Re: qemu:///embed and isolation from global components
On Thu, Mar 12, 2020 at 12:57:36PM +0100, Andrea Bolognani wrote:
On Wed, 2020-03-11 at 17:32 +0100, Michal Privoznik wrote:
> I still don't quite see the value in machinectl (maybe because I'm not
> using systemd :-D)
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.
> but anyway - it's a system-wide monitor of virtual
> machines. Therefore it makes sense to register a domain started under
> qemu:///embed there. I don't view embed mode as a way of starting VMs
> secretly. It's a way of starting VMs privately and that's a different
> thing. Other users might learn that my app is running a VM (plain 'ps'
> would give it away), but they can not mangle with it in any way, e.g.
> change its XML.
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.
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 :|