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

[Yair Zaslavsky]

On 01/19/2012 08:41 PM, Miki Kenneth wrote:
> 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
Miki, just to clear /be sure - you're talking about taking the snapshot
as is, living the shared disk as "plugged" on destination VM?

Yair

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