Bug 707896

Summary:	Try to run vgextend --restoremissing if we run into missing PV issues
Product:	Red Hat Enterprise Linux 5	Reporter:	Dan Yasny <dyasny>
Component:	vdsm22	Assignee:	Dan Kenigsberg <dkenigsb>
Status:	CLOSED DEFERRED	QA Contact:	yeylon <yeylon>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.6	CC:	abaron, acathrow, bazulay, byount, danken, iheim, srevivo, ykaul
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-06-20 09:00:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Dan Yasny 2011-05-26 09:43:25 UTC

Description of problem:
If BZ#537913 is encountered (SD built on several PVs, one of the PVs where LVs are located goes offline and returns, it remains marked as MISSING)
This causes us to not be able to change LVM metadata, e.g. lvcreate (add disk to VM) fails.

At this point, we see the SD as active and operational, but the lvcreates and other actions fail.


Version-Release number of selected component (if applicable):
vdsm22 2.2.6


How reproducible:
always

Steps to Reproduce:
1. set up SD on several LUNs
2. build VMs on top, make sure at least one LV is touching all the PVs
3. take one of the LUNs down, and then bring it back online
  
Actual results:
the PV is marked missing, can be easily restored with vgextend --restoremissing if there were no changes done

Expected results:
bdsm should try to run restoremissing, in these cases, and if restoremissing fails, it should pause the VMs and set the SD as non-op, to avoid data loss since if restoremissing fails, we definitely have a defunct VG

Additional info:

Comment 3 Dan Kenigsberg 2011-06-16 19:46:40 UTC

Dan, with lvm bug 537913 solved, is there anyway to reproduce the vdsm issue? Does it reproduce on RHEL-6?

Comment 4 Dan Yasny 2011-06-17 07:59:15 UTC

(In reply to comment #3)
> Dan, with lvm bug 537913 solved, is there anyway to reproduce the vdsm issue?
This is not a vdsm issue at all. the mentioned LVM BZ was fixed by adding an additional command, which resolves the situation described. This BZ here is for vdsm to start using that command, in case it runs into a particular storage error

> Does it reproduce on RHEL-6?
I don't have vdsm on RHEL-6. However, the LVM fix should also be available there

Comment 5 Ayal Baron 2011-06-17 18:43:03 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > Dan, with lvm bug 537913 solved, is there anyway to reproduce the vdsm issue?
> This is not a vdsm issue at all. the mentioned LVM BZ was fixed by adding an
> additional command, which resolves the situation described. This BZ here is for
> vdsm to start using that command, in case it runs into a particular storage
> error
> 
> > Does it reproduce on RHEL-6?
> I don't have vdsm on RHEL-6. However, the LVM fix should also be available
> there

Right, but according to comment #2 this does not reproduce, so please reproduce it and if you succeed then make sure the steps described here are correct.