From: Eric Blake <eblake@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Yonit Halperin <yhalperi@redhat.com>,
aliguori@us.ibm.com, alevy@redhat.com, qemu-devel@nongnu.org,
Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
Date: Tue, 05 Jun 2012 07:38:02 -0600 [thread overview]
Message-ID: <4FCE0BBA.2010807@redhat.com> (raw)
In-Reply-To: <4FCE067E.5030903@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On 06/05/2012 07:15 AM, Gerd Hoffmann wrote:
> Hi,
>
>> Absolutely not. This is hideously ugly and affects a bunch of code.
>>
>> Spice is *not* getting a hook in migration where it gets to add
>> arbitrary amounts of downtime to the migration traffic. That's a
>> terrible idea.
>>
> So, the big question is how to tackle the issue?
>
> Option (1): Wait until spice-server is done before signaling completion
> to libvirt. This is what this patch series implements.
>
> Advantage is that it is completely transparent for libvirt, thats why I
> like it.
>
> Disadvantage is that it indeed adds a small delay for the spice-server
> handshake. The target qemu doesn't process main loop events while the
> incoming migration is running, and because of that the spice-server
> handshake doesn't run in parallel with the final stage of vm migration,
> which it could in theory.
>
> BTW: There will be no "arbitrary amounts of downtime". Seamless spice
> client migration is pretty pointless if it doesn't finish within a
> fraction of a second, so we can go with a very short timeout there.
>
> Option (2): Add a new QMP event which is emmitted when spice-server is
> done, then make libvirt wait for it before killing qemu.
>
> Obvious disadvantage is that it requires libvirt changes.
But there was recently a proposal for a new monitor command that will
let libvirt query which events a given qemu supports, and therefore
libvirt can at least know in advance whether to expect and wait for the
event, or to fall back to some other option. Just because libvirt would
require a change doesn't necessarily rule out this option.
>
> Option (3): Your suggestion?
>
> thanks,
> Gerd
>
>
>
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]
next prev parent reply other threads:[~2012-06-05 13:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 5:49 [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers Yonit Halperin
2012-06-05 5:49 ` [Qemu-devel] [RFC PATCH 1/5] notifiers: add support for async notifiers handlers Yonit Halperin
2012-06-05 8:36 ` Gerd Hoffmann
2012-06-05 5:49 ` [Qemu-devel] [RFC PATCH 2/5] migration: moving migration start code to a separated routine Yonit Halperin
2012-06-05 8:44 ` Gerd Hoffmann
2012-06-05 5:49 ` [Qemu-devel] [RFC PATCH 3/5] migration: moving migration completion " Yonit Halperin
2012-06-05 8:46 ` Gerd Hoffmann
2012-06-05 5:49 ` [Qemu-devel] [RFC PATCH 4/5] migration: replace migration state change notifier with async notifiers Yonit Halperin
2012-06-05 5:49 ` [Qemu-devel] [RFC PATCH 5/5] spice: turn spice "migration end" handler to be async Yonit Halperin
2012-06-05 11:59 ` [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers Anthony Liguori
2012-06-05 13:15 ` Gerd Hoffmann
2012-06-05 13:38 ` Eric Blake [this message]
2012-06-05 21:37 ` Anthony Liguori
2012-06-06 9:10 ` Yonit Halperin
2012-06-06 9:22 ` Anthony Liguori
2012-06-06 10:54 ` Alon Levy
2012-06-06 11:05 ` Anthony Liguori
2012-06-06 11:27 ` Alon Levy
2012-06-06 11:49 ` Anthony Liguori
2012-06-06 12:01 ` Yonit Halperin
2012-06-06 12:08 ` Anthony Liguori
2012-06-06 12:15 ` Alon Levy
2012-06-06 12:17 ` Anthony Liguori
2012-06-06 12:30 ` Alon Levy
2012-06-06 12:34 ` Anthony Liguori
2012-06-06 13:03 ` Gerd Hoffmann
2012-06-06 14:52 ` Alon Levy
2012-06-06 15:00 ` Gerd Hoffmann
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=4FCE0BBA.2010807@redhat.com \
--to=eblake@redhat.com \
--cc=alevy@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yhalperi@redhat.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).