12:09 p.m.
On Fri, 2020-03-06 at 17:49 +0000, Daniel P. Berrangé wrote:
On Fri, Mar 06, 2020 at 06:24:15PM +0100, Andrea Bolognani wrote:
> * 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.
Agreed. In my case I'll want to use "direct" instead, but "none"
would indeed be a sane default for the embedded driver.
Aside: instead of a per-VM setting, would it make sense for this to
be a connection-level setting? That way, even on traditional libvirt
deployments, the hypervisor admin could eg. opt out of machinectl
registration if they so desire; at the same time, you'd avoid the
situation where most VMs are confined using CGroups but a few are
not, which is probably not a desirable scenario.
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.
Right now we're already doing
qemu-$domid-$domname
where I'm not entirely sure how much $domid actually buys us.
I think machine ids need to be unique per host, not per service,
which is kind of a bummer because the obvious choice would be to
generate a service name based on the embedded root... Michal already
suggested another solution, perhaps that one is more viable.
Anyway, I think it's reasonable to expect that, when it comes to VMs
created via the embedded driver, the same way you'd not be able to
control them via virsh, you'd also not be able to do so via
machinectl, so I'm not too concerned about this once we flip the
default to "none" as discussed above.
> * 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
That's what I'm doing right now and it works well enough, but I'm
afraid that requiring a bunch of setup will discourage developers
from using the embedded driver. We should aim for a reasonable out
of the box experience instead.
> 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.
I'd argue that most users of the embedded driver would probably
prefer it didn't interact with system-wide components: if that
wasn't the case, they'd just use qemu:///system or qemu:///session
instead.
Having a way to turn off those behaviors would certainly be a step
in the right direction, but I think ultimately we want to be in a
situation where developers opt in rather than out of them.
> 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.
Again, I think our defaults for qemu:///embed should be consistent
and conservative: instead of having developers opt out of using
network:///system, they should have to opt in before global
resources are involved.
If we don't do that, I'm afraid developers will lose trust in the
whole qemu:///embed idea. Speaking from my own experience, I was
certainly surprised when I accidentally realized my qemu:///embed
VMs were showing up in the output of machinectl, and now I'm kinda
wondering how many other ways the application I'm working on, for
which the use of libvirt is just an implementation detail, is poking
at the system without my knowledge...
--
Andrea Bolognani / Red Hat / Virtualization