RHEV-M 3.1 :: Cannot Migrate Host

Latest response

I'm testing out RHEV-M 3.1 (we are running 3.0 in production) and...

Try as I might; I cannot migrate a VM to another host.

I get an error saying "Could Not Connect To Peer Host (VM: test1, Source vr2.example.org)" on the console

Here is the VDSM log.

Thread-3190::ERROR::2013-02-06 10:47:32,948::vm::146::vm.Vm::(_setupVdsConnection) vmId=`9072e171-bf05-4dd4-9c96-a3d76a00f16b`::Error initiating connection
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 141, in _setupVdsConnection
    status = self.destServer.getVmStats(self._vm.id)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1382, in _parse_response
    response = file.read(1024)
  File "/usr/lib64/python2.6/socket.py", line 383, in read
    data = self._sock.recv(left)
  File "/usr/lib64/python2.6/ssl.py", line 215, in recv
    return self.read(buflen)
  File "/usr/lib64/python2.6/ssl.py", line 136, in read
    return self._sslobj.read(len)
SSLError: The read operation timed out
Thread-3190::DEBUG::2013-02-06 10:47:32,949::libvirtvm::283::vm.Vm::(_getDiskLatency) vmId=`9072e171-bf05-4dd4-9c96-a3d76a00f16b`::Disk vda latency not available
Thread-3190::DEBUG::2013-02-06 10:47:32,956::vm::189::vm.Vm::(_prepareGuest) vmId=`9072e171-bf05-4dd4-9c96-a3d76a00f16b`::migration Process begins
Thread-3190::DEBUG::2013-02-06 10:47:32,976::vm::260::vm.Vm::(run) vmId=`9072e171-bf05-4dd4-9c96-a3d76a00f16b`::migration semaphore acquired
Thread-3346::DEBUG::2013-02-06 10:47:35,278::task::568::TaskManager.Task::(_updateState) Task=`66a8f842-f8c2-47af-bf78-b1db48ce4990`::moving from state init -> state preparing


Looks like an SSL issue. Can you make sure the host's time/date is set correctly, and that it's hostname/IP are set and resolvable in DNS (A and PTR)

I have verified that


DNS match (both foward and reverse) and that NTP is running and all the time is synced.

Still the same problems.



In that case logs need to be reviewed, but it's a large set of information to post here. I suggest you open a support case for this