Hi,
On 03/20/2012 03:58 PM, Gerd Hoffmann wrote:
Hi,
We can either store and migrate the cache, or choose to reset it.
In the extinct spice seamless migration solution, the cache was reset.
Hmm, this makes me wonder what the main advantage of seamless migration
used to be? image cache was
Hi,
> We can either store and migrate the cache, or choose to reset it.
> In the extinct spice seamless migration solution, the cache was reset.
Hmm, this makes me wonder what the main advantage of seamless migration
used to be? image cache was reset, surfaces didn't exist back then. So
any i
Hi,
On 03/15/2012 04:23 PM, Hans de Goede wrote:
Hi,
On 03/15/2012 03:07 PM, Yonit Halperin wrote:
Hi,
On 03/15/2012 02:36 PM, Hans de Goede wrote:
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
Hi,
It is not easy when you have 2 components,
Hi,
On 03/15/2012 04:07 PM, Yonit Halperin wrote:
Hi,
On 03/15/2012 02:36 PM, Hans de Goede wrote:
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
Hi,
It is not easy when you have 2 components, and it is much less easy
when
you have 3 or 4 comp
Hi,
On 03/15/2012 04:23 PM, Hans de Goede wrote:
Hi,
On 03/15/2012 03:07 PM, Yonit Halperin wrote:
Hi,
On 03/15/2012 02:36 PM, Hans de Goede wrote:
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
Hi,
It is not easy when you have 2 components,
On 03/15/12 13:36, Hans de Goede wrote:
> Hi,
>
> On 03/15/2012 01:11 PM, Yonit Halperin wrote:
>> On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
>>> 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 compli
On Thu, Mar 15, 2012 at 03:34:19PM +0100, Hans de Goede wrote:
> Hi,
>
> On 03/15/2012 03:22 PM, Alon Levy wrote:
> >On Thu, Mar 15, 2012 at 01:36:23PM +0100, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 03/15/2012 01:11 PM, Yonit Halperin wrote:
> >>>On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
> >>>
Hi,
On 03/15/2012 03:22 PM, Alon Levy wrote:
On Thu, Mar 15, 2012 at 01:36:23PM +0100, Hans de Goede wrote:
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
Hi,
It is not easy when you have 2 components, and it is much less easy when
you have 3
On Thu, Mar 15, 2012 at 01:36:23PM +0100, Hans de Goede wrote:
> Hi,
>
> On 03/15/2012 01:11 PM, Yonit Halperin wrote:
> >On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
> >>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
Hi,
On 03/15/2012 03:07 PM, Yonit Halperin wrote:
Hi,
On 03/15/2012 02:36 PM, Hans de Goede wrote:
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
Hi,
It is not easy when you have 2 components, and it is much less easy
when
you have 3 or 4 com
Hi,
On 03/15/2012 02:36 PM, Hans de Goede wrote:
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
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
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
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
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
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/ve
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
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
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 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
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 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
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 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,
>> 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. Draw
Hi.
On 03/11/2012 05:36 PM, Anthony Liguori wrote:
On 03/11/2012 10:25 AM, Alon Levy wrote:
On Sun, Mar 11, 2012 at 09:18:17AM -0500, Anthony Liguori wrote:
On 03/11/2012 08:16 AM, Yonit Halperin wrote:
Hi,
We would like to implement seamless migration for Spice, i.e.,
keeping the
currently o
On 03/11/2012 10:25 AM, Alon Levy wrote:
On Sun, Mar 11, 2012 at 09:18:17AM -0500, Anthony Liguori wrote:
On 03/11/2012 08:16 AM, 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.
To
On Sun, Mar 11, 2012 at 09:18:17AM -0500, Anthony Liguori wrote:
> On 03/11/2012 08:16 AM, 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 establ
36 matches
Mail list logo
