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

[Yoshiaki Tamura]

Hi Juan,

2010/6/9 Juan Quintela <address@hidden>:
> 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.
>
> Later, Juan.
>
> v3:
> - Add comment that MIGRATION_FAILURE will add a QError for 0.14
>  (when we get internal support for that)
>  rebase against today tree
>
> v2:
> - Address pbonzini and mst changes
>  (error messages and doc fixes)
>
> v1:
>
> This series does:
>
> - exit incoming migration on failure.  For exec/fd migrations, once
>  there was a failure, there was nothing useful to do.  And for tcp
>  migration, not exiting created interesting bugs when trying to
>  migrate again to a process with a faild migration.
>
> - Factorize common migration code, no more duplication, makes easier to do
>  "global" migration things, like QMP events.
>
> - Introduce QMP events, both for incoming and outgoing migration.
>
>
> Now, the million dollar question: Why I didn't refactorize outgoing
> migration?  I tried, and have it partially done on my local tree.  But
> it depends (too much) of current_migration global variable -> Libvirt
> folks will also want "info migrate" to work on the incoming side,
> i.e. current_migraition has to also be updated on incoming side.  Done
> until here, but then I hit the wall "incoming migration is synchronous".
>
> To make the monitor work on incoming migration, we need to change
> buffered_file.c abstraction to also work for incoming fd's, or another
> similar solution.  I am open to suggestions about what to do here.

I don't know I have addressed the problem correctly, but here is my
try to get "info migrate" on incoming side.

http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00417.html

Apart from that I have a concern on relation between newly introduced
QMP Migration events and existing MIG_STATE_*.  Are they supposed to
be 1 to 1 mapping?  If so, instead of calling
monitor_protocol_event() everywhere, how about introducing a common
function in migration that sets s->mig_state and emits QMP Migration
events at once?

Thanks,

Yoshi

> This series are quite simple (the unfinished part is more complex),
> will send the other part as an RFC later.
>
> Please review and consider to apply it.
>
> Later, Juan.
>
> Juan Quintela (5):
>  Exit if incoming migration fails
>  Factorize common migration incoming code
>  QMP: Introduce MIGRATION events
>  QMP: Emit migration events on incoming migration
>  QMP: Emit migration events on outgoing migration
>
>  QMP/qmp-events.txt |   52 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  migration-exec.c   |   17 +++--------------
>  migration-fd.c     |   15 ++-------------
>  migration-tcp.c    |   17 ++++-------------
>  migration-unix.c   |   17 ++++-------------
>  migration.c        |   37 +++++++++++++++++++++++++++++++------
>  migration.h        |    4 +++-
>  monitor.c          |   12 ++++++++++++
>  monitor.h          |    4 ++++
>  vl.c               |    7 ++++++-
>  10 files changed, 121 insertions(+), 61 deletions(-)
>
>
>