[Engine-devel] Clone VM from snapshot feature
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
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. 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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 - 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.
- 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.
- 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. Y.
Comments are more than welcome
Kind regards, Yair
_______________________________________________ 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
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@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
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@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 >
----- Original Message ----- > 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. The simple answer is that disks are being copied concurrently. Yaniv, to answer a previous question you had - there is no copy + merge, it is a single operation which creates the target already collapsed (qemu-img convert) Yaniv, I'm not sure what you meant with the disk1 and disk2 being raw question. And wrt the copy being done by other hosts - unfortunately we do not yet support that. That would require separating the creation of the target volumes/files from the copy operation. > 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@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 > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel@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
On 02/26/2012 02:05 PM, Itamar Heim 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
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. Understood. What should be the behaviour if shared flag is set to false?
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).
True, I will revisit this. Aren't we facing actually this issue also in creating a VM from template?
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?)
If I understand you correctly - Cloning images commands (AddVmFromTemplate, cloning vm from snapshot, etc..) will invoke a CopyImage internal command.
Thanks, Itamar
On 02/26/2012 02:38 PM, Yair Zaslavsky wrote:
On 02/26/2012 02:05 PM, Itamar Heim 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
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. Understood. What should be the behavior if shared flag is set to false?
warning to audit log that the disk isn't part of the clone.
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).
True, I will revisit this. Aren't we facing actually this issue also in creating a VM from template?
I assume it already has such logic. I'm suggesting to check how redundant it is across the various commands (if it is), before creating another care.
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?)
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?
On 02/26/2012 03:04 PM, Itamar Heim wrote:
On 02/26/2012 02:38 PM, Yair Zaslavsky wrote:
On 02/26/2012 02:05 PM, Itamar Heim 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
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. Understood. What should be the behavior if shared flag is set to false?
warning to audit log that the disk isn't part of the clone.
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).
True, I will revisit this. Aren't we facing actually this issue also in creating a VM from template?
I assume it already has such logic. I'm suggesting to check how redundant it is across the various commands (if it is), before creating another care. Just checked, and you're correct. We do have such logic at AddVmCommand (adding network of new VM part).
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?)
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/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.) Not sure if I understand - are you asking if why I'm not duplicating
On 02/26/2012 03:19 PM, Itamar Heim wrote: this from the original VM?
On 02/26/2012 03:24 PM, Yair Zaslavsky wrote:
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.) Not sure if I understand - are you asking if why I'm not duplicating
On 02/26/2012 03:19 PM, Itamar Heim wrote: this from the original VM?
I'm asking if a non owner of the original VM can copy these, and also if you are cloning the permissions of the original VM
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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).
----- 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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?
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@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
Thanks, Gilad. ----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org, "gilad Chaplik" <gchaplik@redhat.com> 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
http://www.ovirt.org/wiki/Features/ImportMoreThanOnce
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@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
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.
----- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
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 don't understand, what possible other feature?
----- 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@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.
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). 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.
----- 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.
Send from my iPhone . On 28 בפבר 2012, at 00:16, Ayal Baron <abaron@redhat.com> wrote:
----- 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.
I would state it a bit different, the user would like to create new vm (this is the feature) all the rest are different params (flows if you want).
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (6)
-
Ayal Baron -
Gilad Chaplik -
Itamar Heim -
Miki Kenneth -
Yair Zaslavsky -
Yaniv Kaul