From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org,
armbru@redhat.com, avi@redhat.com,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] QMP forward compatibility support
Date: Mon, 11 Jan 2010 19:49:01 +0000 [thread overview]
Message-ID: <20100111194901.GA10230@redhat.com> (raw)
In-Reply-To: <4B4B748B.6010008@codemonkey.ws>
On Mon, Jan 11, 2010 at 12:57:15PM -0600, Anthony Liguori wrote:
> On 01/11/2010 12:34 PM, Luiz Capitulino wrote:
> > Hi.
> >
> > We (Markus and I) are working on getting QMP forward compatibility
> > support,
> >supported. :)
> >
> > We have a plan for it and I'd like to ask the CC'ed people to review it.
> >
> > Needless to say, but the objective here is to add new commands,
> > arguments,
> >async messages and protocol features w/o breaking existing clients.
> >
> >General Plan
> >------------
> >
> >1. QMP should describe itself, ie. it should dump all accepted commands,
> >their replies and arguments, async messages and protocol features. All in
> >JSON format
> >
> >2. Protocol features are advertised by the (already existent) capabilities
> >array, but are _disabled_ by default. The exception is async messages,
> >which are _enabled_ by default
>
> Any reason to have an exception like this?
Personally I'd be fine with async events being off by default too.
There's no point in me receiving events I'm not able to handle,
so might as well only give me events I actually request.
> >3. We should add command(s) to enable/disable protocol features
> >
> >4. Proper feature negotiation is done in pause mode. That's, clients
> >interested in enabling new protocol features should start QEMU in
> >pause mode and enable the features they are interested in using
> >
>
> Why does this matter?
>
> We should be careful to support connecting to a VM long after it's been
> started so any requirement like this is likely to cause trouble.
Indeed, this won't work for libvirt. If you stop the libvirtd daemon
while a guest is running, and then start the libvirtd daemon again, it
will need to re-negotiate features while the guest is running.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2010-01-11 19:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-11 18:34 [Qemu-devel] QMP forward compatibility support Luiz Capitulino
2010-01-11 18:57 ` Anthony Liguori
2010-01-11 19:49 ` Daniel P. Berrange [this message]
2010-01-12 0:04 ` Luiz Capitulino
2010-01-12 0:24 ` Anthony Liguori
2010-01-12 8:16 ` Markus Armbruster
2010-01-12 12:19 ` Luiz Capitulino
2010-01-12 12:11 ` Luiz Capitulino
2010-01-13 16:53 ` Markus Armbruster
2010-01-13 17:06 ` Luiz Capitulino
2010-01-13 17:38 ` Markus Armbruster
2010-01-13 17:43 ` Luiz Capitulino
2010-01-14 0:01 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100111194901.GA10230@redhat.com \
--to=berrange@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=dlaor@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).