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?
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. It's easier to make the case for virsh because the expectation is that, if they show up, you can perform various operations such as edit or dumpxml or whatever on them; for machinectl, since the only operation that seems to work is poweroff anyway, and that's apparently achieved not by calling libvirt APIs but by killing the QEMU process directly, then the case is not as obvious - but I think the same rationale still applies.
Right now we're already doing
qemu-$domid-$domname
where I'm not entirely sure how much $domid actually buys us.
IIRC $domid was a hack because at one time we had problems with systemd not cleaning up the transient scope when QEMU was killed. This would prevent libvirt starting the guest again thereafter. I can't remember now if this was a bug we fixed in systemd or libvirt or both or neither.
It was introduced by bd773e74f0d1d1b9ebbfcaa645178316b4f2265c and the commit message links to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=68370 which looks like fixed in systemd.
That doesn't look right.
From what I can gather, $domid was added much more recently, specifically in c3bd0019c0e3f080dbf0d4bd08245ffb2daa2765, in order to addresses https://bugzilla.redhat.com/show_bug.cgi?id=1282846.
While I get the overall idea behind the changes, I don't quite understand the rationale behind adding $domid specifically...
I see! It would be neat if we could get rid of it, assuming of course it's no longer needed on the platforms we target.
I don't think it's that simple. Machinectl poses some limitations on the name: either it has to be a FQDN or a simple name without any dots. And according to our code the strlen() must be <= 64 (don't know if that comes from machinectl or is just our own limitation). Therefore, if you have two domains which names would clash after our processing, the domain ID guarantees unique strings are passed to machined.
... but here it is! Makes sense now :) [...]
There's no question that we must fix the machined problem.
I will try to post patches for this.
That'd be awesome! Thanks in advance :) -- Andrea Bolognani / Red Hat / Virtualization