Bug 1113414

Summary:	[RFE] - Manage floating\shared disks with snapshots
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Gajanan <gchakkar>
Component:	RFEs	Assignee:	Rob Young <royoung>
Status:	CLOSED DEFERRED	QA Contact:	Avihai <aefrat>
Severity:	low	Docs Contact:
Priority:	medium
Version:	3.4.0	CC:	achareka, lpeer, nzahar, srevivo, theophanis_kontogiannis
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	sherold: Triaged+ lsvaty: testing_plan_complete-
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-01 14:43:47 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:	1056964, 1334256
Bug Blocks:	1539837

Description Gajanan 2014-06-26 07:19:10 UTC

Description of problem:

Snapshoting of shared VM disk


Expected results:

Wants to snapshot shared VM disk.

Comment 1 Zaharioudakis Nikos 2014-06-27 10:27:48 UTC

Perhaps we need to differentiate a couple of cases

a) Direct Lun presented in VM  ( I guess we could not do anything there)
b)Disk presented to the machine within a storage domain (that is the common case that we would love to have it). That could have two sub-cases

b1) Block level presented storage (FC, FCOE, ISCSI)
b2) File level presented storage domain (NFS)

The filesystem within should be irrelevant at the end. In linux case clusters with 2 virtual nodes, the shared disk could be formatted with cluster fs (like gfs2 or not ext4, xfs , etc). In case you have an MS cluster should be independent as well

Nikos

Comment 2 Allon Mureinik 2014-06-27 16:52:36 UTC

Due to the qemu's dirty-map works, the only way I can possibly see of doing this is to mandate a r/o disk, which is what the RFE in bug 1056964 describes.

Comment 3 Zaharioudakis Nikos 2014-06-29 10:25:03 UTC

In the readonly shared disk, then things should be quite simple.
In the case that we have a shared disk in read  / write state by multiple virtual machines, then we would need a way to "map" the corresponding blocks states at that specific point in time.
I believe that this backup / clone / snapshot thing was resolved because of the backup API we presented in RHEV 3.3 

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.4-Beta/html/Technical_Guide/Backup-Restore_API_Overview.html

Do you think that could be possible ?

Comment 5 Allon Mureinik 2014-07-02 04:03:21 UTC

(In reply to Zaharioudakis Nikos from comment #3)
> In the readonly shared disk, then things should be quite simple.
> In the case that we have a shared disk in read  / write state by multiple
> virtual machines, then we would need a way to "map" the corresponding blocks
> states at that specific point in time.
> I believe that this backup / clone / snapshot thing was resolved because of
> the backup API we presented in RHEV 3.3 
> 
> https://access.redhat.com/site/documentation/en-US/
> Red_Hat_Enterprise_Virtualization/3.4-Beta/html/Technical_Guide/Backup-
> Restore_API_Overview.html
> 
> Do you think that could be possible ?

Backup API has nothing to do with this.
The problem is taking the snapshot, it's being able to write to the same active layer with several QEMU processes. The Backup API creates transient snapshots when you attach an old snapshot to the appliance VM, effectively keeping the "real" chain r/o.

Comment 6 Zaharioudakis Nikos 2014-07-02 18:04:49 UTC

(In reply to Allon Mureinik from comment #5)
> (In reply to Zaharioudakis Nikos from comment #3)
> > In the readonly shared disk, then things should be quite simple.
> > In the case that we have a shared disk in read  / write state by multiple
> > virtual machines, then we would need a way to "map" the corresponding blocks
> > states at that specific point in time.
> > I believe that this backup / clone / snapshot thing was resolved because of
> > the backup API we presented in RHEV 3.3 
> > 
> > https://access.redhat.com/site/documentation/en-US/
> > Red_Hat_Enterprise_Virtualization/3.4-Beta/html/Technical_Guide/Backup-
> > Restore_API_Overview.html
> > 
> > Do you think that could be possible ?
> 
> Backup API has nothing to do with this.
> The problem is taking the snapshot, it's being able to write to the same
> active layer with several QEMU processes. The Backup API creates transient
> snapshots when you attach an old snapshot to the appliance VM, effectively
> keeping the "real" chain r/o.

Since we can create a "real" and a "delta" then is there a way to copy the "real" part. I guess this is more than enough in our case. If this "real" part can be copied outside the machine, then we have what we need.
The business case behind is that there are customers with a virtualization environment a pair of virtual machines configured as a cluster with a shared disk. Should we be able to snapshot the operating system disks and the common disks, then we provide a unique deferentive feature from all the vendors that I know. So the snapshot RFE of this could be part of a backup / restore strategy.

Comment 10 Allon Mureinik 2017-03-22 04:33:50 UTC

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

Comment 11 Michal Skrivanek 2020-03-18 15:42:54 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 12 Michal Skrivanek 2020-03-18 15:46:16 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 13 Michal Skrivanek 2020-04-01 14:43:47 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 14 Michal Skrivanek 2020-04-01 14:49:06 UTC

ok, closing. Please reopen if still relevant/you want to work on it.