Description of problem: When trying to create a new RHEL / CentOS 5.8 guest VM on a Fedora 19 host, I get, Unable to complete install: 'monitor socket did not show up: No such file or directory' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 100, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 1920, in do_install guest.start_install(False, meter=meter) File "/usr/share/virt-manager/virtinst/Guest.py", line 1134, in start_install noboot) File "/usr/share/virt-manager/virtinst/Guest.py", line 1202, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2782, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: monitor socket did not show up: No such file or directory Version-Release number of selected component (if applicable): $ uname -r 3.9.9-302.fc19.x86_64 $ rpm -qa | grep virt-manager virt-manager-common-0.10.0-1.fc19.noarch virt-manager-0.10.0-1.fc19.noarch $ rpm -qa | grep kvm libvirt-daemon-kvm-1.0.5.2-1.fc19.x86_64 qemu-kvm-1.4.2-4.fc19.x86_64 How reproducible: Put host system under IO pressure and try to create a new guest VM. Expected results: Things should just work :-)
Moving to the upstream tracker. The qemu driver has internal timeouts here waiting for the monitor socket to appear. I'm not really sure what the solution is though, we can't wait forever because qemu might hang before creating the monitor socket.
Hi, I have come across this bug as well. the default code behavior is wait for 3 seconds and if the socket is not opened yet, print this error and terminate. the code is in file named src/qemu/qemu_monitor.c in function qemuMonitorOpenUnix. In 2009 there was a patch that added the original 3 seconds retry, the patch can be found here: http://www.redhat.com/archives/libvir-list/2009-July/msg00335.html I have added a patch with this solution: the default behavior stays the same, but a user can add a configuration variable to qemu.conf and change the timeout value. every system needs a different value according to their system configuration but anyway 3 seconds is not suitable for all cases. I am attaching my patch. Pavel Fux.
Created attachment 843475 [details] patch
Pavel - would it be possible for you to post that patch (by using "git send-email") to libvir-list? That is the standard method for getting patches into libvirt; a patch buried in an upstream tracker bug report often goes unnoticed / beyond the attention span of libvirt developers for quite awhile, but we're all monitoring the mailing list constantly.
Ah, never mind. Now that I've caught up on *all* my libvirt mail, I see that you've already sent it to the list :-) https://www.redhat.com/archives/libvir-list/2013-December/msg01326.html
*** Bug 1048818 has been marked as a duplicate of this bug. ***
From the dup'd bug: Check out the number of hits for: https://www.google.co.uk/search?q="monitor+socket+did+not+show+up"
Hopefully fixed upstream by v1.2.1-11-gfe89b68: commit fe89b687a02d1a8e1dce695a67b4f9d2c254d7b9 Author: Martin Kletzander <mkletzan> Date: Thu Jan 9 07:57:59 2014 +0100 qemu: Change the default unix monitor timeout
(In reply to Martin Kletzander from comment #11) > Hopefully fixed upstream by v1.2.1-11-gfe89b68: > > commit fe89b687a02d1a8e1dce695a67b4f9d2c254d7b9 > Author: Martin Kletzander <mkletzan> > Date: Thu Jan 9 07:57:59 2014 +0100 > > qemu: Change the default unix monitor timeout at least in my case changing the value to 30 seconds is not enough, we had to change it to 5 minutes I suggest you let the user change it as he wishes.
(In reply to Pavel Fux from comment #12) Thank you for pointing that out, but may I ask you to raise this issue on the upstream libvirt list? Although I'm afraid that 5 minute timeout already borders with over-commiting the host machine. If qemu takes so long to start, I'm thinking this might be handled in a different way.
libvirt-1.1.3.3-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libvirt-1.1.3.3-2.fc20
Package libvirt-1.1.3.3-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.1.3.3-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1264/libvirt-1.1.3.3-2.fc20 then log in and leave karma (feedback).
libvirt-1.1.3.3-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.