[libvirt] issues with migrating using copy-storage-all

Eric Blake eblake at redhat.com
Tue Dec 13 21:26:11 UTC 2011


On 12/09/2011 06:04 AM, Reinier Schoof wrote:
> Hi,
> 
> today I was trying to use the --copy-storage-all feature of virsh
> migrate, in an attempt to migrate KVM-instances to another storage
> backend. Doing so, I ran into some trouble:
> 
> First of all, it turned out the disk image-file has to be present on the
> receiving end of the migration.

Known limitation, and patches are welcome to teach the receiving end to
create the file rather than requiring it to exist.

> When, just to check, this disk image is
> smaller than the original image, migration suddenly stops (after filling
> the maximum size of the too small disk image). This is expected
> behaviour ofcourse.

I don't know if it is expected; it seems like libvirt could usefully be
taught to be smarter and either reject the migration up front if the
destination exists but is too small, or to resize the destination to
allow the migration.

> But when I fix the disk image to the right size and start the migration
> again, the migration fails immediately, the domain is -undefined- and
> crashes. Qemu log showed:
> 
> kvm: block.c:2889: bdrv_set_in_use: Assertion `bs->in_use != in_use'
> failed.
> 2011-12-09 10:58:16.211: shutting down
> 
> Is this behaviour known to you guys?

Not to me, but then I"ve never tested --copy-storage-all.  This
particular error comes from qemu, so you may have better luck asking on
the qemu lists.

> 
> Also, when I migrate a domain (10G qcow2 disk image, which is only used
> for 1GB), the qcow2 image on the receiving end shows 10G for both
> 'virtual disk' and 'disk size', while this was 10G and 1G respectively
> on the sending end. Why is the image expanded? Or is this a limitation
> of the copy-storage-all?

If nothing else, it is evidence that this area of libvirt is under-tested.

> 
> How does the copy-storage-all function works for raw disk images? Does
> it send incremental copies of blocks which are written too since the
> migration is started?

I imagine that qemu has to do some sort of incremental processing of the
storage for the duration of time that it allows the guest to run
concurrently with the data storage; but you'd have to ask on the qemu
list to get details of whether the incremental storage is kept on the
source, destination, or both sides of the migration.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20111213/68df535a/attachment-0001.sig>


More information about the libvir-list mailing list