[Spice-devel] [Qemu-devel] seamless migration with spice

[Gerd Hoffmann]

  Hi,

> We can either store and migrate the cache, or choose to reset it.
> In the extinct spice seamless migration solution, the cache was reset.

Hmm, this makes me wonder what the main advantage of seamless migration
used to be?  image cache was reset, surfaces didn't exist back then.  So
any image data must be retransmitted anyway, correct?

> For implementing this approach, I think that the first display channel
> that handles migration can freeze the source cache, and send
> SPICE_MSG_DISPLAY_INVAL_ALL_PIXMAPS to the client (together with the
> corresponding "wait list" - i.e., other display channels' message
> serials we should wait for before resetting the cache).

Looks sane to me.

> In the old solution, resetting the client side cache was performed only
> after the channel that freezed the cached completely switched to the
> destination. This required migrating the "wait list" and the last
> message serial. Then, the freezer channel sent the
> SPICE_MSG_DISPLAY_INVAL_ALL_PIXMAPS with the MAX(migrated_wait_list,
> current_cache_wait_list_serial).
> I'm not sure why the old solution initiated the reset from the
> destination and not from the source. Maybe for a case that for some
> reason the client stayed connected to the source and the vm was started
> on the source???

Could be.  Nowdays qemu informs spice-server whenever the migration was
successful or not, so this should not be needed any more.

> If we choose to restore the complete cache on the destination side we
> need to:
> (1) freeze the cache
> (2) send the cache to the destination. The cache holds the ids of the
> images in stored in the client side cache, and the lru list of them.
> In addition, for each such image we store the serial of the last message
> that accessed it from each display channel.
> (3) start the destination cache in freeze mode
> (4) Unfreeze the cache after it is restored from the migtation data.

Ok.

> In any case, the migration data should also hold the cache size (which
> is set by the client upon connection initialization).

Why?  When the client sets it on connection initialization the dest host
should know it already ...

> about it. The only date that should be migrated to the destination
> server are (1) the dictionary size (also set by the client upon connection)

Same here, not needed I think.

> (2) the last image id in the dictionary (otherwise we should have a
> message for resetting the dictionary on the client side).

A message would need to be simliar to
SPICE_MSG_DISPLAY_INVAL_ALL_PIXMAPS for display channel syncronization,
correct?

> (C) Surfaces:
> Again, 2 options:
> (1) Not migrate anything related to the client's off-screen surfaces.
> Consequence: we might send the client off-screen surfaces that we have
> already sent.
> (2) Migrate the list of surfaces that the client holds and their lossy
> regions (or just the regions extents, for simplicity).

Do we have any stats on image / surface usage?

I'd expect image cache tends to hold short-living images, whereas
surfaces tends to hold long-living ones, so preserving surfaces is more
important than keeping the image cache.  That expectation isn't backed
by any real data through, and it probably also depends on the guest os
and driver version ...

> (D) In order to promise that in flight data from/to the src server won't
> get lost we still need to assure that the src server is not killed
> before spice completes its work - and then we are back to the original
> problem that started this thread.

I think this is needed no matter which way the migration state travels,
correct?

cheers,
  Gerd