[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events

[Juan Quintela <quintela@redhat.com>]

Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Wed,  9 Jun 2010 14:10:53 +0200
> Juan Quintela <quintela@redhat.com> wrote:
>
>> This is a resent with what we agreed on yesterday call.
>> Migration events would be there for 0.13 until we get proper
>> async command support.
>
>  Something which is not clear to me is the set of events we'd have if migrate
> was an async command.
>
>  Ie, do we really need MIGRATION_FAILED in this case? Don't we expect to get
> this information from the async response?
>

I am not able to define simpler semantics for this events:

- MIGRATION_STARTED:  somebody started a migration, it is emited on
  source and target, all monitors receive this event.
- MIGRATION_ENDED: migration ended with sucess, all needed data is in
  target machine.  Also emitted in all monitors on source and target.
- MIGRATION_CANCELED: in one of the source monitors somebody typed:
  migrate_cancel.  It is only emmited on the source monitors, target
  monitors will receive a MIGRATION_FAILED event.

- MIGRATION_FAILED (with this error).  At this point we don't have
  neither the QMP infraestructure for sending (with this error) nor
  migration infrastructure to put there anything different than -1.

  This event is emmited on all source and target monitors.
  - For 0.13: Event don't have a QError.
  - For 0.14: It will gain a QError.

  About migration becoming an async command.  Really it is independent
  of what events we emit.  If migration becomes async command, only
  difference is for the monitor that emitted the command, rest of
  monitors see nothing.  If we want to be able to see that informantion
  in the other monitors, we need the events anyways.

Why do we want this?  It makes things like audit simpler (we already
know when a machine starts/stops, knowing when it migrates is also a
good idea.  Same for things like the storage management examples that
danp did.  With events, it becomes trivial, without events, it can be
done with workarounds, sending messages left, rigth and center.

Spice also wanted the equivalent of this events to reconnect to the new
server machine.  I can't see why people have so much trouble with this
events, they are of the simpler class.  The only real problem that we
have is what to put on the MIGRATE_FAILED event, and the problem is an
infrastructure one, that we don't have neither what or how to put
something useful there.

At this point, management applications only want to know if migration
ended with success or with failure, but they will like to know at some
point what kind of failure they had.

Later, Juan.