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

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