Shu, I build oVirt Engine and vdsm from source myself. The commits I indicated are what I built from.I run the engine under FC17 and my nodes are running EL6.x respectively. Dan, I reverted VDSM on my two test nodes to an earlier build of VDSM (commit: c343e1833f7b6e5428dd90f14f7807dca1baa0b4) VDSM after the above commit is broken due to commit: fc3a44f71d2ef202cff18d7203b9e4165b546621 however when I built and tested from master yesterday I did apply a patch I tested for ybronhei which fixed that issue. I will build VDSM from master, today w/ the supervdsm patch and try the manual migration you indicated. - DHC On Thu, Jan 31, 2013 at 4:56 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Thu, Jan 31, 2013 at 11:08:58AM +0100, Martin Kletzander wrote:
On 01/31/2013 10:25 AM, Dan Kenigsberg wrote:
On Thu, Jan 31, 2013 at 09:43:44AM +0100, Martin Kletzander wrote:
On 01/30/2013 08:40 PM, Dead Horse wrote:
The nodes are EL6.3 based.
Currently installed libvirt packages:
libvirt-lock-sanlock-0.9.10-21.el6_3.8.x86_64 libvirt-cim-0.6.1-3.el6.x86_64 libvirt-0.9.10-21.el6_3.8.x86_64 libvirt-python-0.9.10-21.el6_3.8.x86_64 libvirt-client-0.9.10-21.el6_3.8.x86_64
and qemu packages: qemu-kvm-0.12.1.2-2.295.el6_3.10.x86_64 qemu-kvm-tools-0.12.1.2-2.295.el6_3.10.x86_64 qemu-img-0.12.1.2-2.295.el6_3.10.x86_64
Thus my presumption here given the above is that virDomainMigrateToURI2 has not yet been patched and/or back-ported into the EL6.x libvirt/qemu?
virDomainMigrateToURI2 is supported since 0.9.2, but is there a possibility the code is requesting direct migration? That might explain the message, which is then incorrect; this was fixed in [1].
Martin
[1]
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=3189dfb1636da22d426d2fc...
What is "direct migration" exactly, in the context of qemu-kvm?
We are using p2p migration
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/libvirtvm.py;h=fe140...
OK, so that's not the issue, sorry for the confusion. I was thinking it would "somehow" get there. Direct migration doesn't exist in QEMU at all, so it seemed weird, but I can't seem to find any other reason for this failure; will keep searching, though.
In this case, Dead Horse, would you try to migrate a VM (that you do not care much about) using virsh -c qemu+tls://hostname/system migrate --p2p dsthost?
I'd like to see that the problem reproduces this way, too. More of libvirtd.log may help. You may want to disable iptables for a moment, just to eliminate a common cause of failure.