qemu:///embed and isolation from global components

Andrea Bolognani abologna at redhat.com
Fri Mar 6 17:24:15 UTC 2020


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;

  * it does, however, show up in the output of 'machinectl', with
    class=vm and service=libvirt-qemu;

  * virtlogd is automatically spawned, if not already active, to
    take care of the domain's log file.

The first one is expected, but the other two were a surprise, at
least to me. Basically, what I would expect is that qemu:///embed
would work in a completely isolated way, only interacting with
system-wide components when that's explicitly requested.

In other words, I would expect virtlogd not to be spawned, and the
domain not to be registered with machinectl; at the same time, if
the domain configuration is such that it contains for example

  <interface type='network'>
    <source network='default'/>
    <model type='virtio'/>
  </interface>

then I would expect to see a failure unless a connection to
network:///system had been explicitly and pre-emptively opened, and
not the current behavior which apparently is to automatically open
that connection and spawning virtnetworkd as a result.

As a corollary to this, I would expect that two qemu:///embed
connections using different roots to be able to define domains with
the same name without any problem, but as it stands this is not
possible because machinectl will refuse to register the second one.
There might be other components that freak out as well, that's just
the first one that blocked me.

Are my expectations unreasonable? Or should we work towards making
sure uses of qemu:///embed don't touch global resources and don't
clash with each other?

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list