qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes
Date: Mon, 19 Mar 2012 11:31:31 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 03/19/2012 11:09 AM, Paolo Bonzini wrote:
Il 19/03/2012 16:09, Anthony Liguori ha scritto:
Hi,

I didn't start out intending to write this series, but I end up here trying to
resolve an issue in the gtk UI.

What issue? :)

I rewrote the scaling support and did some usability testing with my unsuspecting wife... To make a long story short, my take away was that I need a way to have persistent configuration options. That got me looking at readconfig/writeconfig.


This series does some dramatic refactoring to -readconfig essentially throwing
away the existing (trivial) implementation and replacing it with glib's
GKeyFile support.

Nice.

It also plumbs the existing command line options through QemuOpts via a special
'system' section.  This means that any command line option can be specified via
readconfig and that the combination of -nodefconfig and -writeconfig should give
you exactly the same guest in a repeatable fashion.

I don't like this because it turns command-line options into ABI.

It's already an ABI, no?

Also,
it puts there some options for which -writeconfig is actually able to
produce a QemuOpts equivalent, such as -monitor.

That may be a bug depending on what your concern is.  Can you be more specific?

I have a few patches here that convert almost every option that matters
into QemuOpts so that -writeconfig records it: -m, -bios, -localtime,
-S, -M, -smp, -numa, -nodefaults, -no-shutdown, -no-reboot.  The only
thing that is left basically is -display, where I chickened out.

This series is complimentary to this. You can still promote options to QemuOpts. The advantage of this series is that we provide a programmatic way for libvirt to discover when this happens.

If you look at the management guide that I included, I made a strong statement that we promise to never extend existing options without first converting to QemuOpts.


Finally, this series exposes a new -query-capabilities option which dumps the
QemuOpts schema's via JSON to standard output (along with some other goodies
like the version info and supported QMP commands).

The purpose of this series is to change the way management tools (esp libvirt)
interact with QEMU to determine capabilities.  Instead of help parsing, libvirt
should use -query-capabilities to figure out which options are supported and
when new suboptions are available.

I would like to push this series into 1.1

I think it's too early.  However, we can definitely apply 1/2/7/8/9 now.

Let's go through the discussion and see where we end up. I was just stating my intentions so that folks reviewed appropriately.

But I realize there's a lot of discussion that needs to happen before we make this type of commitment for 1.1.

Regards,

Anthony Liguori


Paolo





reply via email to

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