Re: Making QEMU easier for management tools and applications

[Kevin Wolf <kwolf@redhat.com>]

Am 27.01.2020 um 21:11 hat John Snow geschrieben:
> On 1/27/20 6:56 AM, Kevin Wolf wrote:
> > Am 25.01.2020 um 11:18 hat Markus Armbruster geschrieben:
> >> Kevin Wolf <kwolf@redhat.com> writes:
> >>> basically just a pretty-printed version of it with the consequence that
> >>> it needs to be stored in an external file and there is no reasonable way
> >>> to keep it in my shell history.
> >>
> >> There is a reasonable way to keep it in my file system, though.  I find
> >> that decidedly superior.
> > 
> > That depends a lot on your use case.
> > 
> > If you have a long-lived production VM that you always run with the same
> > configuration, then yes, having a config file for it in the file system
> > is what you probably want. Currently, for this case, people directly
> > using QEMU tend to write a script that contains the command line. I
> > think I do have such scripts somewhere, but their number is very small.
> > 
> > My common case is short-lived VMs with configurations that change very
> > often between QEMU invocations. Here the command line is decidedly
> > superior.
> > 
> > Requiring me to create a file in the file system each time and to
> > remember deleting it after I'm done feels about as convenient as a *nix
> > shell that doesn't accept parameters for commands on the command line,
> > but instead requires you to write a one-off script first and then run
> > that.
> > 
> > Kevin
> > 
> 
> > ./qemu-core <<EOF
> {
>     "machine": "Q35",
>     "memory": "2GiB",
>     "accel": "kvm"
> }
> EOF

I'm not sure why everybody is trying to come up with crude workarounds
when all I said is that keeping things in a file is not always
"decidedly superior".

Of course, I would have points to make about that workaround (like that
I often want to use stdin for an interactive monitor, or that I don't
see how this is superior to --machine Q35 --memory 2GiB --accel kvm),
but that's all beside the point.

> No file required, cooperates with readline, avoids crunchy,
> hard-to-maintain CLI syntax. Directly and easily translatable to a
> stored-file configuration. All configuration and documentation is
> centralized via QAPI.
> 
> A little worse to type manually, yes. Maybe not bad /enough/ for me to
> want to rescue the CLI which prevents full QAPI-fication and a working
> configuration file.
> 
> Arguably, a well documented configuration schema will be much easier to
> browse, discover, and use than a labyrinthine CLI with many stub
> definitions whose options are not exposed in the documentation.
> 
> (The argument here is: It's a little harder and a little longer to type,
> but the benefits from the schema organization may improve productivity
> of using QEMU directly instead of harming it.)

I think this is a false dichotomy.

You can have everything defined by the schema and properly documented
and still have a non-JSON command line. Translating the QAPI schema to
a command line option is a solved problem, this is exactly how
-blockdev works.

The unsolved part is how to compatibly convert the existing options. If
you're willing to sacrifice compatibility, great. Then we can just
define stuff in the QAPI schema and still keep a command line syntax
that is usable for humans. The code for mapping a QAPI type to the
argument of an option is basically already there.

The only question is "is compatibility important"? If the answer is no,
then we'll be there in no time.

Kevin