[Engine-devel] Clone VM from snapshot feature
Ayal Baron
abaron at redhat.com
Sun Feb 26 14:16:21 UTC 2012
----- 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 at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
More information about the Engine-devel
mailing list