qemu-devel
[Top][All Lists]
Advanced

[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: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
Date: Wed, 06 Jun 2012 20:08:40 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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 via email to

[Prev in Thread] Current Thread [Next in Thread]