Hans de Goede píše v Po 12. 03. 2012 v 09:51 +0100: > Hi, > > On 03/12/2012 08:57 AM, Gerd Hoffmann wrote: > > Hi, > > > >>> What about the second part? it's independant of the async issue. > >> > >> Isn't this a client problem? The client has this state, no? > > > > It is state of the client<-> server session. Today spice client > > creates a new session on migration, so there is simply no need to > > maintain any state. Drawback is that everything needs to be resent from > > the server to the client. Thats why we want be able to continue the > > spice session, so the client caches will stay valid. > > > > Of course the spice-server on the migration target needs the session > > state for that, i.e. know for example which bits the client has cached > > which it hasn't. > > > >> If the state is stored in the server, wouldn't it be marshaled as part > >> of the server's migration state? > > > > spice-server is stateless today when it comes to migration. QXL handles > > all (device) state, by keeping track of some commands (such as > > create/destroy surface) which it needs to transfer on migration, and by > > asking spice-server to render all surfaces on migration, which > > effectively flushes the spice server state to qxl device memory. > > > > To transfer the client session state there are basically two options: > > > > (a) transfer it as part of the qemu migration data stream. I don't > > want have any details about the qemu migration implementation > > and/or protocol in the spice-server library api, which basically > > leaves a ugly "transfer-this-blob-for-me-please" style interface > > as only option. > > > > (b) transfer it as part of the spice protocol. As the spice > > client has a connection to both source and target while the > > migration runs we can send session state from the source host via > > spice client to the target host. This needs some form of > > synchronization, to make sure both vmstate and spice migration > > are completed when qemu on the source machine quits. > > The problem with (b) is, that iirc the way b was implemented in the past > was still the big blob approach, but then pass the blob through the client, > which means an evil client could modify it, causing all sorts of "interesting" > behavior inside spice-server. Since we're re-implementing this to me the > send a blob through the client approach is simply not acceptable from a > security pov, also see my previous mail in this thread. >
In addition to security POV, it's also bad from network usage POV - while network connection among hosts is gigabit or better, client may be connected over high-latency low-bandwidth WAN. Sending any data through client makes absolutely no sense in such cases. David > > I think (b) is the better approach. > > I disagree. Note that there is more info to send over then just which > surfaces / images are cached by the client. There also is things like > partial complete agent channel messages, including how much bytes must be read > to complete the command, etc. > > IMHO (b) would only be acceptable if the data send through the client stops > becoming a blob. Instead the client could simply send a list of all surface > ids, > etc. which it has cached after it connects to / starts using the new host. > Note > that the old hosts needs to send nothing for this, this is info the client > already > has, also removing the need for synchronization. As for certain other data, > such > as (but not limited to) partially parsed agent messages, these should be > send through the regular vmstate methods IMHO. > > So I see 2 options > > 1) Do (a), sending everything that way > 2) Do (a) sending non client state that way; and > let the client send state like which surfaces it has cached > when the new session starts. > > Regards, > > Hans > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
