[Dropped Peter from CC. Please don't CC individual developers unless they've explicitly requested that you do so.] On Mon, 2020-02-17 at 17:50 +0000, Richard W.M. Jones wrote:
Build libvirt from git (ccf7567329f).
Using the libvirt ‘run’ script, run something like libguestfs-test-tool. I think basically any command which runs a guest will do. NB These commands are all run as NON-root:
killall libvirtd lt-libvirtd virtlogd lt-virtlogd ./build/run libguestfs-test-tool
Now there will be a lt-virtlogd process using 100% of CPU:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2572972 rjones 20 0 47880 16256 14516 R 100.0 0.1 0:19.27 lt-virt+
It's actually worse than that: not only virtlogd usese an unwarranted amount of CPU, but it also keeps the log file for the domain busy, thus preventing the same domain from being started again: $ virsh start alpine Domain alpine started $ virsh destroy alpine Domain alpine destroyed $ virsh start alpine error: Failed to start domain alpine error: can't connect to virtlogd: Cannot open log file: '/var/log/libvirt/qemu/alpine.log': Device or resource busy $ sudo lsof | grep alpine.log virtlogd 146845 root 16w REG 253,0 35103 17195654 /var/log/libvirt/qemu/alpine.log $ Restarting virtlogd makes thing operational again: $ sudo systemctl restart virtlogd $ virsh start alpine Domain alpine started $ My guess is that virtlogd doesn't realize the QEMU process is gone, and sits there spinning forever waiting for some output that will never arrive. -- Andrea Bolognani / Red Hat / Virtualization