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
How about this bug pls.
Is the topic 'seamless migration with spice' by Yonit
may fix it?
Thanks,
On Thu, Mar 8, 2012 at 6:19 PM, Zhou Peng wrote:
> = How to reproduce =
> $ virsh create win7template.xml
> $ virsh save win7template win7template.ckp
> $ virsh restore win7template.ckp
>
> = Phenom
On Mon, Mar 12, 2012 at 04:41:33PM -0400, nshal...@elys.com wrote:
> From: Nahum Shalman
ACK.
>
> no need to duplicate the check that the fd isn't -1
> ---
> server/reds.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/server/reds.c b/server/reds.c
> index dc0
From: Nahum Shalman
no need to duplicate the check that the fd isn't -1
---
server/reds.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index dc009f4..c54d30c 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -2999,9 +2999,6 @@ static in
Before I get too far into changing lots of code I wanted to ask the
following questions:
spice/server]$ git grep "setsockopt(" | wc -l
10
There are 10 calls to setsockopt in the server code base.
All of them allow ENOTSUP, and won't even complain if they get that
error code.
Only the two that
Hi,
On 03/12/2012 05:36 PM, Marc-André Lureau wrote:
Hi
On Mon, Mar 12, 2012 at 4:48 PM, Hans de Goede wrote:
Hi All,
$subject says it all, if you have any such patches please rebase them
on top of:
http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.0-usbredir
Then *test* them a
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
Hi all,
Recently I've performed an atempt to setup and run Xspice.
I have tried on F17 and Ubuntu12.04.
On Fedora I used prebult binary. It runs but client connects and
disconnects immidiatly and silently.
On Ubuntu I've built from latest qxl release and Xorg segfaults silently
during the init.
Hi spice devs.
I was wondering if is possible for the current usb redirection code to
present in a permanente way several USB devices.
The client PC should have the USB devices connected from booting up because
it would be extremely cumbersome to the end-user to plug the devices once
the spice wi
Hi
On Mon, Mar 12, 2012 at 4:48 PM, Hans de Goede wrote:
> Hi All,
>
> $subject says it all, if you have any such patches please rebase them
> on top of:
> http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.0-usbredir
>
> Then *test* them and send them to me, then I'll take care of ge
Hi,
On 03/12/2012 04:55 PM, Alon Levy wrote:
On Mon, Mar 12, 2012 at 04:48:19PM +0100, Hans de Goede wrote:
Hi All,
$subject says it all, if you have any such patches please rebase them
on top of:
http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.0-usbredir
Then *test* them and s
On Mon, Mar 12, 2012 at 04:48:19PM +0100, Hans de Goede wrote:
> Hi All,
>
> $subject says it all, if you have any such patches please rebase them
> on top of:
> http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.0-usbredir
>
> Then *test* them and send them to me, then I'll take care
Hi All,
$subject says it all, if you have any such patches please rebase them
on top of:
http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.0-usbredir
Then *test* them and send them to me, then I'll take care of getting
them into F-17.
Regards,
Hans
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 Fri, Mar 09, 2012 at 12:26:49PM -0500, Nahum Shalman wrote:
Nahum,
Hans pushed the series, so you should rebase the cleanup series on top of
it, sorry.
Alon
> With thanks to Daniel Berrange for his guidance, this is a redo of my
> previous pair of patches.
>
> Listening on a unix socket w
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
Hi,
On 03/10/2012 12:01 PM, Alon Levy wrote:
On Sat, Mar 10, 2012 at 08:56:55AM +0100, Hans de Goede wrote:
Hi,
Thanks for the patches!
Series looks good, ack! I would like one other spice developer more
familiar with the server to look at it and ack it too and then
I (or that other developer
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
Alon,
Thanks. Your additional information will help me a lot when I debug the code.
I don't expect my code to work without tracing and debugging the code.
-Original Message-
From: Alon Levy [mailto:al...@redhat.com]
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: sp
On Mon, Mar 12, 2012 at 05:51:32PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Alon,
>
> Here is a little bit confusion to me and you might be able to clear my
> puzzle.
>
> If launching a VM by adding the following options can create a separate
> VirIO for virtual printer driver, how th
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
Alon,
Here is a little bit confusion to me and you might be able to clear my
puzzle.
If launching a VM by adding the following options can create a separate
VirIO for virtual printer driver, how the Qemu maps this logical channel to
printing channel?
In other words, Win
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
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
-Original Message-
From: Alon Levy [mailto:al...@redhat.com]
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-devel@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS
On Mon, Mar 12, 2012 at 10:16:37AM +0800, Charles.Tsai-蔡
On Mon, Mar 12, 2012 at 10:16:37AM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Alon,
>
> Thank you for your prompt response. Please see my comments below inside the
> pair tag "Charles <<
>
> -Original Message-
> From: Alon Levy [mailto:al...@redhat.com]
> Sent: Saturday, March 10, 201
38 matches
Mail list logo
