Bug 795800

Summary:	[ovirt] [vdsm] Avoid dangerouos LVM ops on HSM using specific locking type
Product:	[Retired] oVirt	Reporter:	Haim <hateya>
Component:	vdsm	Assignee:	Eduardo Warszawski <ewarszaw>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	abaron, acathrow, amureini, bazulay, ewarszaw, hateya, iheim, mgoldboi, yeylon, ykaul
Target Milestone:	---
Target Release:	3.3.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	storage
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-03-11 21:58:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Haim 2012-02-21 15:00:16 UTC

Description of problem:

The following implementation might add significant value when working when using LVM for both HSM and SPM hosts. 

current pains: 

- lvm process is stuck in kernel - if certain lvm operation stuck (even read-only one), other lvm commands can't run and enter queue, since one of the lvm commands are stuck in kernel, it can only gets release using reboot, with this configuration, other lvm commands can still run, and host will not gets stuck. 

- HSM host tries to right to metadata - by design, hsm host should not write to metadata, we seen several cases where HSM hosts does change metadata, and altough we are in the process of clearing all cases, such configuration may save us from the first place. 

locking type = 4: 

Type 4 enforces read-only metadata and forbids any operations that might want to modify Volume Group metadata.

Comment 1 Itamar Heim 2013-03-11 21:58:33 UTC

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.