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.
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.
These would be the "technical details", but from user perspective, I'd
argue cloning a snapshot is just cloning an older version of the VM.
i.e., i may pass to clone_vm an optional parameter to request cloning an
older version (specific snapshot), vs. cloning the latest down or
running VM.
for a running VM, ayal mentioned a possible flow (live snapshot, clone,
live merge).
implementing this doesn't have to be in same phase, but the question is
what is the right level of modeling for the API for the action.
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
