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@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@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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list