| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
This new call is used in order to identify whether qemu, or
the management (e.g. libvirt), support seamless migration.
If it is supported, qemu spice cmd-line configuration should have
seamless-migration=on.
In addition, we disable seamless migration support if multiple clients
are allowed. Currently, only one client is supported.
|
|
|
|
|
|
|
| |
Till now, red_worker was notfied about vm status changes via QXLWorker->start/stop
(or spice_qxl_start/stop).
Newer qemu, that supports calling spice_server_vm_start/stop, will call only
these routines, and won't call QXLWorker->start/stop.
|
|
|
|
|
|
|
|
|
| |
When vm state changes (started/stopped), we notify all the
attached SpiceCharDeviceStates about the change. This is mainly required
for avoiding writing/reading to/from the device during the non-live
stage of migration.
spice version will be bumped in one of the following patches.
|
|
|
|
|
|
| |
The list of attached char_devices will be used in the next patch
for notifying each instance of SpiceCharDeviceState when the vm
is started or stopped.
|
|
|
|
|
| |
if vdi_port_read_buf_process failes, we detach the agent and also release
the read buffer. We shouldn't try reading from the device afterwards.
|
|
|
|
| |
send SPICE_MSG_MAIN_AGENT_CONNECTED_TOKENS
|
|
|
|
| |
for checking if all the channel clients connected support the cap
|
|
|
|
|
|
| |
All the real work is being done in spice-common, so this patch is just
hooking up the virtual calls and adding the SPICE_DISPLAY_CAP_COMPOSITE
capability.
|
|
|
|
|
|
| |
In red-parse-qxl.c add support for parsing QXLComposite into
SpiceComposite. In red-worker.c add support for marshalling
SpiceComposite onto the wire.
|
|
|
|
|
|
| |
Graduality is irrelevant for A8 images, so instead of using RGB-ness
as a short-cut, add a new macro BITMAP_FMT_HAS_GRADUALITY() that
returns true for the existing RGB images, but false for A8.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After marshalling MSG_STREAM_CREATE, there is no need to ref and
unref stream->current before and after completing the sending of the
message (correspondingly). The referencing is unnecessary because all
the data that is required from the drawable (the clipping), is copied
during marshalling, and no field in the drawable is referenced (see
spice_marshall_msg_display_stream_create).
Moreover, the referencing was bugous:
While display_channel_hold_pipe_item and
display_channel_client_release_item_after_push referenced and
dereferenced, correspondingly, stream->current, stream->current might
have changed in between these calls, and then we ended up with one drawable
leaking, and one drawable released before its time has come (which
of course led to critical errors).
|