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
    verbose=self.__verbose
  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

Responses

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.

 

--Christian

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