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

[Yonit Halperin]

Hi,
Today, we handle migration in the client side by disconnecting from the 
source and connecting to the target. The disconnection
and reconnection occur in response to 
SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST, which is sent from the source when 
migration ends.
In order to solve RHBZ #725009, i.e., to avoid expiration of tickets at 
migration target before spice client has attempted to connect, it has
been proposed that spice client will connect to the target when 
migration starts, but will complete the connection only after
migration ends.
This pathway is more similar to how spice worked when we could support 
seamless migration. But, in contrast to seamless migration,
we still need to initialize data on the client side upon switching to 
the target (this cleanup was achieved by the explicit disconnection and 
reconnection).

Here are the details of the implementation I suggest:

qemu
=====
ui/spice-core::migration_state_notifier should handle MIG_STATE_ACTIVE 
(for migration start) and MIG_STATE_ERROR/CANCELLED by calling 
spice_server_migrate_start, and spice_server_migrate_end, respectively.
These callbacks are currently declared in spice-experimental.h.

spice-server
=============
(A) Migration source side

     * reds::spice_server_migrate_start:
       send SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST.
       We can't use SPICE_MSG_MAIN_MIGRATE_BEGIN since it doesn't
       include the certificate information we need. But we can change it
       to be identical to SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST.

     * reds::spice_server_migrate_end(completed)
       - if (completed) => send SPICE_MSG_MIGRATE (flags=0) to all
          connected channels (via Channel->migrate).
       - if (!completed) => send SPICE_MSG_MAIN_MIGRATE_CANCEL

(B) Migration target side

reds identifies it is a migration target when the client connects with a 
connection id != 0.
When linking to a migrated channels, a special treatment is required 
(and not the support that is currently coded, since it is for seamless 
migration).
For example:
- For the main channel, (1) network test is not required (2) no need for 
SPICE_MSG_MAIN_INIT, but rather SPICE_MSG_MAIN_MULTI_MEDIA_TIME and
SPICE_MSG_MAIN_MOUSE_MODE. This way we will also save all the agent work 
we preform when initializing the main channel in the client.
- For the display channel, we mustn't call display_channel_wait_for_init 
immediately upon link, but we should expect it to arrive later (for 
setting cache and dictionary sizes).
  - For playback channel: we still need to send the current playback 
status, as opposed to seamless migration.

Spice client
============
(A) SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST
     client connects to the target, but still stays connected to the
     source host. It doesn't listen to the target sockets.
     The link message to the target contains the connection_id of the
     connection to the source (this allows the target server to identify
     itself as a migration target).
     For this part we can use most of the code in the class Migrate in
     red_client.cpp
(B) SPICE_MSG_MIGRATE
     We can use the code in red_channel::handle_migrate to switch the
     channels and start listening to the target.
     The difference is that we should implement differently the virtual
      method RedChannel::on_migrate.
     (1) Each channel must reset all the dynamic data that depends on
         the server. For example: the display channel
         needs to destroy all the surfaces and reset the caches and
         dictionary; The playback and record channel need to stop
         the current session, if there is an active one, etc.
     (2) Each channel should send to the server the initalization
         information it normally sends in RedChannel::on_connect.

(C) SPICE_MSG_MAIN_MIGRATE_CANCEL
     disconnects all the new channels. This code is already implemented
     in spice-client.

spice-protocol(?)/Backward compatibility
=========================================
should we bounce spice protocol version, or use capabilities? (if we 
change  SPICE_MSG_MAIN_MIGRATE_BEGIN structue, there is no question).

New Spice-Server with old client will send only 
SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST, and only when migration completes 
(same as today).
New client with old Spice-server will disconnect the source and will 
connect the target upon receiving SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST 
(same as today).

Any comments? If there are any tricky parts I missed, let me know.

Cheers,
Yonit.