On 10/18/2012 05:26 AM, Eric Blake wrote: > On 10/16/2012 10:10 PM, Corey Quinn wrote: >> >> On Oct 16, 2012, at 9:15 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: >> >>> On 10/16/2012 04:37 AM, Corey Quinn wrote: >>>> I have a KVM VM that's backed by a logical volume on local disk. >>>> >>>> I'd like to copy / move it to an identically configured host. >>>> >>>> [root@virt2 cquinn]# virsh migrate --copy-storage-all --verbose --persistent node1.www qemu+ssh://10.102.1.11/system >>> >>> Off-hand, that looks right; I just double-checked >>> http://libvirt.org/migration.html to make sure that it looks like a >>> valid native migration usage. But do be aware that --copy-storage-all >>> is poorly tested, and also that it currently requires you to pre-create >>> a destination file by the same name (there has been talk about patching >>> libvirt to auto-create the files, but that patch is still in the work, >>> and for back-compat reasons, it would require you to pass another option). >>> >> >> Hmm, then what's the "proper" method to copy the VM's backend logical volume? At the moment I'm trying to copy a template VM (used for girt-clone) rather than having to build one of them per host-- that's tedious and an obnoxious source of variance. >> > > So it sounds like you are talking about thin-provisioning - having a > common backing file, and then a different qcow2 file per guest that all > point back to the common backing file. Corey, See if it might be useful to you -- http://kashyapc.wordpress.com/2012/10/04/creating-rapid-thin-provisioned-guests-using-qemu-backing-files/ > >> I'm not opposed to dding it via netcat, but the last time I tried this there was something "off" enough that the VM hung during boot. > > For disk images, dd should work. You might also want to look into > libguestfs; it includes tools such as virt-resize and virt-sparsify that > can be used to do copying more efficiently than dd. > >> >>>> >>>> error: Unable to read from monitor: Connection reset by peer >>> >>> This most likely means that qemu on the receiving end died quite early; >>> perhaps looking at /var/log/libvirt/qemu/node1.www.log will give you >>> more clues why. >> >> Hmm: >> char device redirected to /dev/pts/2 >> inet_listen_opts: bind(ipv4,10.102.1.12,5901): Cannot assign requested address >> inet_listen_opts: FAILED > > Do you have firewall rules preventing native migration? Have you tried > peer-to-peer migration instead (virsh migrate --p2p), as that avoids > needing to punch quite so many holes into the firewall? > >> >> This is on the destination node, but 10.102.1.12 is assigned to the source host, not the destination. > > Native migration requires that the destination be able to call home back > to the source - but my guess is the firewall was preventing it from > doing so. You are thus seeing the error message from the destination > qemu saying it can't reach the source qemu. Again, peer-to-peer > migration would avoid this (qemu would then be talking to libvirt, > instead of directly across the network, with the migration data > piggybacked over libvirt's already-open network connection). > >> Does this need to be an IP that's shared between the two hosts? Frankly, I don't much care if the vnc display > > Native migration requires that the destination can contact the host. > I'm not sure what you are asking about shared IP addresses (that doesn't > make sense for two hosts to share a single IP). > >> >> Additionally, the migrate refuses to start unless the VM is running, but that's far from a requirement from my perspective-- not sure if that's a bug or a feature. > > Kind of both - right now, 'virsh migrate' caters only to live migration, > but there's a patch proposed upstream that will allow offline migration > via a single API call: > https://www.redhat.com/archives/libvir-list/2012-October/msg00456.html > > Meanwhile, you can already do offline migration with a series of calls: > on source: virsh dumpxml $guest > file > then copy all the disk images and that xml file to destination > on destination: virsh define file > > I guess the reason that offline migration hasn't made it into a single > API call yet is because it is so trivial in comparison to live migration. > > > > _______________________________________________ > libvirt-users mailing list > libvirt-users@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvirt-users > -- /kashyap _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
