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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/25/2010 10:35 AM, Juan Quintela wrote:
> Anthony Liguori<anthony@codemonkey.ws>  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.
>    

Why does it do that??

That sound like a terrible idea.

>>> +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.
>    

We need a better solution for reporting errors via notifications.

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

Basically, do we have any useful information in info migrate that we can 
include?

Regards,

Anthony Liguori

> Later, Juan.
>