Re: [Users] VM migrations failing

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