qemu:///embed and isolation from global components

[Andrea Bolognani]

On Thu, 2020-03-12 at 12:09 +0000, Daniel P. Berrangé wrote:
> On Thu, Mar 12, 2020 at 12:57:36PM +0100, Andrea Bolognani wrote:
> > Honestly, so far I haven't been able to figure out the use case for
> > registering libvirt VMs with machined either :)
> > 
> > Most of the operations are either not supported (login, shell, start)
> > or do not work as expected (list --all, reboot), so all you can
> > really do is list the subset of libvirt VMs that happen to be running
> > and power them off. I can't really imagine that being very useful to
> > anyone... Am I missing something?
> 
> Yeah, pretty much all you get is a way to report & terminate VMs via
> systemd commands. A few others things could be wired up, but no one
> ever made an effort todo so and I don't think it is worth it.
> 
> So I'm getting inclined to consider machined a failed experiment from
> POV of VMs - still makes sense for containers. That said I'd still
> keep using it, because we need systemd to deal with cgroups creation
> no matter what, and its no worse to talk to systemd via machined
> than directly.

Would it make sense to default to not registering with machined? It
would probably be more honest of us, considering how severely limited
the functionality is... Set expectations right and all that. The fact
that not even reboot, one of the only three operations available
through machinectl, works correctly (it will shut down the VM instead
of restarting it) leads me to believe that nobody is actually using
this anyway.

> > Of course it's not about secrecy, but for the same reasons
> > qemu:///embed VMs don't show up in the output of 'virsh list' it
> > also makes sense for them to be omitted from that of 'machinectl
> > list', I think.
> 
> Yes, I agree with this.
> 
> The only even slightly plausible use case for machinectl to list
> a full set of guest OS running on the host. This just about makes
> sense for traditional data center / cloud virt use case. I don't
> think it makes sense when KVM is merely used as an infrastructure
> building block embedded in applications. As such, I think we should
> NOT register with machined or systemd at all, for embedded VMs, without
> an explicit opt-in. We should flip to just inheriting the calling
> processes cgroups context, to align with the goal that embedded driver
> should generally aim to inherit all process context.

Cool.

Let's just make sure there is a way for qemu:///embed users to
explicitly opt-in into qemu:///system-style CGroup handling,
hopefully without machined getting in the way, before we flip the
switch. Are you going to revive the old patch you linked to a few
day ago?

-- 
Andrea Bolognani / Red Hat / Virtualization