Re: [Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks

----- Original Message ----- > 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. > Yep, +1.

> Miki > > > > ----- Original Message ----- >> From: "Ayal Baron" <abaron(a)redhat.com&gt; >> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; >> Cc: engine-devel(a)ovirt.org >> 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" <lpeer(a)redhat.com&gt; >>>>>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt;, "Mike Kolesnik" >>>>>> <mkolesni(a)redhat.com&gt; >>>>>> Cc: engine-devel(a)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) >>>>>> >>>>>> 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 >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel