Hi all, I modified the Wiki pages of this feature: http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot

Comments are more than welcome Kind regards, Yair _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On 02/14/2012 10:29 AM, Yaniv Kaul wrote: > On 02/14/2012 10:06 AM, Yair Zaslavsky wrote: >> Hi all, >> I modified the Wiki pages of this feature: >> >> http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot >> >> http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot > > - Missing error handling. I hope all will goes well, of course.

> - Will you be copying the disks in parallel, or serially?

> - Too bad the disks have to be copied by the SPM. Not sure why, really. Typo, will be fixed. > Same for the merge, which is not really mentioned where/how it's going > to take place (VDSM-wise).

> - If the 'Disk1' , 'Disk2' are RAW, would be nice to have an option NOT > to copy them. Especially as you have a snapshot on top of them.

> Y. > >> >> Comments are more than welcome >> >> Kind regards, >> Yair >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On 02/14/2012 10:53 AM, Yair Zaslavsky wrote: > On 02/14/2012 10:35 AM, Yair Zaslavsky wrote: >> On 02/14/2012 10:29 AM, Yaniv Kaul wrote: >>> On 02/14/2012 10:06 AM, Yair Zaslavsky wrote: >>>> Hi all, >>>> I modified the Wiki pages of this feature: >>>> >>>> http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot >>>> >>>> http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot >>> - Missing error handling. I hope all will goes well, of course. > Will be added. Not sure though what can we do in case for example you > fail to copy image N out of M , besides of course Since it's not clear that if you merge the snapshots regardless of the base image (if it's RAW), or you merge them all to one big image, I'm not sure if there are two processes here or not - I assume there are: copy and merge. Each can fail independently, and rollback is probably required? >>> - Will you be copying the disks in parallel, or serially? > CopyImage is an asycnrhonous verb that will be monitored by the > AsyncTaskManager at Engine core. Which means that if there are N disks you copy them in parallel or one by one? May make sense to do it depending on the storage domain - if it's the same for all or not, etc. An optimization, I guess.

> >>> - Too bad the disks have to be copied by the SPM. Not sure why, really. >> Typo, will be fixed. >>> Same for the merge, which is not really mentioned where/how it's going >>> to take place (VDSM-wise). > The copy operation will perform collapse on destination. > Maybe I do not understand your question here- please elaborate. Will the merge of the snapshots be done by SPM or HSM? > >>> - If the 'Disk1' , 'Disk2' are RAW, would be nice to have an option NOT >>> to copy them. Especially as you have a snapshot on top of them. > Please elaborate on that. If you are going to merge snapshots into the base, not sure it needs to be copied first - I wonder if there's an option to collapse to a new destination. QEMU feature, I guess. Y. >>> Y. >>> >>>> Comments are more than welcome >>>> >>>> Kind regards, >>>> Yair >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel

On 02/14/2012 10:06 AM, Yair Zaslavsky wrote: > Hi all, > I modified the Wiki pages of this feature: > > http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot > > http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot > > Comments are more than welcome 1. "Shared disks and direct LUN diskes behavior - For shared disks and direct LUN based disks, the user who performs the snapshot will specify during snapshot creation whether the disk should be plugged or unplugged upon performing the clone." direct lun - if it is not already in shared mode, cannot be used by more than one VM, hence should not be cloned, unless already flagged as shared.

2. it sounds like there should be some general code shared for import vm and clone vm for handling items which can't be duplicate by default (say, mac addresses).

3. MLA - are you cloning the permissions on the VM as well, or only creating an owner permission on the new entity? 4. MLA - what permission does one need to have on source VM/snapsot to clone it? if a non-owner can clone a VM/snapshot, and become owner of the new entity, need to make sure no privilege escalation flows exist. is the intent to share the code of clone VM with AddVm (which is what clone is), with a task to clone the disks rather than create them (otherwise you need to duplicate the code for quota and permission handling?)

Thanks, Itamar

>>> 4. MLA - what permission does one need to have on source VM/snapsot to >>> clone it? >>> if a non-owner can clone a VM/snapshot, and become owner of the new >>> entity, need to make sure no privilege escalation flows exist. >>> is the intent to share the code of clone VM with AddVm (which is what >>> clone is), with a task to clone the disks rather than create them >>> (otherwise you need to duplicate the code for quota and permission >>> handling?) >> If I understand you correctly - Cloning images commands >> (AddVmFromTemplate, cloning vm from snapshot, etc..) will invoke a >> CopyImage internal command. > > iiuc, internal commands don't perform permission checks? Correct, they do not.

On 02/26/2012 03:20 PM, Yair Zaslavsky wrote: ... >>>> 4. MLA - what permission does one need to have on source VM/snapsot to >>>> clone it? >>>> if a non-owner can clone a VM/snapshot, and become owner of the new >>>> entity, need to make sure no privilege escalation flows exist. >>>> is the intent to share the code of clone VM with AddVm (which is what >>>> clone is), with a task to clone the disks rather than create them >>>> (otherwise you need to duplicate the code for quota and permission >>>> handling?) >>> If I understand you correctly - Cloning images commands >>> (AddVmFromTemplate, cloning vm from snapshot, etc..) will invoke a >>> CopyImage internal command. >> >> iiuc, internal commands don't perform permission checks? > Correct, they do not. then how do you not duplicate checks like user is allowed to the cluster (and later, to custom properties, logical networks, shared disks, etc.)

On 02/14/2012 11:03 AM, Yaniv Kaul wrote: > On 02/14/2012 10:53 AM, Yair Zaslavsky wrote: >> On 02/14/2012 10:35 AM, Yair Zaslavsky wrote: >>> On 02/14/2012 10:29 AM, Yaniv Kaul wrote: >>>> On 02/14/2012 10:06 AM, Yair Zaslavsky wrote: >>>>> Hi all, >>>>> I modified the Wiki pages of this feature: >>>>> >>>>> http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot >>>>> >>>>> http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot >>>> - Missing error handling. I hope all will goes well, of course. >> Will be added. Not sure though what can we do in case for example >> you >> fail to copy image N out of M , besides of course > > Since it's not clear that if you merge the snapshots regardless of > the > base image (if it's RAW), or you merge them all to one big image, > I'm > not sure if there are two processes here or not - I assume there > are: > copy and merge. Each can fail independently, and rollback is > probably > required? > >>>> - Will you be copying the disks in parallel, or serially? >> CopyImage is an asycnrhonous verb that will be monitored by the >> AsyncTaskManager at Engine core. > > Which means that if there are N disks you copy them in parallel or > one > by one? May make sense to do it depending on the storage domain - > if > it's the same for all or not, etc. An optimization, I guess. This engine core code that is required to launch VDS command + create a task for monitoring it takes less time than completion of the monitoring itself - so the part of lauch VDS command + create task for monitoring is serial, but the monitoring itself is performed periodically, according to the behavior of AsyncTaskManager.

Engine-core is indifferent to whether the copies are performed concurrently or not in VDSM. > >> >>>> - Too bad the disks have to be copied by the SPM. Not sure why, >>>> really. >>> Typo, will be fixed. >>>> Same for the merge, which is not really mentioned where/how it's >>>> going >>>> to take place (VDSM-wise). >> The copy operation will perform collapse on destination. >> Maybe I do not understand your question here- please elaborate. > > Will the merge of the snapshots be done by SPM or HSM? > >> >>>> - If the 'Disk1' , 'Disk2' are RAW, would be nice to have an >>>> option NOT >>>> to copy them. Especially as you have a snapshot on top of them. >> Please elaborate on that. > > If you are going to merge snapshots into the base, not sure it > needs to > be copied first - I wonder if there's an option to collapse to a > new > destination. QEMU feature, I guess. > Y. > >>>> Y. >>>> >>>>> Comments are more than welcome >>>>> >>>>> Kind regards, >>>>> Yair >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

Yair, what about import of VM more than once?

----- Original Message ----- > Hi all, > I modified the Wiki pages of this feature: > > http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot > > http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot > > Comments are more than welcome > > Kind regards, > Yair > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >

----- Original Message ----- > On 02/26/2012 04:38 PM, Ayal Baron wrote: >> Yair, what about import of VM more than once? > Hi Ayal, > We consider this as a different feature. > Gilad Chaplik is the feature owner. > I can think of some very similar features to this one (not just > import > more than once). First, I couldn't find a feature page for that. Second, I don't really understand the difference, there are subtle differences in the flow, but it is basically the same. In fact. the only difference I can think of is that it is initiated from import and not from right click on the snapshot...

What other similar features will this *not* cover? > >> >> ----- Original Message ----- >>> Hi all, >>> I modified the Wiki pages of this feature: >>> >>> http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot >>> >>> http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot >>> >>> Comments are more than welcome >>> >>> Kind regards, >>> Yair >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > >

----- Original Message ----- > On 02/26/2012 04:38 PM, Ayal Baron wrote: >> Yair, what about import of VM more than once? > Hi Ayal, > We consider this as a different feature. > Gilad Chaplik is the feature owner. > I can think of some very similar features to this one (not just > import > more than once). First, I couldn't find a feature page for that. Second, I don't really understand the difference, there are subtle differences in the flow, but it is basically the same. In fact. the only difference I can think of is that it is initiated from import and not from right click on the snapshot... What other similar features will this *not* cover?

> >> >> ----- Original Message ----- >>> Hi all, >>> I modified the Wiki pages of this feature: >>> >>> http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot >>> >>> http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot >>> >>> Comments are more than welcome >>> >>> Kind regards, >>> Yair >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > >

