On 01/19/2012 08:41 PM, Miki Kenneth wrote: > Top Posting: > > From user POV I think that option 2 is the only one that make sense. We try > to do as much as we can, > and on each "problematic" case, we make him aware and let him decide. > > Miki Miki, just to clear /be sure - you're talking about taking the snapshot as is, living the shared disk as "plugged" on destination VM?
Yair > > > > ----- Original Message ----- >> From: "Ayal Baron" <[email protected]> >> To: "Yair Zaslavsky" <[email protected]> >> Cc: [email protected] >> Sent: Thursday, January 19, 2012 4:04:02 AM >> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot feature in >> context of shared disks and direct >> LUNs-based disks >> >> >> >> ----- Original Message ----- >>> On 01/19/2012 10:32 AM, Mike Kolesnik wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Livnat Peer" <[email protected]> >>>>>> To: "Yair Zaslavsky" <[email protected]>, "Mike Kolesnik" >>>>>> <[email protected]> >>>>>> Cc: [email protected] >>>>>> 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) >>>>>> >>>>>> 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. >>>>>> >>>>>> 3. Taking the snapshot of the VM as is, leaving the VM >>>>>> configuration >>>>>> with plugged disks. >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> 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). >>>> >>>> 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? >>>> >>>>>> >>>>>> >>>>>> Livnat >>>>>> >>>>>> >>>>>> >>>>> >>>>> +1 for option 3 >>>>> >>>> >>>> +1 for option 3 as well (also good with option 1, but I think >>>> this >>>> will hinder usability). >>> I agree with Mike - I think option one is too "aggressive" in >>> protecting >>> us, this is why I prefer 3. +1 on option 3 >> >> This would only be acceptable if the disk is marked read only. >> Just leaving the disk plugged means many users *will* corrupt their >> VMs. >> That trumps the need to mark a checkbox if you want it available. >> >> As I said before, readonly has its own problems and in fact, IMO the >> behaviour is even more difficult to explain (yeah, you might corrupt >> the running VM if it's r/w so we made it r/o and now if you start up >> your clone / preview you will get a kernel panic). >> >>>> >>>> >>>> Regards, >>>> Mike >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
