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

Wed Aug 17 00:47:50 PDT 2011

On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
> Hi
>
> I am also unfamiliar with the migration code, in particular the qemu ->  qemu part. It seems to me that no spice transmission occurs, but only guest memory. Is that correct? How is state of the channel restored? Perhaps it doesn't need any state transmission, and the connection of a client to the target is enough to revive the channels after migration.
>
Hi,
You are right. No Spice transmission occurs. When we supported seamless 
migration we did transfer spice info. This was done via the client: each 
source server channel sent opaque migration data to the corresponding 
channel in the client. The client channel passed this data to the dest 
server and the dest server restored its state from this data.
We don't do it anymore since the current migration notifiers, afaik, 
don't allow us to hold the target vm stopped till we make sure the 
target server has restored its state. We can't prevent the target vm 
from starting => we have synchronization problem. That is why 
switch_host makes the client reconnect from scratch to the target.

> Thanks a lot Yonit for your clear mail, it helps a lot.
:)
>
> ----- Original Message -----
>> 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.
>
> Contrary to Christophe, I don't think we should be afraid of using those functions which have not been supported and used since quite some time, afaik.
>
>> 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.
>
> For the same reason, I guess we can break messages, as long as proper version/caps check are perform before client&  server receive them.
>
>> * 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
>
> flags=0 == No NEED_FLUSH or DATA_TRANSFER. ok
>
>> (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.
>
> It looks to me like you would like to revive the seamless migration.
>
see the above explanation about seamless.
> Wouldn't it be simpler to just leave connection id == 0 for now, and do regular connection? Wouldn't that also work like "switch-host"?
>
Since we want to execute the linking to the target before the logical 
target spice session starts, it is problematic not to let the target 
server know it is a migration target: one of the problems is that upon 
connection, the server display channel expect an INIT message from the 
client. If timeout occurs, it disconnects. This is not desirable when 
this is only the initial connection (the one triggered by 
migrate_start), and the actual communication will start only when 
migration ends.

Besides, it will also save us time and other artifacts that are a result 
of executing a fresh connection. E.g., We can avoid the network 
bandwidth test. Though I guess the bandwidth can change from one host to 
another....But preforming the network test upon linking is more 
complicated since the client doesn't listen yet to the socket...Maybe we 
can neglect this for now and assume the same bandwidth for the new host?
>> 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).
>>
>
> Preferably, I would introduce SPICE_MSG_MAIN_MIGRATE_BEGIN2 etc. and deprecate the older messages. From what I understand, we are now preferably using caps rather than bumping protocol version.
o.k. But when do we actually change the protocol version?
>
> cheers
>