Re: Making QEMU easier for management tools and applications

[Daniel P . Berrangé]

On Mon, Jan 27, 2020 at 10:06:45AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <address@hidden> writes:
> >   * qemu-system-$TARGET
> >
> >     The current binaries that exist today.
> >
> >     qemu-system-$TARGET should not be part of our formal
> >     stability promise. We won't gratuitously / knowingly
> >     break without good reason, but we will accept that
> >     breakage can happen. Stability is only offered by
> >     the qemu-{runtime,launcher}-$TARGET.
> >
> >     Several choices for their future in long term:
> >
> >       - Leave them as-is and basically ignore them
> >         whereever practical going forward, so we
> >     minimally worry about backcompat breakage
> >
> >       - Plan to re-write them so that they are simply
> >         a shim the forks+execs qemu-runtime-$TARGET
> >     and does syntax translation from CLI/HMP/QMP.
> >
> >       - Deprecate them with a view to deletion entirely
> >         in $NNN years. For some large-ish value of NNN,
> >     given how well known they are
> 
> How do the other complex executables like qemu-img, qemu-nbd fit into
> this picture?
> 
> Do they become redundant somehow for non-human users?
> 
> If not, will they get a QMP-only sibling, like qemu-system-$TARGET gets
> qemu-runtime-$TARGET?

I've not really thought about the other tools when writing this.

In libvirt we do see much of the same pain points in dealing with
these tools, as we do with QEMU emulator targets though. eg need
to probe features, the complexity of specifying block devices.
So there's clearly some conceptual overlap here to consider.


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