11:49 a.m.
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.
* virtlogd is automatically spawned, if not already active, to
take care of the domain's log file.
This is trickier. The use of virtlogd was to fix a security DoS
where malicious QEMU can write to serial console, or trigger
QEMU to write to stdout/err, such that it exhausts the host
filesystem. IIUC, virtlogd should still end up writing to
the logfile path associated with the embedded driver root
directory prefix, so there shouldn't be a filename clash
unless I screwed up.
Since introducing virtlogd, however, I did think of a different
strategy, which would be to connect a FIFO to QEMU as the log
file FD. The QEMU driver itself can own the other end of the FIFO
and do rollover.
Of course you can turn off virtlogd via qemu.conf
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.
The goal wasn't explicitly to avoid system-wide components,
but it certainly was intended to avoid clashing resources.
IOW, machined, virtlogd are both valid to use, as long as
the resource clashes are avoided. We should definitely have
a way to disable these too.
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.
The QEMU embedded driver is explicitly intended to be able to
interact with other global secondary drivers.
If you don't want to use virtnetworkd, then you won't be
creating such an <interface> config in the first place.
The app will have the option to open an embedded seconary
driver if desired. Some of the drivers won't really make
sense as embedded things though, at least not without
extra work. ie a embedded network or nwfilter driver has
no value unless your app has moved into a new network
namespace, as otherwise it will just fight with the
global network driver.
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.
Yes, that is definitely needed to work for resources created by
those drivers, so we must solve the name clashes for example.
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 :|