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