----- Original Message -----
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. Livnat - I think that in case of creating a template from snapshot we should should have new API/Command, that will probably have lots in common with Create VM from snapshot.
Why?
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.
+1 on Livnat's explanation - I do see a (design/implementation wise) an option for some code reuse, but IMHO - this should be a new command with new API modelling
Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel