Bug 1343043

Summary:	[Docs] [Admin] Link to a workaround for using 'dirty' LUNs in a RHV environment
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Andrew Dahms <adahms>
Component:	Documentation	Assignee:	Avital Pinnick <apinnick>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Byron Gravenorst <bgraveno>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0.0	CC:	adahms, apinnick, frolland, gveitmic, lbopf, lsurette, mkalinin, rbalakri, srevivo, stirabos, ykaul, ylavi
Target Milestone:	ovirt-4.1.11	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-10 07:38:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Docs	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andrew Dahms 2016-06-06 11:58:30 UTC

In Red Hat Enterprise Virtualization, attempting to re-use LUNs for block storage domains results in an error due to an issue with LVM that is not likely to be resolved.

As a workaround, a certain number of steps can be performed, and these should be called out to users.

From: https://bugzilla.redhat.com/show_bug.cgi?id=1215427#c4

pvcreate will fail if a partition exists on the LUN, even with force flag.

If you run pvcreate with vvv for verbose ,and a partition is found , the following warning will be logged : 'Skipping: Partition table signature found'

pvcreate -ffvvv /dev/mapper/3600a09803753795a64244531644f7846
........
 /dev/mapper/3600a09803753795a64244531644f7846: Skipping: Partition table signature found [none:(nil)]
........
Device /dev/mapper/3600a09803753795a64244531644f7846 not found (or ignored by filtering).

In order to be able to be able to create the PV, the partition table needs to be deleted.
It can be done by zeroing the first blocks:
  dd if=/dev/zero of=/dev/mapper/3600a09803753795a64244531644f7846 bs=1M count=1


I don't think that this operation should be done by the application, as it can be destructive to user data.

I suggest to document this situation with explanation on how to fix manually.

Comment 1 Yaniv Kaul 2016-09-30 05:46:35 UTC

I suggest adding oflag=direct to the command line to ensure this is not buffered.

Comment 3 Simone Tiraboschi 2018-02-15 17:28:45 UTC

I'd suggest 'wipefs -a /dev/...' since it will also call BLKRRPART ioctl to inform kernel about the partition table change.

Comment 4 Marina Kalinin 2018-03-05 15:00:11 UTC

This sounds more of a KCS material to me, isn't it?
Unless we are going to have a troubleshooting storage guide.
Once we have such a KCS (not article, but solution), we can reference it from the guide that talks about creating storage domains.

Comment 6 Marina Kalinin 2018-03-06 23:02:18 UTC

(In reply to Marina from comment #4)
> This sounds more of a KCS material to me, isn't it?
> Unless we are going to have a troubleshooting storage guide.
> Once we have such a KCS (not article, but solution), we can reference it
> from the guide that talks about creating storage domains.

Lucy / Adam,

Please check the attached KCS(there 2) and see if we can point the docs to them and get this bug fixed.

Comment 7 Andrew Dahms 2018-03-18 23:50:52 UTC

Hi Marina,

Thank you for the needinfo request.

Changing this to Lucy, who is now directly connected with the RHV documentation. It looks like a quick fix, but Lucy will have a better handle on the current capacity and priorities of the team.

Kind regards,

Andrew

Comment 9 Lucy Bopf 2018-03-26 04:18:30 UTC

Thanks for checking on this one, Marina.

I agree that pointing to the existing KCS articles would provide a quick and useful fix in this case. Proposing this fix for 4.1 and 4.2.