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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list