Re: Making QEMU easier for management tools and applications

[Dr. David Alan Gilbert]

* Markus Armbruster (address@hidden) wrote:
> Stefan Hajnoczi <address@hidden> writes:
> > 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);

Those might not be as bad when mapped to other languages, all the
bool/value pairs would become Option<...>  so that removes that doubling.
The Error ** mechanism should somehow map onto functions returning a
normal Rust Result<> type.

Dave

>   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.
> 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK