[Spice-devel] Stream migration between Spice servers

[Francois Gouget]

I am having trouble with the comment describing how migrating a VM from 
one Spice server to another affects streams. It's in 
spice-gtk/src/channe-display.c, just before 
display_session_mm_time_reset_cb():
https://github.com/SPICE/spice-gtk/blob/449ccb3f2564c1fb98fcdd0f7776ad2f738740ba/src/channel-display.c#L1284

The first issue is that it does not clarify whether streams are 
migrated. I did not look at the QEMU code but would expect it to not be 
the case as I only expect the VM state to be migrated and I consider 
streams to be something slapped on top of it by the Spice server. Also 
streams are very closely tied to the details of the Spice server 
implementation and could not be migrated if the destination Spice server 
is not the exact same version.

This is somewhat important because it looks like the code thinks 
it's possible for stream's frames mmtime to run backwards during a 
migration. See display_stream_test_frames_mm_time_reset():
https://github.com/SPICE/spice-gtk/blob/449ccb3f2564c1fb98fcdd0f7776ad2f738740ba/src/channel-display.c#L1351

    tail_op = spice_msg_in_parsed(tail_msg);
    new_op = spice_msg_in_parsed(new_frame_msg);

    if (new_op->multi_media_time < tail_op->multi_media_time) {
        SPICE_DEBUG("new-frame-time < tail-frame-time (%u < %u):"
                    " reseting stream, id %d",
    [...]

If streams are not migrated, then the mmtime of the frames they contain 
should be monotonically increasing and thus the above code should never 
trigger.

What would happen during a migration is that the stream of the source 
server would end, and the destination server would detect the same video 
being played and create a new stream for it with frame mmtimes based on 
the destination's mmtime.


Also the following part seems self-contradictory:

* (case 2) mm-time is synced with dst-time, but frames that were in the 
* command ring during migration still arrive (such frames hold 
* src-time).
[...]
* case 2 is less likely, since at takes at least 20 frames till the
* dst-server re-identifies the video stream and starts sending stream 
* data

But my understanding is that in case 2 the frames come from the source 
server and thus don't depend on the time it takes for the destination 
server to detect a video stream.

-- 
Francois Gouget <fgouget at codeweavers.com>