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