Gregor Schaffrath wrote: > On Mon, Sep 21, 2009 at 12:46:46PM +0100, Daniel P. Berrange wrote: >> On Wed, Sep 16, 2009 at 05:42:50PM +0200, Gregor Schaffrath wrote: >>> Hi all. >>> >>> Short summary on DV's request ;) >>> >>> I ran into a problem migrating kvm machines with libvirt-0.6.5: >>> >>> 1) At first, using the same syntax for the migrateuri as with xen (just the >>> IP) did not work... looking into the source code (! ;) ), I found a >>> different syntax for qemu. >> The URI schemes should be listed in the driver capabilities XML. >> The reason they are different is that they are two different ways >> of doing migration. >> >> We are working on a new tunnelled migration scheme that will be >> uniform across drivers. > ic - To be honest, I was confused by the migrateuri anyhow, since I > considered the situation where libvirt traffic is tunneled via SSH, but > Xen-/KVM-/foo communication may be direct a rather rare exception (or am > I mistaken?) (I understood that this was the rationale behind the > hostname-Query in the first place) Well, the rationale is that you may have two paths to get to a machine, and you may only want to allow migration traffic on one of them (say, a direct cross-over) since the data goes across unencrypted. So you might have a machine with eth0 and eth1, where eth0 is exposed to the world, and you have libvirtd listening on eth0. But then when you actually do the migration, you want it to send the data across on eth1. Note also that libvirt traffic tunnelled via ssh isn't the only method, you can also attach to libvirtd via TLS and TCP (with SASL encryption). > >>> 2) using tcp://<ip>:<port> just produced an 'unknown failure' on the >>> receiving side: >>> root@loadgen137:~> virsh -c qemu:///system migrate --live kvm-testnode-vnode3 qemu+tcp://10.192.11.136/system?no_verify=1 tcp://10.192.11.136:12345 >>> error: Unknown failure >>> (Note: it was working like a charm when I eliminated the migrateuri >>> altogether, >> Hmm, try tcp:10.192.11.136:12345 instead - for some unknown reason >> it is not using correct URI formats. > works indeed :) > >>> 3) removing the case distinction and the handling of the migrateuri in >>> the qemudDomainMigratePrepare2 function in qemu_driver.c entirely >>> (if-statement, and full else-part) solved both my issues. >> I don't know what exactly you removed, by you'll almost certainly have >> broken something else. > > the part doesn't do much besides setting the port - the hostname is even > ignored ;) ... and the error comes from the receiving side - not the > sending one. > > Therefore as far as I see, the only thing broken is that now the sending > side can't choose the listening port number on the receiving side (is > this a debugging feature?) Not exactly a debugging feature, more a "give more control to the admin". If you do not supply a migrateuri, then libvirtd will choose a port between 49152 and 49216. However, if you don't want to open up all of those ports on your firewall, you can specify a migrateuri to say "use *this* port", and then you only have to open up one port in the firewall. So we do need to allow the migrateuri, and removing it isn't really feasible. The tunnelled migration stuff should make this a bit easier, although we'll still have to allow the migrateuri type stuff for the dual-homed situation. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list