On Tue, Aug 16, 2011 at 06:54:58PM -0400, 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. > > 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. > > 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"? > > > 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. >
I agree, I think introducing a new message with a caps looks cleaner, if you see such a message being sent you imediately know you are dealing with a new server, no need to add meaning to an existing message that requires you to check what version the server is to know the specific meaning intended. > cheers > > -- > Marc-André Lureau > _______________________________________________ > Spice-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
