Re: qemu:///embed and isolation from global components

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.

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