Description of problem: Snapshoting of shared VM disk Expected results: Wants to snapshot shared VM disk.
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
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.
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 ?
(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.
(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.
*** Bug 1434479 has been marked as a duplicate of this bug. ***
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
ok, closing. Please reopen if still relevant/you want to work on it.