9:16 a.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(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