----- Original Message -----
----- Original Message -----
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, January 19, 2012 9:19:52 AM Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
On 19/01/12 08:38, Yair Zaslavsky wrote:
Hi all, Following the upstream meeting dated Wednesday January 18th, 2012 - I presented the clone VM from snpashot feature and we discussed the feature behaviour.
Two issues that were raised are the behaviour of the feature in context of shared disks and direct LUNs-based disks - On one hand, if we copy&collapse such images - this may yield to data corruption (think of a scenario where the source and destination VMs use the same disk). On the other hand - if we decide not to copy&collapse - the target VM will have missing VM and its state will not totally reflect the logical state. One of the solution raises is to mark such disks (at the destination) as unplugged, allowing the administrator the ability to plug them (understanding of course the consequences).
I would like to receive inputs on this issue
Kind regards,
Yair
Hi Yair,
Some clarifications on the above issue. Currently when taking a snapshot on a VM with shared disks or direct LUN disk there are 3 optional behaviors:
1. Blocking the snapshot action. (User can not take a snapshot of the VM if it has plugged shared or direct LUN disks)
-1, user should be able to take snapshots. Note that once we have integration with hardware side snapshots, we will be able to snapshot direct LUNs (when supported).
2. Taking the snapshot and marking the shared disk and direct LUN disks as unplugged (in the VM snapshot configuration) and marking the snapshot state as partial.
+1, user has to specifically say 'I know that the direct LUN is not in the same state as it was when I took the snapshot but I know what I'm doing and I want to run the snapshot with the LUN as is'
3. Taking the snapshot of the VM as is, leaving the VM configuration with plugged disks.
-1, this will lead to accidental corruptions.
The issue with including these disks in the snapshot is that they are not really being snapshotted, they are not capturing the point in time we are trying to achieve in the snapshot.
Enabling the snapshot action in such a state is a bit misleading to the user.
If we do allow taking the snapshot we should mark the snapshot as partial to indicate that the snapshot did not capture the point in time as the user intended.
+1, the user should be aware of what she did.
I have no preference with regards to the second and third approach, the second approach is a bit more safe, we basically force the user to plug the disks and be sure that he knows what he is doing and the third approach is less safe and less annoying to the user (he took the snapshot, cloned it and wants to start the VM - don't require extra actions)
Kolesnik - please note when starting VM in a preview mode we should mount the disks in read-only mode (if supported).
Note that if the LUN contains a file system to be mounted and the disk is plugged in read only mode the guest will likely have a kernel panic when trying to mount the fs, I'm not sure this is the behaviour we want.
I don't understand this, can you please elaborate why and in which case? The disk is plugged/unplugged? What happens when you commit? It becomes r/w?
No, you mark it as read-only in the configuration when you create the snapshot. User would have to manually change this to r/w. I'm not sure we should both mark it as unplugged and r/o (although this is the safest option). As it would be annoying to get the disk to actually work in r/w (plug + make r/w). Andy, your thoughts on this?
Livnat
+1 for option 3
+1 for option 3 as well (also good with option 1, but I think this will hinder usability).
Regards, Mike _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel