qemu:///embed and isolation from global components

[Daniel P. Berrangé]

On Thu, Mar 12, 2020 at 01:50:49PM +0100, Andrea Bolognani wrote:
> 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?

Dunno how well it will still apply, but yeah, something approximately
the same as that would suit us


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 :|