26 Feb
2012
26 Feb
'12
1:16 p.m.
----- 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 >