search for: qemumonitoropenunix

....github.com/bmb/08fbb6b6136c758d027e90ff139d5701 On 15 February 2017 at 00:47, Michal Privoznik <mprivozn@redhat.com> wrote: > I don't think I understand this. Who is running the other job? I mean, > I'd expect qemu fail to create the socket and thus hitting 30s timeout > in qemuMonitorOpenUnix(). Yes you're right, I just blindly started looking for 30s constants in the code and that one seemed the most obvious but I had not tried to trace it all the way back to the domain start job or checked the debug logs yet, sorry. So looking a bit more carefully I see the real issue is in src/q...

...1 > > > > On 15 February 2017 at 00:47, Michal Privoznik <mprivozn@redhat.com> wrote: > >> I don't think I understand this. Who is running the other job? I mean, > >> I'd expect qemu fail to create the socket and thus hitting 30s timeout > >> in qemuMonitorOpenUnix(). > > > > Yes you're right, I just blindly started looking for 30s constants in > > the code and that one seemed the most obvious but I had not tried to > > trace it all the way back to the domain start job or checked the debug > > logs yet, sorry. So looking a b...

Hi all, In IRC last night Dan helpfully confirmed my analysis of an issue we are seeing attempting to launch high memory KVM guests backed by hugepages... In this case the guests have 240GB of memory allocated from two host NUMA nodes to two guest NUMA nodes. The trouble is that allocating the hugepage backed qemu process seems to take longer than the 30s QEMU_JOB_WAIT_TIME and so libvirt then

...on, then we moved it back; however, that caused changing the inode ids of the files inside /var/lib/libvirt/qemu including the socket files ( <instance>.monitor ) of the running VMs. The problem we are facing is that when libvirtd is restarted it terminates the running VMs with "error : qemuMonitorOpenUnix:315 : monitor socket did not show up.: Connection refused” We are trying to find a workaround so that when libvirtd is restarted it doesn’t stop the running VMs. We are running libvirt 0.9.13 Any help is appreciated. Thanks, Gavin

...b6136c758d027e90ff139d5701 > > On 15 February 2017 at 00:47, Michal Privoznik <mprivozn@redhat.com> wrote: >> I don't think I understand this. Who is running the other job? I mean, >> I'd expect qemu fail to create the socket and thus hitting 30s timeout >> in qemuMonitorOpenUnix(). > > Yes you're right, I just blindly started looking for 30s constants in > the code and that one seemed the most obvious but I had not tried to > trace it all the way back to the domain start job or checked the debug > logs yet, sorry. So looking a bit more carefully I see t...

...;> > On 15 February 2017 at 00:47, Michal Privoznik <mprivozn@redhat.com> wrote: >> >> I don't think I understand this. Who is running the other job? I mean, >> >> I'd expect qemu fail to create the socket and thus hitting 30s timeout >> >> in qemuMonitorOpenUnix(). >> > >> > Yes you're right, I just blindly started looking for 30s constants in >> > the code and that one seemed the most obvious but I had not tried to >> > trace it all the way back to the domain start job or checked the debug >> > logs yet, so...

