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
reliably.
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
completion.
Do you actually mean 'deprecate -incoming arg' here ?