Re: Making QEMU easier for management tools and applications

[Kevin Wolf]

Am 23.12.2019 um 16:04 hat Michal Prívozník geschrieben:
> On 12/21/19 10:02 AM, Markus Armbruster 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);
> > 
> >   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.
> 
> This is something that bothered me for a while now. Even though it's not
> as bad as it used to be because we are not adding so much wrappers for
> monitor commands as we used to. I mean, in libvirt the wrapper for a
> monitor command has to be written by hand. Worse, whenever I'm adding a
> wrapper I look at the QMP schema of it and let my muscle memory write
> the wrapper.
> 
> However, it's not only what Markus already mentioned. Even if we
> generated wrappers by a script, we need to be able to generate wrappers
> for every single supported version of qemu.
> 
> For instance, if qemu version X has a command that accepts some set of
> arguments and this set changes in version X+1 then libvirt needs both
> wrappers and decides at runtime (depending on what version it is talking
> to) what wrapper to use.
> 
> Unfortunately, I don't see any easy way out.

The easy way out would be tying libvirt to a specific QEMU version. And
I'm only half joking.

If libvirt didn't exist yet and we needed a management library for QEMU,
what we would build now would probably not look much like libvirt looks
today. We wouldn't try to have basic support for every hypervisor out
there, but integrate it much closer with QEMU and avoid much of the
backwards compatibility requirements that the interface between QEMU and
libvirt has (which requires us to deal with compatibility twice for
everything).

Maybe it would even be part of the QEMU repository, allowing a single
patch series to implement a new feature in the system emulator and
expose it in the API immediately instead of waiting for the next QEMU
release before libvirt can even think about implementing support for it.

So should libvirt move in that direction? Do people actually still make
much use of its multi-hypervisor nature, or would it make sense to split
it into separate libraries for each hypervisor that can be much tighter
integrated with (a specific version of) the respective hypervisor?

Kevin