On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote: > Chris Wright <chrisw@xxxxxxxxxx> 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 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
