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.