[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making QEMU easier for management tools and applications

From: John Snow
Subject: Re: Making QEMU easier for management tools and applications
Date: Mon, 27 Jan 2020 15:11:05 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0

On 1/27/20 6:56 AM, Kevin Wolf wrote:
> Am 25.01.2020 um 11:18 hat Markus Armbruster geschrieben:
>> Kevin Wolf <address@hidden> writes:
>>> Am 24.01.2020 um 11:27 hat Daniel P. Berrangé geschrieben:
>>>> This is finally something I'd consider to be on a par with the
>>>> original QEMU syntax, before we added hierarchical data. You
>>>> have the minimal possible amount of syntax here. No commas,
>>>> no quotes, no curly brackets, etc.
>>> This seems to have the same problems as the QEMU command line (how do
>>> you distinguish strings from ints, from bools, from null?).
>> True: YAML provides only string scalars.
>> TOML provides strings, integers, floats, booleans, and several flavors
>> of time.  It lacks null.
>>>                                                             It's
>>> 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"

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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]