[Spice-devel] Stream migration between Spice servers

[Victor Toso]

Hi,

On Tue, Feb 16, 2016 at 04:44:57PM +0100, Francois Gouget wrote:
>
> 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.

>From my point of view, this is what I would expect. We close the stream
and let spice-server detect a new stream in the target host.

Moving the video-stream on different hosts could be extra work without
any real gain (please, correct me if I'm wrong).

I agree that different hosts could have different capabilities for
encoding so handling this case would be needed if we must migrate
video-streams.

I would love to understand the rationale behind this.

Cheers,
  toso

>
>
> 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>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel