qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Yonit Halperin <yhalperi@redhat.com>
Cc: aliguori@us.ibm.com, alevy@redhat.com,
	Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
Date: Wed, 06 Jun 2012 20:08:40 +0800	[thread overview]
Message-ID: <4FCF4848.9010005@codemonkey.ws> (raw)
In-Reply-To: <4FCF46B0.1010905@redhat.com>

On 06/06/2012 08:01 PM, Yonit Halperin wrote:
> On 06/06/2012 12:22 PM, Anthony Liguori wrote:
>>
>> So send a QMP event and call it a day.
>>
> Using a QMP event is making spice seamless migration dependent on libvirt
> version.

That is not an acceptable justification.

> Delaying the status change to "migration completed", (1) doesn't affect
> qemu migration time, the migration has already completed, and (2) will allow
> spice to seamlessly migrate, no matter which libvirt version is used.

(1) libvirt starts the destination with -S and starts it manually IIUC.  It 
waits for the migration completed event to do this.

Seriously, just add the event.  Async notifiers are not an option.

Regards,

Anthony Liguori

>
> Yonit.
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>> Yonit.
>>>
>>>>
>>>> Very short version: The requirement is simply to not kill qemu on the
>>>> source side until the source spice-server has finished session handover
>>>> to the target spice-server.
>>>>
>>>> Long version: spice-client connects automatically to the target
>>>> machine, so the user ideally doesn't notice that his virtual machine was
>>>> just migrated over to another host.
>>>>
>>>> Today this happens via "switch-host", which is a simple message asking
>>>> the spice client to connect to the new host.
>>>>
>>>> We want move to "seamless migration" model where we don't start over
>>>> from scratch, but hand over the session from the source to the target.
>>>> Advantage is that various state cached in spice-client will stay valid
>>>> and doesn't need to be retransmitted. It also requires a handshake
>>>> between spice-servers on source and target. libvirt killing qemu on the
>>>> source host before the handshake is done isn't exactly helpful.
>>>>
>>>> [ Side note: In theory this issue exists even today: in case the data
>>>> pipe to the client is full spice-server will queue up the switch-host
>>>> message and qemu might be killed before it is sent out. In practice
>>>> it doesn't happen though because it goes through the low-traffic main
>>>> channel so the socket buffers usually have enougth space. ]
>>>>
>>>> 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.
>>>>
>>>> Option (3): Your suggestion?
>>>>
>>>> thanks,
>>>> Gerd
>>>>
>>>
>>
>

  reply	other threads:[~2012-06-06 12:08 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
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 [this message]
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=4FCF4848.9010005@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=alevy@redhat.com \
    --cc=aliguori@us.ibm.com \
    --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).