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

[Alon Levy <alevy@redhat.com>]

On Wed, Jun 06, 2012 at 05:22:21PM +0800, Anthony Liguori wrote:
> On 06/06/2012 05:10 PM, Yonit Halperin wrote:
> >Hi,
> >
> >I would like to add some more points to Gerd's explanation:
> >On 06/05/2012 04:15 PM, Gerd Hoffmann wrote:
> >>Hi,
> >>
> >>>Absolutely not. This is hideously ugly and affects a bunch of code.
> >>>
> >>>Spice is *not* getting a hook in migration where it gets to add
> >>>arbitrary amounts of downtime to the migration traffic. That's a
> >>>terrible idea.
> >>>
> >>>I'd like to be more constructive in my response, but you aren't
> >>>explaining the problem well enough for me to offer an alternative
> >>>solution. You need to find another way to solve this problem.
> >Actually, this is not the first time we address you with this issues. For
> >example: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01805.html (The
> >first part of the above discussion is not directly related to the current one).
> >I'll try to explain in more details:
> >
> >As Gerd mentioned, migrating the spice connection smoothly requires the src
> >server to keep running and send/receive data to/from the client, after migration
> >has already completed, till the client completely transfers to the target. The
> >suggested patch series only delays the migration state change from ACTIVE to
> >COMPLETED/ERROR/CANCELED, till spice signals it has completed its part in
> >migration.
> >As I see it, if spice connection does exists, its migration should be treated as
> >a non separate part of the whole migration process, and thus, the migration
> >state shouldn't change from ACTIVE, till spice has completed its part. Hence, I
> >don't think we should have a qmp event for signaling libvirt about spice migration.
> 
> Spice client migration has nothing to do with guest migration.  Trying to

I don't understand this POV. If it were a VNC connection instead of a
Spice one would it make a difference? If there is an active VNC client
then it is there as a result of a user choosing to use it, so it should
be treated as part of the user experience and not as something external.
The experience from ignoring this and choosing to treat the remote
console as an unrelated part is bound to be suboptimal.

> abuse QEMU to support it is not acceptable.
> 
> >The second challenge we are facing, which I addressed in the "plans" part of the
> >cover-letter, and on which I think you (anthony) actually replied, is how to
> >tackle migrating spice data from the src server to the target server. Such data
> >can be usb/smartcard packets sent from a device connected on the client, to the
> >server, and that haven't reached the device. Or partial data that has been read
> >from a guest character device and that haven't been sent to the client. Other
> >data can be internal server-client state data we would wish to keep on the
> >server in order to avoid establishing the connection to the target from scratch,
> >and possibly also suffer from a slower responsiveness at start.
> >In the cover-letter I suggested to transfer spice migration data via the vmstate
> >infrastructure. The other alternative which we also discussed in the link above,
> >is to transfer the data via the client. The latter also requires holding the src
> >process alive after migration completion, in order to manage to complete
> >transferring the data from the src to the client.
> 
> <-->
> 
> >To summarize, since we can still use the client to transfer data from the src to
> >the target (instead of using vmstate), the major requirement of spice, is to
> >keep the src running after migration has completed.
> 
> So send a QMP event and call it a day.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >Yonit.
> >
> >>
> >>Very short version: The requirement is simply to not kill qemu on the
> >>source side until the source spice-server has finished session handover
> >>to the target spice-server.
> >>
> >>Long version: spice-client connects automatically to the target
> >>machine, so the user ideally doesn't notice that his virtual machine was
> >>just migrated over to another host.
> >>
> >>Today this happens via "switch-host", which is a simple message asking
> >>the spice client to connect to the new host.
> >>
> >>We want move to "seamless migration" model where we don't start over
> >>from scratch, but hand over the session from the source to the target.
> >>Advantage is that various state cached in spice-client will stay valid
> >>and doesn't need to be retransmitted. It also requires a handshake
> >>between spice-servers on source and target. libvirt killing qemu on the
> >>source host before the handshake is done isn't exactly helpful.
> >>
> >>[ Side note: In theory this issue exists even today: in case the data
> >>pipe to the client is full spice-server will queue up the switch-host
> >>message and qemu might be killed before it is sent out. In practice
> >>it doesn't happen though because it goes through the low-traffic main
> >>channel so the socket buffers usually have enougth space. ]
> >>
> >>So, the big question is how to tackle the issue?
> >>
> >>Option (1): Wait until spice-server is done before signaling completion
> >>to libvirt. This is what this patch series implements.
> >>
> >>Advantage is that it is completely transparent for libvirt, thats why I
> >>like it.
> >>
> >>Disadvantage is that it indeed adds a small delay for the spice-server
> >>handshake. The target qemu doesn't process main loop events while the
> >>incoming migration is running, and because of that the spice-server
> >>handshake doesn't run in parallel with the final stage of vm migration,
> >>which it could in theory.
> >>
> >>BTW: There will be no "arbitrary amounts of downtime". Seamless spice
> >>client migration is pretty pointless if it doesn't finish within a
> >>fraction of a second, so we can go with a very short timeout there.
> >>
> >>Option (2): Add a new QMP event which is emmitted when spice-server is
> >>done, then make libvirt wait for it before killing qemu.
> >>
> >>Obvious disadvantage is that it requires libvirt changes.
> >>
> >>Option (3): Your suggestion?
> >>
> >>thanks,
> >>Gerd
> >>
> >
>