Bug 1180085

 Thread-15::DEBUG::2015-01-08 10:26:42,134::BindingXMLRPC::1142::vds::(wrapper)  client [127.0.0.1]::call setupNetworks with ({'rhevm': {'nic': 'eth0', 'netmask': '255.255.252.0', 'bootproto': 'none', 'ipaddr': '10.34.60.233'}}, {}, {'connectivityCheck': False}) {}
 Thread-15::ERROR::2015-01-08 10:26:42,210::BindingXMLRPC::1161::vds::(wrapper) unexpected error
 Traceback (most recent call last):
  File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 1145, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 563, in setupNetworks
    return api.setupNetworks(networks, bondings, options)
  File "/usr/share/vdsm/API.py", line 1385, in setupNetworks
    supervdsm.getProxy().setupNetworks(networks, bondings, options)
  File "/usr/share/vdsm/supervdsm.py", line 50, in __call__
    return callMethod()
  File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>
    **kwargs)
  File "<string>", line 2, in setupNetworks
  File "/usr/lib64/python2.6/multiprocessing/managers.py", line 726, in _callmethod
    kind, result = conn.recv()
 EOFError

Looks like an issue within VDSM. moving to that component.

It seems that supervdsm crashed while setting up the network. Please attach supervdsm.log

Created attachment 982327 [details]
supervdsm log

The plot thickens. supervdsm took itself down since its connection to libvirt was broken.

MainProcess|Thread-15::CRITICAL::2015-01-08 10:26:42,140::libvirtconnection::137::root::(wrapper) taking calling process down.
MainThread::DEBUG::2015-01-08 10:26:42,140::supervdsmServer::453::SuperVdsm.Server::(main) Terminated normally
MainProcess|Thread-15::DEBUG::2015-01-08 10:26:42,142::libvirtconnection::143::root::(wrapper) Unknown libvirterror: ecode: 1 edom: 7 level: 2 message: internal error client socket is closed

Could you attach libvirtd.conf, libvirtd.log and supply libvirt's version?

Does /var/log/message has any trace of a libvirtd crash?

Created attachment 982841 [details]
libvirtd configuration file

Created attachment 982843 [details]
libvirtd log

libvirt-0.10.2-46.el6_6.2.x86_64

/var/log/messages doesn't show any error or crash from that day

Is this libvirtd.log in its entirety?

2015-01-21 12:16:21.097+0000: 1566: error : virNetSocketNewListenTCP:239 : Unable to resolve address '0.0.0.0' service '16514': Address family for hostname not supported

if so, could you set

 log_outputs="1:file:/var/log/libvirt/libvirtd.log"
 auth_unix_rw="none"

in libvirtd.conf, pkill libvirtd, and try to reproduce?
Before installation, does `virsh list` succeed?

[root@pm-upgrade2 ~]# virsh list
error: Failed to reconnect to the hypervisor
error: no valid connection
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

When I changed the two lines I couldn't reproduce this bug, although I found a different one:
[ ERROR ] Failed to execute stage 'Closing up': Cannot set temporary password for console connection. The VM may not have been created: please check VDSM logs

Created attachment 983306 [details]
new vdsm log

error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory

means that libvirtd failed to start. we should debug this issue first - does the more verbose libvirtd.log say anything?

I tried to reproduce this issue but I couldn't, the virsh list now succeeds although it prints no domains. However I reproduced the issue I found before (comment #11)

Could you supply the logs of the new reproduction?

Created attachment 985194 [details]
VDSM log

Created attachment 985195 [details]
supervdsm log

It seems that qemu process crashed right after startup. Can you attach qemu and libvirt logs? Could it be that your host does not have enough ram+swap space for this VM?

Thread-77::DEBUG::2015-01-28 13:22:08,363::libvirtconnection::143::root::(wrapper) Unknown libvirterror: ecode: 1 edom: 10 level: 2 message: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
Cannot set up guest memory 'pc.ram': Cannot allocate memory

Sorry, it really didn't have enough memory. Must have been fixed with something else because it works fine now.