[libvirt] migration: qemu vs. qemu+tcp at virsh vs. libvirt-java

Bryan Kearney bkearney at redhat.com
Tue Nov 17 20:55:06 UTC 2009

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

More information about the libvir-list mailing list