From: Anthony Liguori <anthony@codemonkey.ws>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Ryan Harper <ryanh@linux.vnet.ibm.com>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
quintela@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
Date: Tue, 26 Jul 2011 08:00:51 -0500 [thread overview]
Message-ID: <4E2EBA83.7030703@codemonkey.ws> (raw)
In-Reply-To: <CAJSP0QV6z-Ux=ASgMuCaeCe94vHrjB1K7Mc2F-rsQmWhTjFckA@mail.gmail.com>
On 07/26/2011 07:51 AM, Stefan Hajnoczi wrote:
> On Tue, Jul 26, 2011 at 10:48 AM, Stefan Hajnoczi
> <stefanha@linux.vnet.ibm.com> wrote:
>> On Mon, Jul 25, 2011 at 06:23:17PM -0500, Anthony Liguori wrote:
>> However, doing so imposes extra work on management tools - they need to
>> understand and drive negotiation. If QEMU adds a new capability we
>> might even need to update management tools!
>>
>> As a management tool author I would prefer the source and destination to
>> work it out amongst themselves so that I just issue the 'migrate'
>> command. Negotiation can be done without the management tool's
>> involvement: fail migration if the initial negotation phase fails.
>
> An advantage I didn't think of was that management tools handling
> negotiation makes negotiation out-of-band and the migration protocol
> doesn't need to be changed.
Not quite that, but that you can detect when the migration changes. For
instance, this feature would allow the following behavior:
1) src doesn't know the new protocol, dst still supports the old
protocol and the new protocol, migration uses old protocol.
2) src knows the new protocol, dst doesn't know the new protocol, old
protocol is used.
3) src knows the new protocol, dst knows the new protocol, new protocol
is used
4) src doesn't know the new protocol, dst chooses to only support the
new protocol, migration fails gracefully.
Even if we only ever introduce a single feature, having the mechanism
means that we can gracefully fail with a new format and have a
transition period.
Regards,
Anthony Liguori
>
> It seems like the migration protocol needs an overhaul sooner or later
> anyway, so perhaps it's not work making the negotiation external.
>
> Stefan
>
next prev parent reply other threads:[~2011-07-26 13:00 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 15:46 [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format Paolo Bonzini
2011-06-30 15:46 ` [Qemu-devel] [RFC PATCH 1/4] add support for machine models to specify their " Paolo Bonzini
2011-06-30 18:11 ` Michael S. Tsirkin
2011-07-01 6:10 ` Paolo Bonzini
2011-07-29 13:08 ` Anthony Liguori
2011-07-29 14:35 ` Paolo Bonzini
2011-06-30 15:46 ` [Qemu-devel] [RFC PATCH 2/4] add pc-0.14 machine Paolo Bonzini
2011-08-05 19:26 ` Bruce Rogers
2011-08-05 19:41 ` Anthony Liguori
2011-06-30 15:46 ` [Qemu-devel] [RFC PATCH 3/4] savevm: define new unambiguous migration format Paolo Bonzini
2011-07-29 13:12 ` Anthony Liguori
2011-07-29 14:35 ` Paolo Bonzini
2011-06-30 15:46 ` [Qemu-devel] [RFC PATCH 4/4] Partially revert "savevm: fix corruption in vmstate_subsection_load()." Paolo Bonzini
2011-07-25 21:10 ` [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format Paolo Bonzini
2011-07-25 23:23 ` Anthony Liguori
2011-07-26 9:42 ` Daniel P. Berrange
2011-07-26 9:48 ` Stefan Hajnoczi
2011-07-26 12:51 ` Stefan Hajnoczi
2011-07-26 13:00 ` Anthony Liguori [this message]
2011-07-26 12:07 ` Juan Quintela
2011-07-26 12:37 ` Anthony Liguori
2011-07-26 20:13 ` Juan Quintela
2011-07-26 21:46 ` Anthony Liguori
2011-07-26 22:22 ` Peter Maydell
2011-07-26 23:08 ` Anthony Liguori
2011-07-29 14:03 ` Kevin Wolf
2011-07-29 14:28 ` Anthony Liguori
2011-07-29 15:18 ` Kevin Wolf
2011-07-29 22:28 ` Anthony Liguori
2011-07-31 10:48 ` Dor Laor
2011-07-31 11:37 ` Peter Maydell
2011-07-31 11:45 ` Dor Laor
2011-07-31 18:46 ` Christoph Hellwig
2011-07-31 20:43 ` Dor Laor
2011-07-31 20:55 ` Anthony Liguori
2011-07-31 23:10 ` Christoph Hellwig
2011-08-01 0:15 ` Anthony Liguori
2011-08-01 7:54 ` Christoph Hellwig
2011-08-01 13:53 ` Anthony Liguori
2011-08-04 14:59 ` Luiz Capitulino
2011-07-31 20:43 ` Anthony Liguori
2011-07-31 20:57 ` Dor Laor
2011-07-31 21:03 ` Anthony Liguori
2011-07-31 21:25 ` Dor Laor
2011-07-31 21:49 ` Anthony Liguori
2011-07-29 13:14 ` Anthony Liguori
2011-07-29 14:49 ` Paolo Bonzini
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=4E2EBA83.7030703@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=ryanh@linux.vnet.ibm.com \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.com \
/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).