[Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
Ayal Baron
abaron at redhat.com
Thu Jan 19 09:22:01 UTC 2012
----- Original Message -----
>
>
> ----- 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)
-1, user should be able to take snapshots.
Note that once we have integration with hardware side snapshots, we will be able to snapshot direct LUNs (when supported).
> > >
> > > 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.
+1, user has to specifically say 'I know that the direct LUN is not in the same state as it was when I took the snapshot but I know what I'm doing and I want to run the snapshot with the LUN as is'
> > >
> > > 3. Taking the snapshot of the VM as is, leaving the VM
> > > configuration
> > > with plugged disks.
-1, this will lead to accidental corruptions.
> > >
> > >
> > > 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.
+1, the user should be aware of what she did.
> > >
> > > 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).
Note that if the LUN contains a file system to be mounted and the disk is plugged in read only mode the guest will likely have a kernel panic when trying to mount the fs, I'm not sure this is the behaviour we want.
>
> 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?
No, you mark it as read-only in the configuration when you create the snapshot.
User would have to manually change this to r/w.
I'm not sure we should both mark it as unplugged and r/o (although this is the safest option).
As it would be annoying to get the disk to actually work in r/w (plug + make r/w).
Andy, your thoughts on this?
>
> > >
> > >
> > > Livnat
> > >
> > >
> > >
> >
> > +1 for option 3
> >
>
> +1 for option 3 as well (also good with option 1, but I think this
> will hinder usability).
>
>
> Regards,
> Mike
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
More information about the Devel
mailing list