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

[Daniel P. Berrange]

On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote:
> Chris Wright <address@hidden> 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.

>   - 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.

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|