On 03/15/12 13:36, Hans de Goede wrote: > Hi, > > On 03/15/2012 01:11 PM, Yonit Halperin wrote: >> On 03/13/2012 09:40 AM, Gerd Hoffmann wrote: >>> Hi, >>> >>>> It is not easy when you have 2 components, and it is much less easy >>>> when >>>> you have 3 or 4 components. So why make it more complicated if you can >>>> avoid it. Especially since there is no functional reason for making the >>>> qemu/client capabilities/versions dependent on the server internal >>>> data. >>> >>> qemu has ways to handle compatibility in the vmstate format. We can use >>> those capabilities. That of course requires exposing the structs to be >>> saved to qemu and adds some complexity to the qemu<-> spice interface. >>> >>> What session state is needed by the target? >>> What of this can be negotiated between client and target host without >>> bothering the source? >>> What needs be transfered from source to target, either directly or via >>> client? >>> >>>>> If this is a hard requirement then using the vmstate channel isn't >>>>> going >>>>> to work. The vmstate is a one-way channel, no way to negotiate >>>>> anything >>>>> between source and target. >>>>> >>>> We can do this via the client. >>> >>> Then you can send the actual state via client too. >>> Out-of-band negotiation for the blob send via vmstate scares me. >>> >>> Can we please start with a look at which state we actually have to send >>> over? >> Ok, I can take the display and sound channels. >> Alon, can you take the smartcard? >> Hans, spicevmc? > > Easy, the spicevmc channel has no state which needs to be migrated, except > for things in the red_channel_client base class: > > 1) Partially received spice messages > 2) Possible pending pipe items when writes from qemu -> client have > blocked. > > I assume that the red_channel_client base class will handle migrating them, > if we migrate them at all. > > Instead of migrating we could: > For 1. expect the client to stop sending new messages at a certain point > during the migration, and ensure we've processed any pending messages > after this point. > > For 2. we could flush pending items and set a flag to stop channel > implementations from queuing new ones, at which point for spicevmc the > data will get queued inside qemu and migrating it no longer is > a spice-server problem to migrate it (and we need migration support for > the data possibly queued inside qemu anyways).
Sounds good. Any state qemu knows about is easy to migrate, and not having any state (aka unprocessed buffers) inside spice-server is great. We render everything to surfaces on migration for the same reason: have no state (aka unprocessed rendering ops) in spice-server. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
