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

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 06/12/2010 06:05 AM, Juan Quintela wrote:
> Luiz Capitulino<lcapitulino@redhat.com>  wrote:
>    
>> On Thu, 10 Jun 2010 12:44:55 +0200
>> Juan Quintela<quintela@redhat.com>  wrote:
>>
>>      
>>> Luiz Capitulino<lcapitulino@redhat.com>  wrote:
>>>        
>>>> On Wed,  9 Jun 2010 14:10:53 +0200
>>>> Juan Quintela<quintela@redhat.com>  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?
>>>>
>>>>          
>>> I am not able to define simpler semantics for this events:
>>>        
>>   Ok, I must be missing something here.
>>
>>   First, let's talk about how async commands work today, better yet, how they
>> should work in 0.14.
>>
>>   I see two possible interfaces (off the top of my head):
>>
>>   1. QMP only returns the response when the command is finished, eg:
>>
>>      C: { "execute": "migrate", "id": "foo" ... }
>>      /* nothing is returned, other commands are issued, after several hours... */
>>      S: { "return": ... "id": "foo" }
>>
>>   2. QMP returns a response right away just to signal that the command
>>      has been accepted:
>>
>>      C: { "execute": "migrate", "id": "foo" ... }
>>      S: { "return": {}, "id": "foo" ... }
>>
>>      However, the actual response is emitted as an event:
>>
>>      S: { "event": "ASYNC_RESPONSE", "return": ..., "id": "foo" }
>>
>>
>>   That's what I have in mind, that's why I'm confused about what we're
>> trying to accomplish here.
>>      
> You continue forgeting the case that you have more than one monitor
> conected.  The other monitor will not receive _ethire_ of that
> responses.  Will not know what is happening.
>
>
>    
>>> - MIGRATION_STARTED:  somebody started a migration, it is emited on
>>>    source and target, all monitors receive this event.
>>>        
>>   The client has started the migration, it knows it. Why is the event needed?
>>      
> The monitor that did it knows it, nobody else knows it.  At destination
> time, I guess you agree this is important, i.e. the management app knows
> that migration has started.
>    

Dual monitors is a slippery slope argument because even if you had these 
events, it doesn't give you nearly enough information to implement 
anything safely.

If you truly want to support dual uncooperative monitors, you basically 
need to mirror every monitor session so that each monitor can see what 
the other monitors are doing.  You also need a transaction mechanism to 
allow a client to do operations in a non-racy way.

Since we're not likely to ever implement these things, dual monitor 
support is really not a viable argument for such a change.

> I have been needinng this for audit, knowing when guest
> start/stop/migrates.  And just now the only way to get that information
> is to "hack" qemu source code.  With migration_events it will be
> "trivial" to know when that happens.
>    

QMP is the wrong mechanism for this.  Merging the tracing code and then 
adding trace points to migration is the right solution for this problem.

>>> - 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?
>>      
> Again, no.  Think that you have more than one monitor.
> And indeed in the case of a single monitor.  We are delaying the
> information to the target management app.
>
> MIGRATION_ENDED on target machine: We can do whatever is needed when
> migration has ended.  Async (or sync) answer to the source management
> app, it needs to receive that information + send that information to
> destination machine + receive information in destination machine + do
> whatever is needed on destination vm.
>
> Just because we refuse to give Information that we have, ready.
> I am not asking for something that is difficult to do in qemu, it is
> information that qemu knows (when migration has started/ended).  And we
> are telling management apps that they need to guess when things happens
> and use polling to know it.
>    

The problem is, all of the arguments you're using to justify this for 
the migrate command is applicable for every other command we have.  Why 
do this for migrate and not for commit or savevm?

Do we really want to introduce 4 events for every command that we support?

Regards,

Anthony Liguori