[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 09:54:22 -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 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.

On the source end, I can't think of any events that would be useful. The migrate command can complete with a failure so that gives you failure notifications.

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.

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 completion.


Anthony Liguori

MIGRATED_STARTED+STOPPED really *is* needed if we're to make QMP cope
with all possible use cases. If we rely on inferring it from STOP+RESUME
events, it is going to exclude a significant set of use cases, and likely
result in this being proposed all over again in 12 months time :-(


reply via email to

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