On 22/01/12 15:21, Ayal Baron wrote: > > > ----- 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) > >
And what about quotas? with the above flow for cloning VM the user needs quota on the source domain, I find this not intuitive for the user, and i expect we'll have hard time explaining it. > >> >> >> >>>> >>>> Implementation: >>>> Well it is simply another implementation. >>>> >>>> >>>> Livnat >>>> >>>> >> >> _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
