----- 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" <[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
