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

Fri Jan 20 10:01:02 UTC 2012

On 20/01/12 09:35, Ayal Baron wrote:
> 
> 
> ----- 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.
> 

Trying to get to a conclusion here,
3 different people said on this thread that they think that from the
user perspective leaving the shared devices plugged is what they think
is the best behavior to the user. (Omer, Kolesnik, Yair)

On the other hand we have 2 people who think that protecting the user is
more important than leaving the VM configuration as it was in the
original VM (Miki, Ayal).

Ayal/Miki can you please specify what are we protecting the user from?

I think that because we are not snapshotting the shared disk and the
direct LUN they should not be part of the VM configuration (in the
snapshot) at all. we can not promise the user that the disk will be
there and if it is there we can not guarantee it is in the same state as
it was when we took the snapshot.

Another issue,

I can not see a reason to limit this feature to creating a VM from
snapshot and not a template? Almost no extra work is needed for
supporting templates as well.

Any reason not to?

Livnat

>> 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
>>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel