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