[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change han

From: Alon Levy
Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
Date: Wed, 6 Jun 2012 17:52:40 +0300
User-agent: Mutt/1.5.21 (2011-07-01)

On Wed, Jun 06, 2012 at 03:03:37PM +0200, Gerd Hoffmann wrote:
>   Hi,
> >> I literally have danpb's event introspection patches from Luiz's PULL
> >> request testing on my system right now to be pushed.
> Good.
> > this?: [PATCH 29/29] Add 'query-events' command to QMP to query async events
> > 
> > This is about libvirt getting qemu's event list. I am talking about qemu
> > getting libvirt to say "we support event SPICE_MIGRATE_DONE".
> Why do you think we need this?  Other way around (libvirt detecting
> whenever qemu supports SPICE_MIGRATE_DONE event) should be good enougth, no?
> > i.e. Yet
> > another capability negotiation, during the handshake QMP phase.
> I'm sure libvirt will use query-events for other reasons anyway, so
> there is no extra overhead for this.

What Anthony suggested, using a command line switch, would work fine for
the problem I am talking about. The problem is how do we know that
libvirt will support our new event. Libvirt using query-events doesn't
help - unless you suggest we intercept it and record "libvirt is aware
of our new event, it probably supports it", but that's obviously wrong.

If libvirt doesn't support this event we want to fall back to
semi-seamless migration, if it does we want to do seamless migration by
waiting for the source to complete guest migration, send the spice
client a notification that the target is alive, then send this
event, and libvirt will then close the source vm - migration downtime is
unaffected since we only delay the closing of the vm after it is "dead",
i.e. stopped and migrated.

> cheers,
>   Gerd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]