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

[Itamar Heim]

On 01/22/2012 09:26 AM, Livnat Peer wrote:
> 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.
>
> 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
>
> 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).
>
> Implementation:
> Well it is simply another implementation.

These would be the "technical details", but from user perspective, I'd 
argue cloning a snapshot is just cloning an older version of the VM.
i.e., i may pass to clone_vm an optional parameter to request cloning an 
older version (specific snapshot), vs. cloning the latest down or 
running VM.
for a running VM, ayal mentioned a possible flow (live snapshot, clone, 
live merge).
implementing this doesn't have to be in same phase, but the question is 
what is the right level of modeling for the API for the action.