| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
Pending motion acks, and keyboard modifiers messages will be sent
by the destination after receiving the migration data.
|
| |
|
|
|
|
|
|
| |
Storing the motion count in uint16_t and not in uint32_t since
the exact count is not important, just its division in
SPICE_INPUT_MOTION_ACK_BUNCH (see the next 2 patches).
|
|
|
|
|
| |
If the server is a destination of seamless migration, send msgs to the client,
even though an init msg has not been sent to the client.
|
|
|
|
|
|
|
|
| |
red_channel_client_set_message_serial
red_channel_client_set_message_serial is called for setting
the serial of the display channel messages after migration (on the
destination side). The serial is retrieved from the migration data.
|
|
|
|
| |
The relevant flags reside in RedChannelClient and RedClient
|
|
|
|
|
|
|
|
|
|
| |
The playback and record channel send SPICE_MSG_MIGRATE to the client.
Both playback and record channel does not have a state to restore:
while in the legacy migration implementation the record channel
used to restore the mode and start time, it looks unnecessary since
the client receives from the src MSG_RECORD_STOP before the migration
completion notification (when the vm is stopped). Afterwards, when the vm
starts on the dest side, the client receives MSG_RECORD_START.
|
|
|
|
|
|
|
|
| |
Due to the fix in the previous patch, snd_disconnect_channel can be
called both when there is write/read error in the channel, or from
red_client_destroy (which calls client_cbs.disconnect).
Multiple calls to snd_disconnect_channel resulted in calling
channel->cleanup(channel) more than once (double release).
|
|
|
|
|
|
|
|
|
|
|
| |
snd channel wasn't added to be part of the client's channels list.
As a result, when the client was destroyed, or migrated, snd channel
client wasn't destroy, or its migration callback wasn't called.
However, due to adding dummy channels to the client, we need special
handling for calls to disconnecting dummy channel clients.
TODO: we need to refactor snd_worker to use red_channel
|
|
|
|
|
|
| |
Restoring display channel from migration data.
Not notifying client about changes that are artifacts of loading the vm.
Remove legacy migration code.
|
| |
|
| |
|
| |
|
|
|
|
| |
The default callback sends SPICE_MSG_MIGRATE to the client.
|
|
|
|
|
|
| |
A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE.
SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item
type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
|
|
|
|
|
|
|
|
| |
might have changed since it was created
If reading/writing from the device have occured before migration data
has arrived, the migration data might no longer be relvant, and we
disconnect the client.
|
|
|
|
| |
Also removed old migration leftovers.
|
|
|
|
|
| |
Also removed some unused definitions from reds that used to belong to
old agent and migration code.
|
|
|
|
|
|
|
|
|
| |
Before sending the above msg, if there is a pending partial msg that
has been read from the agent, we send it to the client. The alternative
was to keep the msg as part of the migration data, and then
to send it to the destination server via the client and to wait there
for the msg chunk completion, before sending it to the client. Of
course, the latter is less efficient.
|
| |
|
|
|
|
| |
agent)
|
|
|
|
|
|
|
|
|
| |
A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE.
SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item
type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
Also removed sending SPICE_MSG_MIGRATE. It will be handled in the next
patch.
|
|
|
|
| |
The pipe item is used for sending messages that don't have body.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The above is the default behaviour for red_channel_client, if
client_cbs.migrate is not registered as part of red_channel_register_client_cbs
|
|
|
|
|
| |
The enum should start from PIPE_ITEM_TYPE_CHANNEL_BASE, otherwise,
PIPE_ITEM_TYPE_ERROR is handled like PIPE_ITEM_TYPE_SET_ACK.
|
|
|
|
|
|
|
|
|
| |
Attach/detach a client to a SpiceCharDeviceState upon its
connection/disconnection, instead of upon reader_add/remove messages.
When the client is removed from a SpiceCharDeviceState, all the
messages from this client are removed from the device write queue.
This shouldn't happen when we only receive reader_remove and the
client is still connected.
|
| |
|
| |
|
|
|
|
|
| |
The above is the default behaviour for red_channel_client, if
client_cbs.migrate is not registered as part of red_channel_register_client_cbs
|
| |
|
| |
|
|
|
|
| |
for migraion data
|
| |
|
|
|
|
|
|
|
| |
When restoring migration data, we also restore data that is addressed to
the device, and that might have been originated from more than 1
message. When the write buffer that is assoicated with this data is
released, we need to free all the relevant tokens.
|
| |
|
| |
|
|
|
|
|
|
| |
Tracking the channels that wait for migration data. If there
is a new migration process pending, when all the channels have
restored their state, we begin the new migration.
|
|
|
|
|
|
|
| |
The relevant code is common to all channels.
The patch also contains a fix to the return value for
handle_migrate_data callback: s/uint64_t/int
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In semi-seamless, SPICE_MSG_MAIN_MIGRATE_END is sent.
In seamless, each channel migrates separately.
The src waits till all the clients are disconnected (or a timeout), and
then it notifies qemu that spice migration has completed.
The patch doesn't include the per-channel logic for seamless migration
(sending MSG_MIGRATE, MIGRATE_DATA, etc.).
|
|
|
|
|
|
|
|
|
|
| |
- handle SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS
- reply with SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK
- prepare the channels for migration according to the migration
type (semi/seamless)
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sending SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS and handling
SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS
The src side signals the client to establish a connection
to the destination.
In seamless migration, the client is also used to perform
a sort of handshake with the destination, for verifying
if seamless migration can be supported.
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
|
|
|
|
|
|
| |
Also Update server and client according to the change of
SpiceMsgMainMigrationBegin: it now holds all the fields inside
SpiceMigrationDstInfo.
|
|
|
|
|
|
|
| |
The file will hold the declarations of the different migration
data messages (depending on the channel), that will be passed
from the src server to the dst server, via the client, using
SPICE_MSG_MIGRATE_DATA.
|
|
|
|
|
|
|
| |
New api entries:
spice_server_vm_start
spice_server_vm_stop
spice_server_set_seamless_migration
|