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

[Yonit Halperin]

On 08/16/2011 12:53 PM, Yonit Halperin wrote:
> 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).
>
Missed the compatibility with qemu:
we need to bounce spice server version and qemu will need to support the 
older version (only call spice_server_migrate_switch when migration 
completes).
Newer spice server will still need to support spice_server_migrate_switch.
> Any comments? If there are any tricky parts I missed, let me know.
>
> Cheers,
> Yonit.
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel