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

[Ayal Baron]

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