Re: Redesign of QEMU startup & initial configuration

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Mark Burton <mark.burton@greensocs.com>
Cc: "Damien Hedde" <damien.hedde@greensocs.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Mirela Grujic" <mirela.grujic@greensocs.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: Redesign of QEMU startup & initial configuration
Date: Fri, 10 Dec 2021 14:26:58 +0000	[thread overview]
Message-ID: <YbNjsq6hUWSIDtVt@redhat.com> (raw)
In-Reply-To: <A220E257-3378-4E43-86B6-4ED84E3CA3E8@greensocs.com>

On Fri, Dec 10, 2021 at 03:15:50PM +0100, Mark Burton wrote:
> 
> 
> > On 10 Dec 2021, at 12:25, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > 
> > On Fri, Dec 10, 2021 at 09:34:41AM +0100, Paolo Bonzini wrote:
> >> On 12/9/21 20:11, Daniel P. Berrangé wrote:
> >>>>    They still need to bootstrap a QMP monitor, and for that, CLI is fine
> >>>>    as long as it's simple and stable.
> >> 
> >> I would go a step further and say that the QMP monitor socket should be
> >> created by whoever invoked QEMU and passed down via systemd's socket
> >> activation protocol, with a fallback to stdin/stdout.
> 
> Could we take one more small step …. 
> (Sorry - I’m sure you’ll all hate me for pointing at the elephant in the room….)
> 
> Why should QEMU itself handle this? You may want to use systemd
> socket activation, I may be happier with a different approach.
> The commonality is surely at the level of the underlying QAPI.
> Being able to build QEMU as a ….. library, with a single entry
> point to access the QAPI would allow the QEMU community to focus
> on it’s key ‘kernel’, while others are able to propose integrated
> solutions like activation through systemd an/or whatever libvirt
> does etc etc…. By all means there can be a systemd-qemu project….
> But does that have to be baked into QEMU?

Systemd activation doesn't really tie QEMU into systemd at
all. The socket passing scheme is trivial and both sides are
easily implemented by any application. It is reasonable to
use in QEMU on any UNIX platform at least. Windows is probably
the only complication here.

> I know there’s a history on the use of the “Library” word - equally
> there is a notion of a library needing a static interface etc - I
> propose we agree upon a single access mechanism to the QAPI - who’s
> existence and stability we have already (I think) agreed upon.

A stable/static interface is not hard - it doesn't require all
that much more than exposing a few APIs related to input and
output of QAPI based JSON docs. This all exists already, you
wwould just get skipping thue sockets serialization of QMP.

The biggest stumbling block for QEMU as a library is actually
the licensing mess. Too much of our code is GPLv2-only, which
makes it impractical to use as a library in too many use cases.
Any app that is not GPLv2-only compatible would have to isolate
QEMU in its own process and talk to it over RPC, at which point
it has just reinventing QMP again.

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