On Wed, Sep 23, 2009 at 10:05:36AM +0200, Chris Lalancette wrote: > 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. More critically that than, you cannot assume that the libvirt URI used to connect to the machine actually has a hostname that refers to the machine in question, eg ssh -L 22:src.virt.machine:9001 -L 22:dst.virt.machine:9002 some.gateway.machine Now do migration using.... virsh -c xen+ssh://localhost:9001/ migrate --live guest xen+ssh://localhost:9002/ ...what hostname exactly are you going to expect the migration data to go over ? It certainly won't be 'localhost'. We have no choice but todo the hostname query on the target machine to discover the real primary hostname - the libvirt connection URIs are useless for determining the hostname. If the user then wants a different NIC that is not associated with the primary hostname we have to use the extra migrateuri field to supply that data as there's no other way to get it. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list