From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S74Y1-0000hS-TT for qemu-devel@nongnu.org; Mon, 12 Mar 2012 08:40:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S74Xr-0004mI-WE for qemu-devel@nongnu.org; Mon, 12 Mar 2012 08:40:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S74Xr-0004iP-AA for qemu-devel@nongnu.org; Mon, 12 Mar 2012 08:40:11 -0400 From: David =?UTF-8?Q?Ja=C5=A1a?= In-Reply-To: <4F5DB906.2030508@redhat.com> References: <4F5CA590.1000605@redhat.com> <4F5CB429.4000907@codemonkey.ws> <20120311152528.GD7273@garlic.redhat.com> <4F5CC692.7050002@codemonkey.ws> <4F5DAC69.6010002@redhat.com> <4F5DB906.2030508@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 12 Mar 2012 12:39:55 +0100 Message-ID: <1331552395.5548.521.camel@dhcp-29-7.brq.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Spice-devel] seamless migration with spice Reply-To: "spice-devel@freedesktop.org" , qemu-devel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "spice-devel@freedesktop.org" , qemu-devel Cc: Anthony Liguori Hans de Goede p=C3=AD=C5=A1e v Po 12. 03. 2012 v 09:51 +0100: > Hi, >=20 > 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 f= rom > > 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 cache= d > > which it hasn't. > > > >> If the state is stored in the server, wouldn't it be marshaled as pa= rt > >> of the server's migration state? > > > > spice-server is stateless today when it comes to migration. QXL hand= les > > 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 basical= ly > > leaves a ugly "transfer-this-blob-for-me-please" style interfa= ce > > 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. >=20 > The problem with (b) is, that iirc the way b was implemented in the pas= t > was still the big blob approach, but then pass the blob through the cli= ent, > which means an evil client could modify it, causing all sorts of "inter= esting" > behavior inside spice-server. Since we're re-implementing this to me th= e > send a blob through the client approach is simply not acceptable from a > security pov, also see my previous mail in this thread. >=20 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. >=20 > 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. >=20 > IMHO (b) would only be acceptable if the data send through the client s= tops > becoming a blob. Instead the client could simply send a list of all sur= face ids, > etc. which it has cached after it connects to / starts using the new ho= st. Note > that the old hosts needs to send nothing for this, this is info the cli= ent already > has, also removing the need for synchronization. As for certain other d= ata, such > as (but not limited to) partially parsed agent messages, these should b= e > send through the regular vmstate methods IMHO. >=20 > So I see 2 options >=20 > 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. >=20 > Regards, >=20 > Hans > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel --=20 David Ja=C5=A1a, RHCE SPICE QE based in Brno GPG Key: 22C33E24=20 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24