Bug 928317

Summary:	[RFE] [vdsm] Avoid dangerouos LVM ops on HSM using specific locking type
Product:	[oVirt] vdsm	Reporter:	Haim <hateya>
Component:	RFEs	Assignee:	Nobody <nobody>
Status:	CLOSED WONTFIX	QA Contact:	Aharon Canan <acanan>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	---	CC:	amureini, bazulay, bsettle, bugs, iheim, lpeer, scohen, srevivo, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	amureini: needinfo- amureini: needinfo- ylavi: ovirt-future? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-13 14:48:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1080372, 1185830
Bug Blocks:

Description Haim 2013-03-27 11:51:06 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-12-01 19:12:12 UTC

patch is from February, haven't been touched since may.
is this still slated for 3.4?

Comment 2 Ayal Baron 2013-12-01 19:42:33 UTC

(In reply to Itamar Heim from comment #1)
> patch is from February, haven't been touched since may.
> is this still slated for 3.4?

Not clear.

Comment 3 Ayal Baron 2013-12-18 09:29:14 UTC

Yeela, any update on this?

Comment 7 Yaniv Lavi 2016-07-13 14:48:08 UTC

Please reopen if still relevant.