8:27 p.m.
note ignore the IP diff in the ssh host auth --> copy/paste fail ;)
- DHC
On Thu, Jan 31, 2013 at 11:25 AM, Dead Horse
<deadhorseconsulting(a)gmail.com>wrote:
Doh, brain fart VDSM is not involved here for the purposed of the
needed
test.
Here is my initial whack at it:
Source Node:
virsh # list
Id Name State
----------------------------------------------------
1 sl63 running
virsh # migrate --p2p sl63 qemu+ssh://192.168.1.2/system
error: operation failed: Failed to connect to remote libvirt URI
qemu+ssh://3.57.111.32/system
virsh # migrate --live sl63 qemu+ssh://192.168.1.2/system
The authenticity of host '3.57.111.32 (192.168.1.2)' can't be established.
RSA key fingerprint is e5:1d:b3:e5:38:5f:e1:8b:73:26:9e:15:c8:0a:2d:ac.
Are you sure you want to continue connecting (yes/no)? yes
root(a)192.168.1.2's password:
Please enter your authentication name: vdsm@ovirt
Please enter your password:
virsh #
Dest Node After migrate --live:
virsh # list
Id Name State
----------------------------------------------------
2 sl63 running
virsh #
On Thu, Jan 31, 2013 at 10:38 AM, Dead Horse <
deadhorseconsulting(a)gmail.com> wrote:
> 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(a)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=3189dfb1636da22d426d...
>> > >
>> > > 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=fe...
>> > >
>> >
>> > 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.
>>
>
>