Bug 1332018

Summary:	[RFE] - Support LVM-mirrored volumes on iSCSI/FC data domains
Product:	[oVirt] ovirt-engine	Reporter:	Barak Korren <bkorren>
Component:	RFEs	Assignee:	Rob Young <royoung>
Status:	CLOSED WONTFIX	QA Contact:	Gil Klein <gklein>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	future	CC:	bugs, ebenahar, joerg.loges, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	ylavi: ovirt-future? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-11-26 14:01:27 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:

Description Barak Korren 2016-05-01 09:03:22 UTC

oVirt currently leverages LVM for using iSCSI/FC-based storage domains.

LVM has an interesting feature where it allows creating volumes that are mirrors across two different physical volumes.

This feature could be leveraged by oVirt to allow creating VMs that are mirrored across multiple storages and therefore are resilient to storage failures without requiring the use of complex storage technology like Gluster, snap-mirror or others.

This configuration could potentially have better performance then other storage-HA solutions because it may result in lower latency for storage write operations. This is because a mirrored write would require round-trips running in parallel from the hypervisor to the different storages as opposed to a round-trip for write-sync between the storage that is serially nested inside the write round-trip from the hypervisor.

Comment 1 Yaniv Kaul 2017-03-13 13:47:48 UTC

I think it requires a clvm and dlm for locking (based only on reading https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Logical_Volume_Manager_Administration/mirvol_create_ex.html ), which may or may not work with sanlock and friends?

This is for geo-mirroring. 
On the same host (for 'backup' disk), I'd argue that RAID1 makes more sense?

I highly doubt it's more performant (and stable and feature-rich) than storage-based replication.

Comment 2 Yaniv Lavi 2017-11-26 14:01:27 UTC

It makes little sense to me to move the complexity from something like Gluster to oVirt. It is not the right tool for the problem and you can use the oVirt UI to manage Gluster that even makes this more appealing than doing this.
Therefore closing.

Comment 3 Yaniv Lavi 2017-11-26 14:04:25 UTC

*** Bug 1470071 has been marked as a duplicate of this bug. ***