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

[Daniel P. Berrange]

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

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