Re: Making QEMU easier for management tools and applications

[Markus Armbruster <armbru@redhat.com>]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> Hi,
> QEMU presents a command-line interface and QMP monitor for
> applications to interact with.  Applications actually need API
> bindings in their programming language.  Bindings avoid reimplementing
> code to spawn a QEMU process and interact with QMP.  QEMU is kind of
> lazy and de facto relies on libvirt for API bindings.
>
> Is it time for better QEMU APIs?
>
> 1. We have qapi-schema.json.  Let's render to HTML and publish
> versioned documentation online.

Make can build docs/interop/qemu-qmp-ref.{7,html,info,pdf,txt}.  Grab
the .html and go for it.  There's also qmp-ga-ref.

Sadly, this documentation is not nearly as good as it could be.  The doc
comment format is an ad hoc solution to the problem of enabling doc
generation with minimal churn to existing comments.  The doc generator
makes an effort to play that hand (but the hand sucks).  Finally and
most seriously, the doc comments are simply not good enough.

> 2. scripts/qmp/ contains command-line tools for QMP communication.
> They could use some polish and then be shipped.

MAINTAINERS blames them on me, but they're effectively unmaintained.
Prerequisite for shipping: having a maintainer who actually gives a
damn.

Let's review them:

* scripts/qmp/qemu-ga-client

  Is anybody using this?

  I think it should be unter "QEMU Guest Agent", not under "QMP".

* scripts/qmp/qmp

  Half-hearted attempt at a CLI tool for sending a QMP command.  Is
  anybody using this?
 
* scripts/qmp/qmp-shell

  Half-hearted attempt at a human-friendly wrapper around the JSON
  syntax.  I have no use for this myself.

* scripts/qmp/qom-fuse

  I find this occasionally useful for QOM-spelunking.  The need for this
  indicates our QMP interface to QOM is too primitive for such uses.

* scripts/qmp/qom-get
  scripts/qmp/qom-list
  scripts/qmp/qom-set
  scripts/qmp/qom-tree

  Rather specialized.  Is anybody using them?

> 3. python/qemu/ contains Python modules for managing a QEMU process
> and QMP communication.  This should be packaged in distros and
> available on PyPI.

Currently maintained by Eduardo and Cleber (cc'ed) under "Python
scripts".

> 4. Go and Rust bindings would also be useful.  There is
> https://github.com/intel/govmm but I think it makes sense to keep it
> in qemu.git and provide an interface similar to our Python modules.

Mapping QAPI/QMP commands and events to function signatures isn't hard
(the QAPI code generator does).  Two problems (at least):

1. Leads to some pretty ridiculous functions.  Here's one:

    void qmp_blockdev_mirror(bool has_job_id, const char *job_id,
                             const char *device,
                             const char *target,
                             bool has_replaces, const char *replaces,
                             MirrorSyncMode sync,
                             bool has_speed, int64_t speed,
                             bool has_granularity, uint32_t granularity,
                             bool has_buf_size, int64_t buf_size,
                             bool has_on_source_error,
                             BlockdevOnError on_source_error,
                             bool has_on_target_error, BlockdevOnError on_target_error,
                             bool has_filter_node_name, const char *filter_node_name,
                             bool has_copy_mode, MirrorCopyMode copy_mode, 
                             bool has_auto_finalize, bool auto_finalize,
                             bool has_auto_dismiss, bool auto_dismiss,
                             Error **errp);

  We commonly use 'boxed': true for such beasts, which results in
  functions like this one:

    void qmp_blockdev_add(BlockdevOptions *arg, Error **errp);

2. Many schema changes that are nicely backward compatible in QMP are
   anything but in such an "obvious" C API.  Adding optional arguments,
   for instance, or changing integer type width.  The former is less of
   an issue with 'boxed': true.

Perhaps less of an issue with dynamic languages.

I figure a static language would need much more expressive oomph than C
to be a good target.  No idea how well Go or Rust bindings can work.

> 5. A jailer is needed to isolate the QEMU process and vhost-user
> device backends using seccomp, Linux namespaces, and maybe
> SELinux/AppArmor.  We used to be able to rely on libvirt for QEMU
> security, but it's becoming a common task for any device backend and
> IMO should be its own launcher tool.

Perhaps the libvirt refactoring effort can give us one.

> 6. A configuration file format is sorely needed so that guest
> configuration can be persisted and easily launched.  Today you have to
> create a shell script that executes a QEMU command-line, but this is
> suboptimal because sharing executable scripts is dangerous from a
> security perspective and is hard to parse or modify programmatically.

No argument.  There is -readconfig, but it falls way short.

With command line QAPIfication, a real configuration file will be quite
feasible.

The main reason for the lack of progress there is our dedication to
backward compatibility.  A functional replacement of our CLI is a huge
task already.  Throwing in backward compatibility makes it a daunting
one.  Not least because nobody fully understands all the quirks.

> In many of these areas we already have a partial solution.  It just
> needs more work.  I think it would be worth the effort and the mental
> shift to really providing APIs that are easy to use by applications.
>
> What do you think?
>
> Have I missed things that are needed?
>
> Have I included things that are unnecessary?

I feel we need to make up our minds what kind of interface(s) we want to
provide.

We provide a low-level interface for management applications.  I feel we
need to nail this one.  Its QMP part is okay, I think, the CLI part is
not.

We also try to provide friendlier interfaces for human users.  Not only
do we suck at it, we're also prone to create liabilities for later: much
of the compatibility woes that have been holding us back are rooted in
"convenience" features.  And don't get me started on the folly of us
dabbling in GUI.