On 3/6/20 6:49 PM, Daniel P. Berrangé wrote:
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.
Instead of PID we can derive the value from the root path, e.g. i-node
of the root dir or some substring of the path hash, say first 6 letters
of md5($root_path). This would guarantee the stability of the prefix
across app restarts (if we assume all root dirs to be on one FS so we
don't have clashing i-node numbers).
Michal
