Hi,
Below are the notes I collected during the BoF session about QEMU
configuration, command-line and QMP. Sorry for taking so long to
send them.
All inaccuracies and mistakes below are my own fault. (I learned
the hard way that trying to take notes while participating in the
discussion at the same time is not a good idea.)
--------------------------------
KVM Forum 2017 BoF session: configuration, command-line and QMP
2017-10-26
People: Jiri Denemark, Laine Stump, Peter Krempa,
Markus Armbruster, Eduardo Habkost, Igor Mammedov,
Kevin Wolf, Eduardo Otubo, Alistair Francis,
Kashyap Chamarthy, Max Reitz
----------------
First topic: early QMP and -paused series by Igor
ehabkost tried to explain the original problem and Igor's proposal[1].
Markus: startup time is important, some things can make it slow. Personally,
not so much concerned about querying stuff. Just cache it!
Markus, about starting a monitor earlier: "it just makes sense". One problem
is: command-line processing ordering mess in QEMU. It's tempting but very
scary. very easy to screw up. About command-line ordering, “I'd just go
left-to-right”.
ehabkost: is gradual change with NUMA stuff the right path? (Markus: "what's
the
right path?"; ehabkost: "I don't know"). If you are using CPU hotplug you still
might have some stuff not appearing in the command-line, because it uses
query-hotpluggable-cpus. pkrempa: if you're using cpu hotplug you don't care
about startup time. NUMA is not different.
Markus's objection to current -paused series: the need for another option/state.
We basically have 3 states/phases:
1: between exec and monitor available
2: between monitor and machines start to runs (in that phase a device_add
is/can be a cold plug)
3: then the machine actually runs, and all device_add is hotplug
ehabkost: that's how I understand it, too.
ehabkost: question for libvirt developers: is there an "expansion" operation
where libvirt could fill-up missing data on the XML based on info queried from
QEMU? (Answer seems to be yes)
----------------
Some comments from Igor and Peter about query-hotpluggable-cpus and the need to
choose the right device type (sometimes TYPE_CPU is not appropriate for
device_add, but only CPU cores, like on Power).
ehabkost: that's probably another use case for query-device-slots: knowing that
power machines can't device_add threads, but just cores. Tricky part: providing
slot information at qemu-probing time (with -machine none), before any machine
was built.
----------------
Some discussion about QEMU capability caching, why we need it, what we need to
get rid of it (answer: early QMP?).
Markus: would --query-FOO for some FOOs help? libvirt developers seem to prefer
early QMP.
----------------
Now that libvirt queries QEMU for host CPUID capabilities, there are more
interesting ways the cache may need to be invalidated.
Markus: “there's a it of a combinatorial explosion, i.e. query results can
depend on so much more than just the QEMU version and machine type. Makes
invalidating the cache tricky, and possibly even finding something useful in it
insufficiently likely to be worth the trouble.”
----------------
Some discussion about libvirt/qemu versions compatibility. Markus proposes that
we could choose to make newer QEMU require a more recent libvirt version.
OpenStack Nova re-evaluates every 6 months what next minimum libvirt and QEMU
versions to use (via constants: NEXT_MIN_LIBVIRT_VERSION, NEXT_MIN_QEMU_VERSION)
Markus: “The version decoupling we have is really nice, but I think an
occasional dependency would be tolerable. Consider it when it saves lots of
work.”
Markus: “Also: drop support for old versions of QEMU. Anything before 1.5?”
----------------
References and notes:
[1] References for “Early QMP”:
* Igor’s proposal at:
Subject: [Qemu-devel] [RFC 0/6] enable numa configuration before
machine_init() from HMP/QMP
https://www.mail-archive.com/qemu-devel@nongnu.org/msg488601.html
* And what Eduardo has suggested at:
http://www.linux-kvm.org/images/4/46/03x06A-Eduardo_HabkostMachine-type_Introspection_and_Configuration_Where_Are_We_Going.pdf
Comments from Markus:
> Related: "Why /two/ config interfaces?" in my KVM Forum talk. The two
> being CLI and QMP.
>
> We've long held the idea to support starting QEMU with a minimal command
> line, then do all configuration via QMP. Not possible today, because
> lots of things can only be done via CLI. In part because QMP becomes
> available only after quite a few config boats have sailed.
>
> Making QMP available earlier during startup ("early QMP") would be a
> stepping stone towards the "only QMP" goal.
>
> Related: rebasing CLI onto QAPI would make replicating CLI-only
> interfaces in QMP easier.
--
Eduardo
