[Users] VM migrations failing

[Martin Kletzander]

On 02/03/2013 08:40 AM, Dan Kenigsberg wrote:
> On Fri, Feb 01, 2013 at 11:44:08PM +0100, Martin Kletzander wrote:
>> On 02/01/2013 09:29 PM, Dead Horse wrote:
>>> To test further I loaded up two more identical servers with EL 6.3 and the
>>> same package versions originally indicated. The difference here is that I
>>> did not turn these into ovirt nodes. EG: installing VDSM.
>>>
>>> - All configurations were left at defaults on both servers
>>> - iptables and selinux disabled on both servers
>>> - verified full connectivty between both servers
>>> - setup ssh (/root/authorized keys) between the servers --> this turned out
>>> to be the key!
>>>
>>> Then using syntax found here:
>>> http://libvirt.org/migration.html#flowpeer2peer
>>> EG: From the source server I issued the following:
>>>
>>
>> So your client equals to the source server, that makes us sure that the
>> connection is made on the same network for p2p and non-p2p migration.
>>
>>> virsh migrate --p2p sl63 qemu+ssh://192.168.1.2/system
>>>
>>
>> You're using ssh transport here, but isn't vdsm using tcp or tls?
> 
> It is!
> 

So then testing it with '+ssh' does not help much.  But at least we know
the addresses are reachable.

>> According to the config file tcp transport is enabled with no
>> authentication whatsoever...
>>
>>> It fails in exactly the same way as previously indicated when the
>>> destination server does not have an ssh rsa pub ID from the source system
>>> in it's /root/.ssh/authorized_keys file.
>>> However once the ssh rsa pub ID is in place on the destination system all
>>> is well and migrations work as expected.
>>>
>>
>> ..., which would mean you need no ssh keys when migrating using tcp
>> transport instead.
>>
>> Also during p2p migration the source libvirt daemon can't ask you for
>> the password, but when not using p2p the client is connecting to the
>> destination, thus being able to ask for the password and/or use
>> different ssh keys.
>>
>> But it looks like none of this has anything to do with the problem as:
>>
>>  1) as you found out, changing vdsm versions makes the problem go
>> away/appear and
> 
> I've missed this point. Which version of vdsm makes it go away?
> 

Sorry, I've got it stuck in my head that part of the thread was about
it, but when going through the mail now it makes less sense than before.
 I probably understood that from [1] and maybe some other sentence that
mixed in my head, but was related to the ssh migration.

Sorry for that,
Martin

[1] http://www.mail-archive.com/users@ovirt.org/msg06105.html