From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7LdP-00042I-HY for qemu-devel@nongnu.org; Tue, 13 Mar 2012 02:55:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7LdK-0006rc-Qf for qemu-devel@nongnu.org; Tue, 13 Mar 2012 02:55:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7LdK-0006rQ-It for qemu-devel@nongnu.org; Tue, 13 Mar 2012 02:54:58 -0400 Message-ID: <4F5EEEC5.4040400@redhat.com> Date: Tue, 13 Mar 2012 08:52:53 +0200 From: Yonit Halperin 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> <4F5DF074.2030305@redhat.com> <4F5DFF3B.3040007@redhat.com> <4F5E445A.7000201@redhat.com> <4F5EEBC4.7030704@redhat.com> In-Reply-To: <4F5EEBC4.7030704@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: Anthony Liguori , Hans de Goede , Alon Levy , qemu-devel , "spice-devel@freedesktop.org" Hi, On 03/13/2012 08:40 AM, Gerd Hoffmann wrote: > On 03/12/12 19:45, Yonit Halperin wrote: >> Hi, >> On 03/12/2012 03:50 PM, Gerd Hoffmann wrote: >>> Hi, >>> >>>> Can you explain/exemplify, why sending data as a blob (either by (a) or >>>> (b)), that is verified only by the two ends that actually use it, is a >>>> problem? >>> >>> It tends to be not very robust. Especially when the creating/parsing is >>> done ad-hoc and the format changes now and then due to more info needing >>> to be stored later on. The qemu migration format which has almost no >>> structure breaks now and then because of that. Thus I'd prefer to not >>> go down this route when creating something new. >>> >>> cheers, >>> Gerd >> >> Exposing spice server internals to the client/qemu seems to me more >> vulnerable then sending it as a blob. > > That also depends on what and how much we need to transfer. > >> Nonetheless, it introduces more >> complexity to backward compatibility support and it will need to involve >> not only the capabilities/versions of the server but also those of the >> qemu/client > > Backward compatibility isn't that easy both ways. > 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. >> .Which reminds me, that we also need capabilities >> negotiation for the migration protocol between the src and the destination. > > 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. Regards, Yonit. > cheers, > Gerd