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

[Miki Kenneth]

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



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