Re: [libvirt] [PATCH] Run 'qmp_capabilities' command at monitor startup
On Mon, 15 Feb 2010 15:16:32 +0000
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Mon, Feb 15, 2010 at 04:14:01PM +0100, Matthias Bolte wrote:
> 2010/2/15 Daniel P. Berrange <berrange(a)redhat.com>:
> > ---
> > src/qemu/qemu_driver.c | 18 ++++++++++++++----
> > src/qemu/qemu_monitor.c | 13 +++++++++++++
> > src/qemu/qemu_monitor.h | 2 ++
> > src/qemu/qemu_monitor_json.c | 20 ++++++++++++++++++++
> > src/qemu/qemu_monitor_json.h | 2 ++
> > 5 files changed, 51 insertions(+), 4 deletions(-)
> >
>
> ACK.
>
> Why do we need to call qmp_capabilities at startup?
Because QEMU developers just decided to add it and make it mandatory :-)
Actually, it's because when a client connects QMP is in "capabilities
negotiation mode". In this mode only the qmp_capabilities command can
be issued. When this is done QMP changes to "command mode", where all
commands are accepted.
This is QMP's capabilities negotiation support. It's a mandatory step
because new capabilities are reserved for protocol changes or features
which are not backward compatible. This way, it's important that server
and clients agree on what is going to be on the wire before any message
is exchanged.
We don't have any capabilities yet, so qmp_capabilities is issued
without arguments. Which is what clients should do if they don't support
new features.
/me is happy the JSON code is still disabled until QEMU 0.13 comes
out
Well, I was in favor of making QMP stable for 0.12, but today I realize
that this would have been a mistake, as the protocol wasn't mature yet.
I understand that having to keep up to date with an unstable protocol
isn't always fun, on the other hand libvirt's early adoption and your
inputs are crucial to guide QMP's unstable phase into the right direction.
Please, let me know if there's anything that we could improve on our side.