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

On 01/19/2012 10:32 AM, Mike Kolesnik wrote: > > > ----- Original Message ----- >> >> >> ----- Original Message ----- >>> From: "Livnat Peer" <lpeer(a)redhat.com&gt; >>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt;, "Mike Kolesnik" >>> <mkolesni(a)redhat.com&gt; >>> Cc: engine-devel(a)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

> > > Regards, > Mike _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel