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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/27/2010 10:58 AM, Juan Quintela wrote:
> Luiz Capitulino<lcapitulino@redhat.com>  wrote:
>    
>> On Wed, 26 May 2010 11:55:31 -0500
>> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>      
>    
>>> That's exactly how the protocol is designed.  That was one of the major
>>> improvements of QMP over the human monior.
>>>        
>>   Yes and it already has 'id' support:
>>
>> { "execute": "cont", "id": "luiz" }
>> {"timestamp": {"seconds": 1274966635, "microseconds": 776813}, "event": "RESUME"}
>> {"return": {}, "id": "luiz"}
>>
>>   But it doesn't detect duplicates, this is something I think it's up
>> to the client to do, do you agree?
>>
>>      
>>> This is how the info balloon command works, BTW.
>>>        
>>   I won't remember the details now, but that interface has some issues and it
>> has to be reviewed.
>>
>>      
>>> Since there's a clear correlation between the request and the result of
>>> the request, an asynchronous command is what makes the most sense.  It
>>> eliminates the problem of how to pass QErrors via an event which is one
>>> of the problems with the current event proposal.
>>>        
>>   Not exactly, this is a problem with QError not the event proposal. We'll
>> have the same issue if we decide to include errno in the migrate errors and
>> the problem still exists with the BLOCK_IO_ERROR event.
>>
>>   That said, I do agree that migrate should be asynchronous. This yet another
>> thing we may want to fix before 0.13.
>>      
> How difficult is that?
>    

Easy.  I've got a patch locally and will submit an RFC this afternoon.  
I'm currently converting the migration error's to QError to make sure 
than when an error occurs, we can report it in a meaningful way.

We'll still need the MIGRATION_CONNECTED event though and I'm not 
currently planning on working on that.

>> [...]
>>
>>      
>>>>> For tcp: and unix:, a CONNECTED event absolutely makes sense (every
>>>>> socket server should emit a CONNECTED event).  Unfortunately, after
>>>>> CONNECTED you lose the monitor until migration is complete.  If
>>>>> something bad happens, you have to exit qemu so once the monitor
>>>>> returns, migration has completed successfully.
>>>>>
>>>>> If we introduce live incoming migration, we'll need to rethink things.
>>>>> I would actually suggest that we deprecate the incoming command if we do
>>>>> that and make incoming migration a monitor command.  I would think it
>>>>> should have the same semantics as migrate (as an asynchronous command).
>>>>> A CONNECTED event still makes sense for tcp and unix protocols but I
>>>>> don't think events make sense for start stop vs. an asynchronous command
>>>>> completion.
>>>>>
>>>>>            
>>>> Do you actually mean 'deprecate -incoming arg' here ?
>>>>
>>>>          
>>> Yes.  And by deprecate, I really mean that -incoming just becomes
>>> syntactic sugar for executing a monitor command immediately.
>>>        
>>   But we can't change -incoming itself, since our command-line is supposed
>> to be stable, right?
>>
>>   Also, Juan has said that replacing that arg with a monitor command
>> doesn't work, as qemu would have to be started in paused monitor for this
>> to work.
>>
>>   So, what about introducing a -incoming-monitor command, which puts qemu
>> in the right state for migration, but requires a migrate_incoming command
>> to actually start migration?
>>      
> this -incoming-monitor is called -S, that should have a long name of
> -no-autostart
>
> that is what it does, and what we need for incoming migration as monitor
> command.  Nothing new to see here.
>    

Agreed.  We could introduce a migrate_incoming command but it wouldn't 
be possible to poll it's results while the command executed.  I'd rather 
not do that though because that's potentially ugly for clients to deal with.

Regards,

Anthony Liguori

> Later, Juan.
>