----- 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. > > Implementation: > Well it is simply another implementation. > > > Livnat > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel