From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S73Jt-0006vj-IT for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:22:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S73JT-0003nI-Lk for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:21:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S73JT-0003n3-DT for qemu-devel@nongnu.org; Mon, 12 Mar 2012 07:21:15 -0400 Message-ID: <4F5DDC97.1030701@redhat.com> Date: Mon, 12 Mar 2012 12:23:03 +0100 From: Hans de Goede MIME-Version: 1.0 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> <4F5DC604.9010702@redhat.com> In-Reply-To: <4F5DC604.9010702@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Spice-devel] seamless migration with spice List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "spice-devel@freedesktop.org" , qemu-devel , Anthony Liguori Hi, On 03/12/2012 10:46 AM, Gerd Hoffmann wrote: > Hi, > >> 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. > > Agree. It should be a normal spice message which goes through the spice > marshaller for parsing& sanity checking. > >> 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. > > Is there a complete list of the session state we need to save? > There is still code in spice-server for the old seamless migration, someone could go through that and use that as an initial list of session state we need to save. >> IMHO (b) would only be acceptable if the data send through the client stops >> becoming a blob. > > Using (a) to send a blob isn't better. > It has the distinct advantage that we can trust the contents of the blob which makes life significantly easier IMHO. >> 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. > > Yes, some session state is known to the client anyway so we don't need a > source<-> target channel for them. > >> 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. > > That isn't easy to handle via vmstate, at least as soon as this goes > beyond a fixed number of fields aka 'migrate over this struct for me'. > Think multiple spice clients connected at the same time. > >> 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. > > I think we have to look at each piece of state information needed by the > target and look how to handle this best. Agreed, so for starts someone needs to make a list of all session state we need to save. Regards, Hans