[libvirt] qemu_driver migrateuri handling broken?

[Gregor Schaffrath]

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)

> 
> > 2) using tcp://<ip>:<port> just produced an 'unknown failure' on the
> > receiving side:
> > root at 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?)

Cheers & thx for the response,
				Gregor.


---snip---
root at loadgen137:/usr/src# diff libvirt-0.6.5/src/qemu_driver.c
libvirt-0.6.5.modified/src/qemu_driver.c 
4862c4862
<     if (uri_in == NULL) {
---
>     //if (uri_in == NULL) {
4878c4878
<     } else {
---
>     //} else {
4883c4883
<         if (!STRPREFIX (uri_in, "tcp:")) {
---
>     /*    if (!STRPREFIX (uri_in, "tcp:")) {
4887c4887
<         }
---
>         }*/
4890,4892c4890,4892
<         p = strrchr (uri_in, ':');
<         p++; /* definitely has a ':' in it, see above */
<         this_port = virParseNumber (&p);
---
>     //    p = strrchr (uri_in, ':');
>     //    p++; /* definitely has a ':' in it, see above */
>     /*    this_port = virParseNumber (&p);
4898c4898
<     }
---
--snip---


>     }*/

> 
> 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 :|