[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events

[Juan Quintela]

Anthony Liguori <address@hidden> wrote:
> On 05/25/2010 09:21 AM, Juan Quintela wrote:

>> +MIGRATION_CANCELED
>> +------------------
>> +
>> +Emitted when migration is canceled.  This is emitted in the source.
>> +Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
>> +and CANCELED migration for target).
>>    
>
> But the management tool is the one that cancels so surely, it knows
> why already.

ok, then that one is ok.

>
>> +Data: None
>> +
>> +Example:
>> +
>> +{ "event": "MIGRATION_CANCELED",
>> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_ENDED
>> +---------------
>> +
>> +Emitted when migration ends (both in source and target)
>>    
>
> A start event is going to be generated already, no?

problem here is that libvirt start target with -S, and waits to do the
"cont" as soon as possible.  As of know, only way to do it is to poll
info migrate on source faster.

>> +Data: None
>> +
>> +Example:
>> +
>> +{ "event": "MIGRATION_ENDED",
>> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_FAILED
>> +----------------
>> +
>> +Emitted when migration fails (both is source and target).
>> +
>> +Data: None
>>    
>
> There should be some information about why it failed, no? Preferrably
> in a QError format.

At this point, we have basically -1 :(

I can add a field with an error number, but we are very bad at the
moment about moving errno's upstack.

>> +Example:
>> +
>> +{ "event": "MIGRATION_FAILED",
>> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_STARTED
>> +-----------------
>> +
>> +Emitted when migration starts (both in source and target).
>>    
>
> I think this makes more sense as a MIGRATION_CONNECTED event.  It
> probably should carry peer information too.

What kind of peer information?

We have tcp/fd/exec/unix migrations.  calling it CONNECTED vs STARTED, I
don't care.  But adding information?  Notice that the management
application knows what it did, I can put the:

 "exec: gzip -d < /tmp/foo"

string, but not much more that I can put here.

Later, Juan.