Re: Making QEMU easier for management tools and applications

[Daniel P . Berrangé]

On Sat, Jan 25, 2020 at 12:52:30PM +0100, Paolo Bonzini wrote:
> On 24/01/20 10:50, Daniel P. Berrangé wrote:
> >   * qemu-launcher-$TARGET
> > 
> >     A binary that is able to launch qemu-runtime-$TARGET
> >     with jailers active.
> > 
> >     This has no command line arguments except for a pair
> >     of UNIX socket paths. One is a QMP server, the other
> >     is the path for the QMP of qemu-runtime-$TARGET.
> > 
> >     Commands it processes will be in automatically proxied
> >     through to the qemu-runtime-$TARGET QMP, with appropriate
> >     jailer updates being done in between.
> > 
> 
> What would be the advantage of this over the Libvirt embedded driver?
> Especially if you include in the picture something like libvirt-go-xml
> (or libvirt-GObject, does it still exist?) that hides the XML from the
> code that uses it.

Yes, libvirt-gobject still exists & is used by GNOME Boxes.

> The main complication in the launcher is hotplug, which means that a
> simple "do a couple bind mounts, unshare, drop privileges and forget
> about it" approach doesn't work.  Proxying QMP commands doesn't seem
> that easy, and I don't see much code being shared between the launcher
> and QEMU; if the existing QEMU code is not suitable for Libvirt, it
> wouldn't be suitable for a qemu.git launcher either.

Mostly this suggestion is a response to discussions elsewhere in this
thread expressing a desire for a way to do QEMU jailing natively. In
this proposal I'm describing an approach that might satisfy that desire,
while ignoring whatever exists in the current ecosystem including
libvirt.

So yes, there is clearly overlap here with libvirt, and this tool is
not an easy thing to build to a level which is feature comparable
with what libvirt offers. For this launcher to be credible I think
it would have to be something libvirt were capable of using itself
and that's a challenge. So quite possibly the libvirt embedded driver
is indeed a better bet.  


> Also, as you mentioned earlier, QEMU wants to keep its vocabulary
> lower-level, and therefore the launcher's vocabulary would end up
> diverging from QEMU.  Some example:
> 
> - QEMU wants a qemu-pr-helper socket path, the launcher would take care
> of launching qemu-pr-helper itself
> 
> - QEMU wants the complete configuration on the migration destination,
> the launcher might take care of sending it from the source?
> 
> At this point, you get something that looks very much like Libvirt and,
> especially if you include live migration, it has to take into account
> the same compatibility considerations as Libvirt.

Yes indeed.

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