...efault (I don't remove the default /dev/vhost-net directory) The VHOST file descriptor is present in "/dev/vhost-0" directory instead of the default "/dev/vhost-net". When I try to give vhostfd in the XML I get a different error: 2014-07-24 10:42:22.507+0000: 3181: error : qemuMonitorOpenUnix:293 : failed to connect to monitor socket: No such process 2014-07-24 10:42:22.507+0000: 3181: error : qemuProcessWaitForMonitor:1806 : internal error process exited while connecting to monitor: qemu-system-x86_64: -netdev type=tap,id=net1,script=no,downscript=no,ifname=port4,vhost=on,vhostfd=/dev/...

On Thu, Jul 24, 2014 at 03:48:06PM +0500, Asadullah Hussain wrote: > Let me clarify my question, I am using unmodified stock qemu (1.4.0) and > only the location of vhost file descriptor is different from default (I > don't remove the default /dev/vhost-net directory) > > The VHOST file descriptor is present in "/dev/vhost-0" directory instead of > the default

...argets mainline >> QEMU, we only target mainline kernel / standard device layout >> >> ​I was able to change my device name to /dev/vhost-net but still I get > the error, the error itself isn't telling much about the problem: > 2014-07-24 10:41:35.970+0000: 3183: error : qemuMonitorOpenUnix:293 : > failed to connect to monitor socket: No such process > 2014-07-24 10:41:35.970+0000: 3183: error : qemuProcessWaitForMonitor:1806 > : internal error process exited while connecting to monitor: > qemu-system-x86_64: -netdev > type=tap,id=net1,script=no,downscript=no,ifname=por...

​The qemu that I am using isn't modified at all. It's the VHOST drivers that are mounted elsewhere i.e., not on default /dev/vhost-net. Here is the command that I use to launch my qemu VM: qemu-system-x86_64 -cpu host -boot order=c -hda /root/Disks/ubuntu1.qcow2 -m 1024M -smp 2 --enable-kvm -name 'client 1' -nographic -vnc :2 -net none -no-reboot -mem-path /dev/hugepages

...9 dpdk-OptiPlex-5040 libvirtd.service: 1530: debug : virCommandHandshakeWait:2663 : Wait for handshake on 26 Mar 28 18:05:29 dpdk-OptiPlex-5040 libvirtd.service: 1530: debug : virCommandHandshakeNotify:2729 : Notify handshake on 30 *Mar 28 18:05:29 dpdk-OptiPlex-5040 libvirtd.service: 1530: error : qemuMonitorOpenUnix:374 : failed to connect to monitor socket: No such process* *Mar 28 18:05:29 dpdk-OptiPlex-5040 libvirtd.service: 1530: error : qemuProcessReportLogError:1709 : internal error: process exited while connecting to monitor: 2019-03-28T12:35:29.176289Z qemu-system-x86_64: -chardev socket,id=charnet0,pa...

...Just as libvirt only targets mainline > QEMU, we only target mainline kernel / standard device layout > > ​I was able to change my device name to /dev/vhost-net but still I get the error, the error itself isn't telling much about the problem: 2014-07-24 10:41:35.970+0000: 3183: error : qemuMonitorOpenUnix:293 : failed to connect to monitor socket: No such process 2014-07-24 10:41:35.970+0000: 3183: error : qemuProcessWaitForMonitor:1806 : internal error process exited while connecting to monitor: qemu-system-x86_64: -netdev type=tap,id=net1,script=no,downscript=no,ifname=port4,vhost=on: vhost-net re...

...l: libfcoe_device_notification: NETDEV_UNREGISTER vnet2 Log messages in /var/log/libvirt/libvirtd.log are similar to the console 2012-06-16 19:56:39.807+0000: 32175: error : virNetSocketReadWire:911 : End of file while reading data: Input/output error 2012-06-16 20:15:23.672+0000: 32176: error : qemuMonitorOpenUnix:290 : failed to connect to monitor socket: No such process 2012-06-16 20:15:23.672+0000: 32176: error : qemuProcessWaitForMonitor:1289 : internal error process exited while connecting to monitor: char device redirected to /dev/pts/7 inet_listen_opts: bind(ipv4,127.0.0.1,5902): Cannot assign request...

...irtio-disk0: Could not open '/home/greg/Downloads/Fedora/f27/Fedora-Workstation-Live-x86_64-27- 1.6.iso': Permission denied The /var/log/message entries associated with the above error message is the following : Jul 15 08:55:37 HmGp libvirtd: 2018-07-15 13:55:37.922+0000: 1643: error : qemuMonitorOpenUnix:385 : failed to connect to monitor socket: No such process Jul 15 08:55:37 HmGp libvirtd: 2018-07-15 13:55:37.927+0000: 1643: error : qemuProcessReportLogError:1912 : internal error: process exited while connecting to monitor: 2018-07-15T13:55:37.836269Z qemu-kvm: -drive file=/home/greg/Downloads/...

...from libvirtd log is below: 2015-01-08 08:07:32.376+0000: 22552: warning : qemuDomainObjTaint:1890 : Domain id=19 name='ceph' uuid=e4412366-1f16-4c54-b121-dfb565672427 is tainted: high-privileges Detaching after fork from child process 23015. 2015-01-08 08:07:32.684+0000: 22552: error : qemuMonitorOpenUnix:309 : failed to connect to monitor socket: No such process 2015-01-08 08:07:32.684+0000: 22552: error : qemuProcessWaitForMonitor:2207 : internal error: process exited while connecting to monitor: 2015-01-08 08:07:32.684+0000: 22552: error : virDBusCall:1542 : error from service: TerminateMachine...