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

[Livnat Peer]

On 22/01/12 12:14, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
>> On 20/01/12 17:21, Itamar Heim wrote:
>>> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>>>> 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.
>>>
>>> I assume you meant, creating a VM from another VM (if it is down)?
>>> It should be supported.
>>
>> Actually I meant creating a Template from Snapshot.
> 
> +1
> 
>>
>> What you suggested is creating a VM from VM.
>> Although I see how the two are connected, I think they should be
>> modeled
>> as two different API calls.
>> There is a difference in the flow, behavior, locks and parameters
>> between the two.
>>
>> Behavior:
>> - Original VM has to be down for creating a VM from VM, not the case
>> for
>> creating a VM from snapshot.
>>
>> parameters:
>> - Creating VM from snapshot should support getting a snapshot-ID,
>> Creating VM from VM get a VM id
> 
> What's the difference?
> 
>>
>> Locks:
>> - When creating a VM from VM, we need to lock the original VM as a
>> whole, we can not edit the VM, take snapshot or any other VM level
>> action while such operation is active.
>> While for creating the VM from snapshot we can take more fine-grained
>> locks (only image related locks).
> 
> I would suggest we change the clone VM flow to be:
> 1. create a snapshot in original VM
> 2. clone the snapshot
> This way, while this is going on, the user *can* run the VM and do everything else and behaviour becomes much nicer and not 'you have to wait 4 hours until your clone ends before running the VM'.
> 3. delete the snapshot
> 
> This would also mean that both ops would be collapsed to one and there would be only 1 flow.
> 

I am not sure this is the right way to support creating a VM from VM flow.

Let's say I have a server VM with RAW disks (for performance), I would
not want to take a snapshot from this VM to clone it.



>>
>> Implementation:
>> Well it is simply another implementation.
>>
>>
>> Livnat
>>
>>