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 d
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
pro
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 ver
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
On Mon, Mar 12, 2012 at 04:24:16PM +0200, Alon Levy wrote:
> On Mon, Mar 12, 2012 at 01:44:47PM +0100, Gerd Hoffmann wrote:
> > On 03/12/12 12:45, Alon Levy wrote:
> > > On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
> > >> On 03/12/12 12:29, Alon Levy wrote:
> > >>>
> > >>> Actuall
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
On Mon, Mar 12, 2012 at 01:44:47PM +0100, Gerd Hoffmann wrote:
> On 03/12/12 12:45, Alon Levy wrote:
> > On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
> >> On 03/12/12 12:29, Alon Levy wrote:
> >>>
> >>> Actually the agent protocol does extend nicely to multiple clients - I
> >>> f
On 03/12/12 12:45, Alon Levy wrote:
> On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
>> On 03/12/12 12:29, Alon Levy wrote:
>>>
>>> Actually the agent protocol does extend nicely to multiple clients - I
>>> forgot the name but there is an additional wrapper between the
>>> client/se
On 03/12/2012 11: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
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<
On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
> On 03/12/12 12:29, Alon Levy wrote:
> > On Mon, Mar 12, 2012 at 11:26:50AM +0100, Gerd Hoffmann wrote:
> >> Hi,
> >>
> >>> Migrate this struct n times for me.
> >>
> >> I think for the agent case this isn't needed. Or is every clie
Hi,
>> 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.
That doesn't help much as it is _way_ too old. P
On 03/12/12 12:29, Alon Levy wrote:
> On Mon, Mar 12, 2012 at 11:26:50AM +0100, Gerd Hoffmann wrote:
>> Hi,
>>
>>> Migrate this struct n times for me.
>>
>> I think for the agent case this isn't needed. Or is every client
>> allowed to speak to the agent in case of multiple clients connected? I
On Mon, Mar 12, 2012 at 11:26:50AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> >>> 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,
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 i
Hi,
>>> 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 o
On Mon, Mar 12, 2012 at 10:46:44AM +0100, 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
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-implement
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 the
Hi,
On 03/11/2012 02:16 PM, Yonit Halperin wrote:
Hi,
We would like to implement seamless migration for Spice, i.e., keeping the
currently opened spice client session valid after migration.
Today, the spice client establishes the connection to the destination before
migration starts, and when
20 matches
Mail list logo
