Bug 1332018 - [RFE] - Support LVM-mirrored volumes on iSCSI/FC data domains
Summary: [RFE] - Support LVM-mirrored volumes on iSCSI/FC data domains
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: future
Hardware: Unspecified
OS: Unspecified
unspecified
low vote
Target Milestone: ---
: ---
Assignee: Rob Young
QA Contact: Gil Klein
URL:
Whiteboard:
: 1470071 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-01 09:03 UTC by Barak Korren
Modified: 2017-11-26 14:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-26 14:01:27 UTC
oVirt Team: Storage
ylavi: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

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. ***


Note You need to log in before you can comment on or make changes to this bug.