Re: KVM call agenda for Mar 16

Daniel P. Berrange
2010-03-16T10:31:51Z

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

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