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

[Ayal Baron]

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



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