[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change han
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers |
Date: |
Tue, 05 Jun 2012 07:38:02 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
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 address@hidden +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [RFC PATCH 1/5] notifiers: add support for async notifiers handlers, (continued)
- [Qemu-devel] [RFC PATCH 1/5] notifiers: add support for async notifiers handlers, Yonit Halperin, 2012/06/05
- [Qemu-devel] [RFC PATCH 2/5] migration: moving migration start code to a separated routine, Yonit Halperin, 2012/06/05
- [Qemu-devel] [RFC PATCH 3/5] migration: moving migration completion code to a separated routine, Yonit Halperin, 2012/06/05
- [Qemu-devel] [RFC PATCH 5/5] spice: turn spice "migration end" handler to be async, Yonit Halperin, 2012/06/05
- [Qemu-devel] [RFC PATCH 4/5] migration: replace migration state change notifier with async notifiers, Yonit Halperin, 2012/06/05
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Anthony Liguori, 2012/06/05
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Gerd Hoffmann, 2012/06/05
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Yonit Halperin, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Alon Levy, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Alon Levy, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Yonit Halperin, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Anthony Liguori, 2012/06/06
- Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers, Alon Levy, 2012/06/06