[libvirt] [PATCH v1 00/11] Rework storage migration

Michal Privoznik mprivozn at redhat.com
Wed Nov 28 13:11:00 UTC 2012


On 28.11.2012 14:00, Jiri Denemark wrote:
> On Wed, Nov 28, 2012 at 10:31:54 +0800, li guang wrote:
>> 在 2012-11-27二的 16:42 -0500,Eric Blake写道:
>>>> This patch set re-implements migration with storage for enough new
>>>> qemu.
>>>
>>> How does this series interact with Li Guang's efforts to add offline
>>> migration?  In particular,
>>>
>>>> 1)  src -> dest: (QEMU_MIGRATION_PHASE_BEGIN3 ->
>>>> QEMU_MIGRATION_PHASE_PREPARE)
>>>>     <nbd>
>>>>        <disk src='/var/lib/libvirt/images/f17.img'
>>>>        size='17179869184'/>
>>>>     </nbd>
>>>
>>> Both sets of patches need to pass size information across in the
>>> cookies; so is tying it to <nbd> appropriate, or should we be
>>> rethinking this XML to be shared between both patches?
>>
>> actually, I think 'src' is unnecessary, for 'def->disks[i]->src'
> 
> 'src' is not only unnecessary it's actually totally useless since we can't
> rely on it. In case a domain is migrated to a host with pre-migration hook
> installed, the hook is allowed to modify parts of the XML that are not visible
> to the domain. And disk source is one of them. (The same applies for
> specifying the XML to be used on destination directly to virDomainMigrate*
> APIs.) In other words, disk source on destination does not have to match the
> path on source host.
> 
> Jirka
> 

Oh, right. Then we can't rely on disk ordering neither (well, for now we
can because of our code being dumb-enough; but if we change it ...). I
should have used device-id instead as it is the only thing that will not
change. However, if it ever will - we are gonna need a mapping anyway,
so we can map these device-ids then. So the migration cookie should look
like this:
<nbd>
  <disk id="drive-virtio-disk0" size="123456"/>
  ...
</nbd>


Although, I am not sure whether to include the QEMU_DRIVE_HOST_PREFIX
(="drive-") or not.

Michal




More information about the libvir-list mailing list