Re: KVM call agenda for Mar 16

Avi Kivity
2010-03-16T09:43:52Z

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