[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] vl: add -libvirt-caps option for libvirt to sto
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH] vl: add -libvirt-caps option for libvirt to stop parsing help output |
Date: |
Thu, 26 Jul 2012 09:10:02 -0500 |
User-agent: |
Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
"Daniel P. Berrange" <address@hidden> writes:
> On Thu, Jul 26, 2012 at 01:47:23PM +0100, Daniel P. Berrange wrote:
>> On Wed, Jul 25, 2012 at 02:47:57PM -0500, Anthony Liguori wrote:
>> > The help output is going to change dramatically for 0.13. We've spent too
>> > long
>> > waiting for a perfect solution to capabilities handling and the end loser
>> > is
>> > the direct consumer of QEMU because the help output is awful.
>> >
>> > I will not apply any patches that change help output until 0.13 development
>> > opens up. This should give libvirt adequate time to implement support for
>> > dealing with this new option.
>>
>> I completely agree with this. We have spent far too long making do with
>> "help output" and its about time we finish with this once & for all.
>> I'm assuming you mean the 1.3 release here. If so I'll agree that it
>> is an acceptable plan to change help output at the start of the 1.3
>> release.
>>
>> This gives us enough time to agree on what todo to support apps needing
>> to query QEMU.
>>
>> > This capabilities set comes directly from libvirt's source code so it's
>> > entirely
>> > adequate for libvirt's purposes. We can still explore more sophisticated
>> > approaches that are more general purpose but the help output will be
>> > changing.
>>
>> While I appreciate what you're trying todo here, I think this would be a
>> serious mistake on many counts, and even be incorrect in some ways.
>>
>> - It ignores the needs of other apps using QEMU. In particular Richard
>> Jones has frequently requested a way to detect QEMU capabilities
>> to satisfy libguestfs. I think it is unreasonable to expect libguestfs
>> to use the libvirt capabilities described here. Likewise other apps
>>
>> - This is just a point in time snapshot of what libvirt currently uses
>> from QEMU. If, for example, someone provided a patch to libvirt to
>> support the bluetooth devices we'd be stuck, because although QEMU
>> already supports bluetooth, this is not expressed in any of the
>> caps libvirt already has.
>>
>> - Not all of this information actually comes from the help output.
>> A bunch of it is stuff we detect from '-device ?' and
>> '-device name,?'. Although, (AFAIR) no one has objections to use
>> parsing the -device output because it is much better defined &
>> stable than -help, I think we could use some improvement to make
>> the parsing 100% long term maintainable by QEMU/apps. Similarly
>> we do '-cpu ?' and '-machine ?'. Some of the caps are set based
>> on the machine architecture, or QEMU version.
>>
>> - Some of the caps are set based on what libvirt is actually
>> able to handle from a command line generation POV, so having
>> QEMU report these unconditionally is misleading/wrong. It is
>> not about what QEMU supports, it is about what libvirt is able
>> to cope with.
>>
>> - In the future some of the caps may be describing supported
>> monitor commands, detected via 'query-commands' QMP cmd.
>>
>> - Users of libvirt are asking us to expose information about
>> what QEMU supports, in particular wrt to devices, but also
>> other aspects of configuration.
>>
>>
>>
>> A long time back I proposed a '-capabilities' command line argument
>> for querying QEMU.
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00921.html
>>
>> There was a long discussion about this & many aspects of it were
>> disliked. In retrospect I agree with many of the comments, and
>> am glad we didn't adopt this. I think, however, there is a merit
>> in trying something vaguely related again, but with some key
>> differences. Basically I'd sum up my new idea as "just use QMP".
>>
>>
>> * No new command line arguments like -capabilities
>>
>> * libvirt invokes something like
>>
>> $QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
>>
>> * libvirt then runs a number of QMP commands to find out
>> what it needs to know. I'd expect the following existing
>> commands would be used
>>
>> - query-version - already supported
>> - query-commands - already supported
>> - query-events - already supported
>> - query-kvm - already supported
>> - qom-{list,list-types,get} - already supported
>> - query-spice/vnc - already supported
>>
>> And add the following new commands
>>
>> - query-devices - new, -device ?, and/or -device NAME,?
>> data in QMP
>> - query-machines - new, -M ? in QMP
>> - query-cpu-types - new, -cpu ? in QMP
>>
>> The above would take care of probably 50% of the current libvirt
>> capabilities probing, including a portion of the -help stuff. Then
>> there is all the rest of the crap we detect from the -help. We could
>> just take the view, that "as of 1.2", we assume everything we previously
>> detected is just available by default, and thus don't need to probe
>> it. For stuff that is QOM based, I expect we'll be able to detect new
>> features in the future using the qom-XXX monitor commands. For stuff
>> that is non-qdev, and non-qom, libvirt can just do a plain version
>> number check, unless we decide there is specific info worth exposing
>> via other new 'query-XXX' monitor commands.
>>
>> So in summary, as of 1.2 QEMU, libvirt would
>>
>> - Remove all use of -help, and other -XXXX command line args
>> for detecting capabilities
>>
>> - Use -qmp and issue commands above to detect whatever it
>> can
>>
>> - Any other existing capabilities are just "enable by default"
>> for QEMU >= 1.2
>>
>> - Detect future stuff via existing monitor commands, otherwise
>> just do it by QEMU version number.
>>
>>
>> So in terms of QEMU work, all I'm asking is to be allowed to
>> implement the query-devices, query-machines & query-cpu-types
>> QMP monitor commands. I'll happily do this work myself, if it
>> brings an end to the -help madness.
>
> Oh, if it is possible to get this data via QOM commands already,
> or it can be easily made to work with QOM commands, then obviously
> I wouldn't ask for these new query-XXX commands.
Yup.
You could do:
qom-list-types implements=TYPE_DEVICE
And that will give you the various types. We'll need to add a:
device-list-properties typename=FOO
I've got a patch locally for that that I'm testing right now. Paolo and
I never came to an agreement on how to do this generically for Objects
but I'm happy with a device-specific interface for the short term.
Regards,
Anthony Liguori
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|