Bug 1113414 - [RFE] - Manage floating\shared disks with snapshots
Summary: [RFE] - Manage floating\shared disks with snapshots
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.4.0
Hardware: All
OS: All
medium
low
Target Milestone: ---
: ---
Assignee: Rob Young
QA Contact: Avihai
URL:
Whiteboard:
: 1434479 (view as bug list)
Depends On: 1056964 1334256
Blocks: 1539837
TreeView+ depends on / blocked
 
Reported: 2014-06-26 07:19 UTC by Gajanan
Modified: 2021-06-10 10:48 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-01 14:43:47 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:
sherold: Triaged+
lsvaty: testing_plan_complete-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1539837 0 high CLOSED [RFE][tracker][Cinder] - Improve integration and support with storage using cinderlib 2022-04-24 19:47:51 UTC

Internal Links: 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.


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