[Qemu-devel] Re: KVM call agenda for Mar 16

[Avi Kivity <avi@redhat.com>]

On 03/16/2010 11:29 AM, Daniel P. Berrange wrote:
> On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote:
>    
>> Chris Wright<chrisw@redhat.com>  wrote:
>>      
>>> Please send in any agenda items you are interested in covering.
>>>        
>> Migration:
>> - flexible migration:  I hope to sent an RFC patch on time for the
>>    call.  idea is to use subsections.
>>
>> - callbacks.  block migration introduced several callbacks:
>>    * cancel()
>>    * get_status()
>>    * release()
>>    in spice we need now another to callbacks: on_start() and on_end().
>>     * on_start(): tells spice that migration has started (it will then
>>       manage certificates, passwords, ... itself)
>>     * on_end(): it is called when migration ends.  spice use it to
>>       transparently connect to the new host and user don't have to "reconnect"
>>
>> - what to do on migration error:
>>    - target side:  libvirt folks want the program to print a message if
>>      it fails.  Current code spent 100% cpu time doing select on a closed
>>      fd.  (patches already on the list to make it wait without using
>>      cpu).
>>      
> No, that is not correct. We want QEMU to exit when incoming migration
> fails. Printing to stderr is just something that will end up in the
> logs for admin to further diagnose the problem if required. There is
> nothing to be gained by leaving QEMU running, and everything to loose
> since the failed migration may have left it in a dangerous state from
> which you do not want to attempt incoming migration again.
>
> If we really want to leave it running when migration fails, then we're
> going to have to add yet another QMP event to inform libvirt when
> migration has finished/failed, and/or make 'query_migrate' work on
> the destination too.
>    

A qmp event seems the logical thing to do?  Exiting can happen for many 
reasons, a qmp event is unambiguous.

>>    - source side: current behaviour if migration fails is to stop the
>>      vm.  We have requests to make it continue (remember that this is
>>      live migration).  what to do?  adding a paramenter like the block
>>      layer:
>>        migration_error=[stop|continue]
>>      any better ideas.
>>      
> A parameter to the 'migrate' monitor command would be the logical
> place if we needed this configurable.
>
> Incidentally I have a feeling we might need to introduce a migration
> event in QMP. Currently libvirt polls on the 'query_migrate' command
> to get the ongoing migration status. This means there can be a delay
> in detecting completion as long as the polling interval - for this
> reason we just dropped libvirt's polling time from 1/2 sec to 50ms
> to ensure prompt detection.
>    

Whenever you implement a polling loop, can you send an event to qemu-devel@?

Polling loops are an indication that something is wrong.

-- 
error compiling committee.c: too many arguments to function