Re: qemu:///embed and isolation from global components

On Fri, Mar 06, 2020 at 06:24:15PM +0100, Andrea Bolognani wrote: > Recently I've been working on integrating qemu:///embed into an > application. It's been reasonably smooth so far :) > > There's one thing, however, that has caused a bit of confusion, and > I would like to clarify whether my expectations are incorrect, there > are genuine bugs in the implementation that need to be addressed, or > maybe the experimental nature of embedded driver support results in > not all scenarios having yet been considered and catered for. > > Using virt-qemu-run as an example, when I run it as root I see that > > * the domain doesn't show up in the output of 'virsh list' for > qemu:///system; This is good. > * it does, however, show up in the output of 'machinectl', with > class=vm and service=libvirt-qemu; This is bad. It is one of the gaps we need to deal with. A long while back I proposed a domain XML option for this: https://www.redhat.com/archives/libvir-list/2017-December/msg00729.html <resource register="none|direct|machined|systemd"/> The "none" case meant inherit the cgroups placement of the parent libvirtd (or now the app using the embedded driver), and would be a reasonable default for the embedded case. For the other cases, we certainly need to do something to ensure uniqueness. This is possibly as simple as including a fixed prefix like "qemu-$PID" where $PID is the app embedding the driver. That said, we support closing the app, and re-starting using the same embedded driver directory, which would change PID.