[libvirt] Qemu capability probes lifecycle should be tied to libvirtd
Hi, on libvirt 3.10 I see a set of qemu processes used for capability probing [1] (in my case 8x x86_64 and 3xi386 which seems a lot, but ok). But when stopping the service those still stay around [2]. That is correct for guests that were started by libvirt as their lifecycle isn't tied to the libvirtd service. But those probes are IMHO tied to the service. At first this might seem non-relevant, but e.g. when users want to uninstall they might think on stopping their guests, but I'd assume no one will clean up the capability probes before the hard removal. But then on the removal scripts will run into issues e.g. failing to remove users as they are still in use by those qemu processes. Right now Distro's have to be aware to clean those up at least at times where packaging would expect them to be gone, but I wanted to ask if there would be a consensus that it would be "correct" to stop the processes on a libvirtd stop? [1]: http://paste.ubuntu.com/26208661/ [2]: http://paste.ubuntu.com/26208664/ P.S. I discussed this on IRC last Friday, but other than Michael confirming the current state there was no further traction on the discussion yet. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
On Mon, Dec 18, 2017 at 03:22:57PM +0100, Christian Ehrhardt wrote:
Hi, on libvirt 3.10 I see a set of qemu processes used for capability probing [1] (in my case 8x x86_64 and 3xi386 which seems a lot, but ok). But when stopping the service those still stay around [2].
That is correct for guests that were started by libvirt as their lifecycle isn't tied to the libvirtd service. But those probes are IMHO tied to the service.
At first this might seem non-relevant, but e.g. when users want to uninstall they might think on stopping their guests, but I'd assume no one will clean up the capability probes before the hard removal. But then on the removal scripts will run into issues e.g. failing to remove users as they are still in use by those qemu processes.
Right now Distro's have to be aware to clean those up at least at times where packaging would expect them to be gone, but I wanted to ask if there would be a consensus that it would be "correct" to stop the processes on a libvirtd stop?
Well in general they should all be killed immediately after libvirt finishes probing the capabilities - they should only live for a fraction of a second. If these are getting stuck, it is an indication of a bug somewhere in either QEMU or libvirt. So from that POV, the "correct" way to stop them would be to find and fix the bug that is preventing them being killed. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, Dec 18, 2017 at 3:35 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Mon, Dec 18, 2017 at 03:22:57PM +0100, Christian Ehrhardt wrote:
Hi, on libvirt 3.10 I see a set of qemu processes used for capability probing [1] (in my case 8x x86_64 and 3xi386 which seems a lot, but ok). But when stopping the service those still stay around [2].
That is correct for guests that were started by libvirt as their lifecycle isn't tied to the libvirtd service. But those probes are IMHO tied to the service.
At first this might seem non-relevant, but e.g. when users want to uninstall they might think on stopping their guests, but I'd assume no one will clean up the capability probes before the hard removal. But then on the removal scripts will run into issues e.g. failing to remove users as they are still in use by those qemu processes.
Right now Distro's have to be aware to clean those up at least at times where packaging would expect them to be gone, but I wanted to ask if there would be a consensus that it would be "correct" to stop the processes on a libvirtd stop?
Well in general they should all be killed immediately after libvirt finishes probing the capabilities - they should only live for a fraction of a second.
Yes that is how it always was before. I expected something in a more recent libvirt was changed to keep them around and thereby debugged in the wrong direction. Just recently ~1h ago it resolved in my test environment to no more show up hanging after a restart of libvirtd.
If these are getting stuck, it is an indication of a bug somewhere in either QEMU or libvirt. So from that POV, the "correct" way to stop them would be to find and fix the bug that is preventing them being killed.
I wish I'd have thought that way of it while it still occurred. Thanks a lot for the hint Daniel, now at least everything makes sense. Next time I see this I know which way to look at it and will gather debug data - for now it seems unreproducible even in a new test environment :-/
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
participants (2)
-
Christian Ehrhardt -
Daniel P. Berrange