[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events

From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
Date: Wed, 26 May 2010 11:55:31 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 05/26/2010 10:15 AM, Daniel P. Berrange wrote:
On Wed, May 26, 2010 at 09:54:22AM -0500, Anthony Liguori wrote:
On 05/26/2010 05:33 AM, Daniel P. Berrange wrote:
I'm not sure why you would need a notification of when migration
starts (since you know when you've started migration).

But you don't know if the other end "knows" that it has also started.

started is needed only in incoming part, because .... we don't have a
monitor to ask if migration has started.

If we ever want to get closer to allowing multiple monitors, or allowing
apps to issue QMP commands directly via libvirt, then we still need the
'migration started' event on the source, because something else can
have issued the 'migrate' command without the mgmt app knowing.

Migration started doesn't help multiple monitors.  You need locking of
some sort.

Part of the problem is the QMP migrate command is implemented as a
synchronous command.  It really ought to be an asynchronous command.
That tells you when the migration has actually completed without polling.
Handling asynchronous commands is alot more complicated and error
prone for client apps, than providing a asynchronous event notification
of the lifecycle stages. If you want to also query status while waiting
for the completion, it means you can have to deal with overlapping
command  execute+return pairs within a single monitor connection.
AFAICT this requires a change to QMP to require a unique ID to be
sent with the {'execute'..} command and be sent back with the later
corresponding {'return'...} data,  so you can actually correlate

That's exactly how the protocol is designed. That was one of the major improvements of QMP over the human monior.

This is how the info balloon command works, BTW.

Since there's a clear correlation between the request and the result of the request, an asynchronous command is what makes the most sense. It eliminates the problem of how to pass QErrors via an event which is one of the problems with the current event proposal.

Events are meant for when there is no clear request that the event is associated with. A VNC CONNECT event is a good example of this.

On the destination side, we're really limited by the fact that we don't
do live incoming migrations.  The monitor doesn't get a chance to run at
all with exec: migration, for instance.
If QEMU let you issue a monitor command for starting incoming
migration, instead of using -incoming this wouldn't such a bad
problem. eg you can launch QEMU in the desired config, with CPUs
stopped, do the normal QMP handshake + whatever else is required
then issue 'migrate_incoming URI' which blocked the caller for
the duration, to allow completion to be detected.

For tcp: and unix:, a CONNECTED event absolutely makes sense (every
socket server should emit a CONNECTED event).  Unfortunately, after
CONNECTED you lose the monitor until migration is complete.  If
something bad happens, you have to exit qemu so once the monitor
returns, migration has completed successfully.

If we introduce live incoming migration, we'll need to rethink things.
I would actually suggest that we deprecate the incoming command if we do
that and make incoming migration a monitor command.  I would think it
should have the same semantics as migrate (as an asynchronous command).
A CONNECTED event still makes sense for tcp and unix protocols but I
don't think events make sense for start stop vs. an asynchronous command
Do you actually mean 'deprecate -incoming arg' here ?

Yes. And by deprecate, I really mean that -incoming just becomes syntactic sugar for executing a monitor command immediately.


Anthony Liguori


reply via email to

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