[Spice-devel] changing the timing of spice client linking in migration (RHBZ #725009)

[Hans de Goede]

Hi,

On 08/25/2011 12:24 PM, Yonit Halperin wrote:
> Hi all,
> here is the original email I sent for #725009.
> ===> For this plan no change is required in libvirt. <===
>
> This plan does not bring back seamless migration to live. But it does
> make the current host switching less noticeable by the user.
> The difference from seamless migration is that in-progress operations fail (equivalent to disconnect and reconnect): audio, smartcard, usb (? not sure for which rhel version it is designated), vdagent (copy-paste).
>
> After some discussions with Alon, we came to the conclusion that in order to revive seamless migration we need to solve the following race conditions :
>
> race 1: target starts before the client managed to connect to it.
> possible solutions:
> 1) qxl savevm will hold (with timeout) migration till client is connected to target. Will it be acceptable by qemu? (Gerd?)
> However, qxl is not necessarily installed...
> 2) spice will try to connect the target immediately when it receives client_migrate_info from libvirt, and will wait till it succeeds (and by this will hold migration. (libvirt - can we count on executing client_migrate_info just before migration starts and not a long time before?)
>
> race 2: target starts before it manages to restore the source pre-migration state (which was sent to it from the src server, via the client).
> solution:
> the target won't attach any spice device interface till it restores its state (with timeout). i.e., it will queue any request from the quest, and will operate on them only after it has been restored.
>
> other changes in spice:
> due to the broken seamless migration, spice channels were not maintained to keep supporting it (i.e., sending the minimal amount of data that is required for the target to restore the channel's state), especially the new channels (smartcard, usb(?), agent transmissions, etc.). So, implementation in this level is required as well.

For usb no form of migration is currently supported, this needs to be fixed.
I plan to work on switch-hot migration first. Where the plan was basically
queue up any messages in either between the disconnect and the reconnect
(and hide the disconnect / reconnect from the usb-redir device in qemu, resp.
the libusbredirhost object in the client).

With the change that the client does the connect to the other vm earlier
there does not need to be much change to this plan (aka vaporware for now),
we just need to make sure there is one clear point in time where the
switch over happens from the channel pov. So that any messages send past that
point get send from / to the new vm, and the new vm is aware of any messages
send to the old vm before this time.

Esp. the second point is tricky, since some messages may be "in flight" so
we need some way to "drain" the channel from in flight messages in both
direction before finishing the migration.

To be clear with in flight I mean they have left the client and not
yet reached the server, iow they are queued up in some tcp stack queue
of either the client / a router / the host.

Regards,

Hans