On Tue, Mar 16, 2010 at 11:43:48AM +0200, Avi Kivity wrote: > 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@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. > > > > A qmp event seems the logical thing to do? Exiting can happen for many > reasons, a qmp event is unambiguous. Yes, for the QEMU upstream adding an event is more flexible. I had originally suggested exiting in the context of the Fedora bug report which was for QEMU 0.10.x which has no events capability. > > > >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@? Yep, sure thing. This is the only polling loop that isn't related to I/O stats collection. > > Polling loops are an indication that something is wrong. Except when people suggest they are the right answer, qcow high watermark ;-P Regards, 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