From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; To: "Ayal Baron" <abaron(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "gilad Chaplik" <gchaplik(a)redhat.com&gt; Sent: Sunday, February 26, 2012 5:03:33 PM Subject: Re: [Engine-devel] Clone VM from snapshot feature On 02/26/2012 05:02 PM, Yair Zaslavsky wrote: > On 02/26/2012 04:55 PM, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> On 02/26/2012 04:38 PM, Ayal Baron wrote: >>>> Yair, what about import of VM more than once? >>> Hi Ayal, >>> We consider this as a different feature. >>> Gilad Chaplik is the feature owner. >>> I can think of some very similar features to this one (not just >>> import >>> more than once). >> >> First, I couldn't find a feature page for that. >> Second, I don't really understand the difference, there are subtle >> differences in the flow, but it is basically the same. >> In fact. the only difference I can think of is that it is >> initiated from import and not from right click on the snapshot... > Gilad? CC'ing Gilad on this

>> >> What other similar features will this *not* cover? >> >> >>> >>>> >>>> ----- Original Message ----- >>>>> Hi all, >>>>> I modified the Wiki pages of this feature: >>>>> >>>>> http://www.ovirt.org/wiki/Features/CloneVmFromSnapshot >>>>> >>>>> http://www.ovirt.org/wiki/Features/DetailedCloneVmFromSnapshot >>>>> >>>>> Comments are more than welcome >>>>> >>>>> Kind regards, >>>>> Yair >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>> >>> > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

On 02/26/2012 05:05 PM, Yair Zaslavsky wrote: > On 02/26/2012 04:55 PM, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> On 02/26/2012 04:38 PM, Ayal Baron wrote: >>>> Yair, what about import of VM more than once? >>> Hi Ayal, >>> We consider this as a different feature. >>> Gilad Chaplik is the feature owner. >>> I can think of some very similar features to this one (not just >>> import >>> more than once). >> >> First, I couldn't find a feature page for that. >> Second, I don't really understand the difference, there are subtle >> differences in the flow, but it is basically the same. >> In fact. the only difference I can think of is that it is initiated >> from import and not from right click on the snapshot... >> >> What other similar features will this *not* cover? > I can tell you that for current testing until fully integrated with > snapshots modifications, I am testing it on VM which is down. > Not sure we're interested in this, but here is an example of possible > feature. I think Ayal point/question is similar to mine - why at general code level (obviously there are implementation differences) and user experience wise, the following aren't similar: [AddVmFromBlank] AddVmFromTemplate AddVmFromVm AddVmFromSnapshot AddVmFromImportCandidate[1]

[1] yes, there is a difference if you select more than a single import candidate (adding multiple VMs), but that's actually at UI level, not backend implementation.

----- Original Message ----- > On 02/27/2012 09:09 PM, Itamar Heim wrote: >> On 02/26/2012 05:05 PM, Yair Zaslavsky wrote: >>> On 02/26/2012 04:55 PM, Ayal Baron wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> On 02/26/2012 04:38 PM, Ayal Baron wrote: >>>>>> Yair, what about import of VM more than once? >>>>> Hi Ayal, >>>>> We consider this as a different feature. >>>>> Gilad Chaplik is the feature owner. >>>>> I can think of some very similar features to this one (not just >>>>> import >>>>> more than once). >>>> >>>> First, I couldn't find a feature page for that. >>>> Second, I don't really understand the difference, there are >>>> subtle >>>> differences in the flow, but it is basically the same. >>>> In fact. the only difference I can think of is that it is >>>> initiated >>>> from import and not from right click on the snapshot... >>>> >>>> What other similar features will this *not* cover? >>> I can tell you that for current testing until fully integrated >>> with >>> snapshots modifications, I am testing it on VM which is down. >>> Not sure we're interested in this, but here is an example of >>> possible >>> feature. >> >> I think Ayal point/question is similar to mine - why at general >> code >> level (obviously there are implementation differences) and user >> experience wise, the following aren't similar: >> [AddVmFromBlank] >> AddVmFromTemplate >> AddVmFromVm >> AddVmFromSnapshot >> AddVmFromImportCandidate[1] > > Of course there is shared code - for example, in the class diagram I > presented for Clone VM from Snapshot, it can clearly be seen that > there > is code reuse, and there are two paths of "image-creation" (actually, > there is of course also a 3rd path of 'createImage' verb) - path for > snapshot and path for copyImage - In addition, the code of the > "addVmXXXCommand" usually extends AddVmCommand, and of course > introduces > some changes. > In addition , differences may occur at MLA (for example, for > clone-vm-from-snapshot, and maybe other future flows I'm considering > of > adding a new action-group for CloneVm to the code - I'll update the > wiki > shortly on this), and of course UI-wise. > So I hope that now I gave more explanations on where the code is > similar > and where its different (actually, I would like to point that in my > changes, I'm striving to introduce more code-reuse). The point is not about code reuse. It is about the above being the same functionality from the user perspective with a few nuances. It could actually be implemented in different ways but it's still not multiple features. Which also means that user experience should be almost the same in all these scenarios, which is why they should derive from the same point (design wise not implementation wise). Today as you mentioned there are 2 different low level commands for achieving the above, but in fact going forward in the new image API, creating a new image whether it is based on an existing image or not and whether it is optimized for performance (collapse) or optimized for space (qcow2 / something else) would be a single command. Somthing like: createImage size [source] [perf/space] So again, code wise you could in fact be invoking different commands (so no code reuse), but the user doesn't care that underlying it is different flows, it is the same operation - creating a new image. everything else is a nuance.

> > Yair > >> >> >> [1] yes, there is a difference if you select more than a single >> import >> candidate (adding multiple VMs), but that's actually at UI level, >> not >> backend implementation. >> > > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel