Re: qemu:///embed and isolation from global components
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