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

[Juan Quintela <quintela@redhat.com>]

Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 06/11/2010 09:30 AM, Luiz Capitulino wrote:
>> On Thu, 10 Jun 2010 12:44:55 +0200
>> Juan Quintela<quintela@redhat.com>  wrote:

>
> I think we've more or less agreed that MIGRATION_CONNECTED is really
> the event we want.

This had the problem of migrating to a file/whatever.

MIGRATION_CONECTED only makes sense when you have TCP or similar.
MIGRATION_STARTED it just means that migration has started,
independently of whatever method you have.  For TCP it is possible that
we want another event each time that somebody connected to a port (not
only for migration), but that is something different.

>>> - 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.
>>>      
>>   Aren't all the three events above duplicating the async response?
>>    
>
> Yes.  Today, we should just generate a MIGRATION_DONE event and let a
> client poll for failure status.

I disagree completely.  It just defeat the reason for this.

MIGRATION_ENDED on destination machine: go ahead, everything is ok.
MIGRATION_FAILED: Uh, oh, something got wrong, we are in the slow path.

With MIGRATION_DONE + polling, we are delaying the "success" case just
to avoid having a new event.  I don't buy it.

>>>    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.
>>>      
>>   Somewhere else in this discussion someone has said that we should assume
>> that the client talking to the source is the same one which is going to
>> talk to the target, in this case all the communication is done through
>> the source qemu instance.
>>    
>
> MIGRATION_DONE gets deprecated for 0.14.

I still think that we want the 4 events that I described.  My
understanding is that libvirt people also would love to have that 4
events.

Answer here is that: you can do this workaround and this other
workaround and you can get that information.

About semantics of messages, I don't see anytime soon that migration are
going to change from:

Start migration and then end with success or failure.

The only one that we could change/remove is MIGRATION_CANCEL to
MIGRATION_FAILURE(User canceled) it.  But that is it.

Why have to do a polling when none is needed?
If you preffer to change the MIGRATION_ENDED + MIGRATION_FAILURE(error)
to MIGRATION_ENDED(result code), and you have to check the error code, I
can also live with that.  But that is it.

Later, Juan.