[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: Kevin Wolf
Subject: Re: Making QEMU easier for management tools and applications
Date: Mon, 27 Jan 2020 12:56:06 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

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

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


reply via email to

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