VDSM built from commit: c343e1833f7b6e5428dd90f14f7807dca1baa0b4 works Current VDSM built from master does not work. I could try spending some time trying to bisect and find out where the breakage occurred I suppose. - DHC On Sun, Feb 3, 2013 at 10:13 AM, Martin Kletzander <mkletzan@redhat.com>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
same package versions originally indicated. The difference here is
On 02/03/2013 08:40 AM, Dan Kenigsberg wrote: the 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