[libvirt] migration: qemu vs. qemu+tcp at virsh vs. libvirt-java
Hi, I'm having a little problem when triggering (live) migration from libvirt-java (libvirt.so at client is approx. 0.7.1), I get an error that the qemu:// driver for migration URIs is not supported, only qemu+tcp:// Strange thing is, with virsh at the same client (same libvirt.so), qemu:// works. Interestingly, the error message seems to come from libvirt.so and not libvirt-java. I'd like to avoid maintaining two different URIs/drivers for normal connections and migration destinations, especially as it works flawlessly (and fast!) with virsh? Has anyone clues where this twisted-mind behaviour could come from? kr, tom
On 11/16/2009 12:33 AM, Thomas Treutner wrote:
Hi,
I'm having a little problem when triggering (live) migration from libvirt-java (libvirt.so at client is approx. 0.7.1), I get an error that the qemu:// driver for migration URIs is not supported, only qemu+tcp://
Strange thing is, with virsh at the same client (same libvirt.so), qemu:// works. Interestingly, the error message seems to come from libvirt.so and not libvirt-java.
I'd like to avoid maintaining two different URIs/drivers for normal connections and migration destinations, especially as it works flawlessly (and fast!) with virsh?
Has anyone clues where this twisted-mind behaviour could come from?
What is the full argument list you are passing to the migrate function? You should only see that 'tcp' error if you are passing an explicit URI, which isn't required for standard migration. For virDomainMigrate, the least you need is a VM pointer and an open connection ptr, which will be the destination connection. URI should only be specified if you want to migrate over a specific interface on the remote host, and the uri should be of the form tcp://hostname[:port] This does not require TCP auth to be setup between the connections, since migrate uses a straight TCP connection (unless using the PEER2PEER flag, in which case URI should be a full fledged libvirt URI). - Cole
On Monday 16 November 2009 14:42:16 you wrote:
On 11/16/2009 12:33 AM, Thomas Treutner wrote:
Hi,
I'm having a little problem when triggering (live) migration from libvirt-java (libvirt.so at client is approx. 0.7.1), I get an error that the qemu:// driver for migration URIs is not supported, only qemu+tcp://
Strange thing is, with virsh at the same client (same libvirt.so), qemu:// works. Interestingly, the error message seems to come from libvirt.so and not libvirt-java.
I'd like to avoid maintaining two different URIs/drivers for normal connections and migration destinations, especially as it works flawlessly (and fast!) with virsh?
Has anyone clues where this twisted-mind behaviour could come from?
What is the full argument list you are passing to the migrate function? You should only see that 'tcp' error if you are passing an explicit URI, which isn't required for standard migration.
domain.migrate(dst, 1, null, dstIP, 0); where dst is a Connect object created with qemu://nodeX/system - I'm also passing a destination IP, could that be the problem? I used this code with Xen before. I have two ethXs, one for iSCSI, libvirt, .. and one for br0. dstIP is the same IP dst points to, but if it's possible, I'd like to let it be configurable that way. Ah, javadoc says I'm using an URI ;) I'll try your suggestions ASAP. Thanks! kr tom
On 11/17/2009 05:36 AM, Thomas Treutner wrote:
On Monday 16 November 2009 14:42:16 you wrote:
On 11/16/2009 12:33 AM, Thomas Treutner wrote:
Hi,
I'm having a little problem when triggering (live) migration from libvirt-java (libvirt.so at client is approx. 0.7.1), I get an error that the qemu:// driver for migration URIs is not supported, only qemu+tcp://
Strange thing is, with virsh at the same client (same libvirt.so), qemu:// works. Interestingly, the error message seems to come from libvirt.so and not libvirt-java.
I'd like to avoid maintaining two different URIs/drivers for normal connections and migration destinations, especially as it works flawlessly (and fast!) with virsh?
Has anyone clues where this twisted-mind behaviour could come from?
What is the full argument list you are passing to the migrate function? You should only see that 'tcp' error if you are passing an explicit URI, which isn't required for standard migration.
domain.migrate(dst, 1, null, dstIP, 0);
where dst is a Connect object created with qemu://nodeX/system - I'm also passing a destination IP, could that be the problem? I used this code with Xen before. I have two ethXs, one for iSCSI, libvirt, .. and one for br0. dstIP is the same IP dst points to, but if it's possible, I'd like to let it be configurable that way.
Ah, javadoc says I'm using an URI ;) I'll try your suggestions ASAP.
Let me know what would have been better in the Javadoc, and I will make the change. Thanks! -- bk
On Monday 16 November 2009 14:42:16 Cole Robinson wrote:
For virDomainMigrate, the least you need is a VM pointer and an open connection ptr, which will be the destination connection. URI should only be specified if you want to migrate over a specific interface on the remote host, and the uri should be of the form
Both
tcp://hostname[:port]
and omitting the URI parameter seem to work. Regarding javadoc - of course one should read it, which I didn't, but I think it wouldn't have helped me, because in "If uri is NULL, then libvirt will try to find the best method. Uri may specify the hostname or IP address of the destination host as seen from the source. Or uri may be a URI giving transport, hostname, user, port, etc. in the usual form. Refer to driver documentation for the particular URIs supported." the pointer to http://libvirt.org/drvqemu.html isn't helpful as "tcp://host" isn't there either. So I think it would be helpful to add your suggestions to either javadoc or the drivers doc? kr, tom
participants (3)
-
Bryan Kearney -
Cole Robinson -
Thomas Treutner