[Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
Livnat Peer
lpeer at redhat.com
Sun Jan 22 17:06:57 UTC 2012
On 22/01/12 15:21, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> 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.
>
> There is only a performance problem if the VM is running.
> Keeping as suggested before would prevent running the VM.
> So what I'm suggesting is an improvement (when the VM is running it gives much better performance compared to when it is not).
> Then if the user ran the VM then there are 2 options at the end of the clone:
> 1. shutdown the VM and merge back (again, as opposed to not being able to run the VM - an improvement)
> 2. live merge which would be costly but VM would go on running (also note that next version will support merge in both directions so even better)
>
>
And what about quotas? with the above flow for cloning VM the user needs
quota on the source domain, I find this not intuitive for the user, and
i expect we'll have hard time explaining it.
>
>>
>>
>>
>>>>
>>>> Implementation:
>>>> Well it is simply another implementation.
>>>>
>>>>
>>>> Livnat
>>>>
>>>>
>>
>>
More information about the Engine-devel
mailing list