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

[Yoshiaki Tamura]

2010/6/10 Luiz Capitulino <address@hidden>:
> On Wed,  9 Jun 2010 14:10:53 +0200
> Juan Quintela <address@hidden> 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?

There would be two types of MIGRATION_FAILED.
One for errors happen during setup of live migration, and one for
during the process of live migration.  The former is a synchronous
event, and later would be an asynchronous event (if you didn't use -d
option, this should also be a synchronous event).

I'm not sure whether we should distinguish these failures or not.

Yoshi

>
>>
>> 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.
>>
>> 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(-)
>>
>>
>
>
>