Hans,
There is no output. It simply just exits.
Is there any way to get the log of Qemu? I tried to find the log in
/var/log/libvirt/qemu but found nothing there.
-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com]
Sent: Friday, May 18, 2012 2:39 PM
To: Charles.Tsai-蔡清海-
Hi,
On 05/17/2012 11:42 PM, Marc-André Lureau wrote:
The remote may want to use that same key sequence,
so we better send it through, even if it matches
the ungrab key combination.
I'm not sure about this, if the grab-sequence is
getting in the way, maybe we need a different
grab-sequence?
Wh
Hi,
On 05/18/2012 02:57 AM, Charles.Tsai-蔡清海-研究發展部 wrote:
Hi Hans,
Thank you for your suggestion. I tried your Qemu code. But I found my
qemu script which is only coded with simple qemu command options.
Before using your Qemu code, my VM could be launched by running the
foll
Hi Vadim,
It's great!
I have tried and it work fine now. Thank you for your work.
2012/5/18 Vadim Rozenfeld
> Hi wangfeng,
>
> could you please try reproducing the issue with the most recent vioserial
> driver, available at
> http://people.redhat.com/vrozenfe/build-27/virtio-win-prewhql-0.1.zip
Hi Hans,
Thank you for your suggestion. I tried your Qemu code. But I found my
qemu script which is only coded with simple qemu command options.
Before using your Qemu code, my VM could be launched by running the
following script without any problem. But it failed to launch the
The remote may want to use that same key sequence,
so we better send it through, even if it matches
the ungrab key combination.
---
gtk/spice-widget.c |2 --
1 file changed, 2 deletions(-)
diff --git a/gtk/spice-widget.c b/gtk/spice-widget.c
index e6c252d..fad9db5 100644
--- a/gtk/spice-widge
Hi wangfeng,
could you please try reproducing the issue with the most recent vioserial
driver, available at
http://people.redhat.com/vrozenfe/build-27/virtio-win-prewhql-0.1.zip ?
Thank you,
Vadim.
On Wednesday, May 09, 2012 10:19:26 AM wangfeng wangfeng wrote:
> Thank you very much
>
> 2012/
Fix a crash caused by a call to __red_is_next_stream_frame made by
red_stream_maintenance, with a drawable that is not a DRAW_COPY one.
Only DRAW_COPY drawables can be streamed, and __red_is_next_stream_frame
refers to red_drawable->u.copy.src_bitmap.
---
server/red_worker.c |4
1 files c
The change abc56811de978ad336a651924a21b920cfe677f0 actually added
a field in a public struct while changing overall struct size, the
fields were also reorder, all of this breaks ABI.
However, we are running out of free space in SpiceChannelClass
struct. And since the SPICE_RESERVED_PADDING was 44
On Thu, May 17, 2012 at 11:20 AM, Yonit Halperin wrote:
> + void (*channel_reset_capabilities)(SpiceChannel *channel);
oops.. I forgot we ran out of space in SpiceChannelClass.. This patch
should have updated _spice_reserved field.
It's not a big deal to increase the struct size, unless peopl
On Thu, May 17, 2012 at 2:25 PM, Yonit Halperin wrote:
> +static void spice_channel_reset_capabilities(SpiceChannel *channel)
> +{
> +
there is an extra line here
> + SpiceChannelPrivate *c = SPICE_CHANNEL_GET_PRIVATE(channel);
> + g_array_set_size(c->caps, 0);
> +
> + if (SPICE_CHANNEL
If no cert-subject or pubkey is provided, we should unset the corresponding
flags.
---
gtk/spice-session.c |8 ++--
spice-common|2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/gtk/spice-session.c b/gtk/spice-session.c
index b3c66ce..17b1fe8 100644
--- a/g
Even if they are not public functions, those conditions can be reached
in a invalid state.
---
common/ssl_verify.c |5 +
1 file changed, 5 insertions(+)
diff --git a/common/ssl_verify.c b/common/ssl_verify.c
index 2f34c00..3667b2e 100644
--- a/common/ssl_verify.c
+++ b/common/ssl_verify.c
---
gtk/channel-record.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-record.c b/gtk/channel-record.c
index d93d908..0ae9e4c 100644
--- a/gtk/channel-record.c
+++ b/gtk/channel-record.c
@@ -89,15 +89,20 @@ static void channel_up(SpiceChannel *chan
---
gtk/channel-playback.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-playback.c b/gtk/channel-playback.c
index 37b260e..1485267 100644
--- a/gtk/channel-playback.c
+++ b/gtk/channel-playback.c
@@ -83,15 +83,20 @@ static void spice_playback_hand
---
gtk/channel-display.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index 578cb03..801d867 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@ -103,6 +103,7 @@ static void clear_streams(SpiceChannel
---
gtk/channel-main.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index 6d5281e..fc6c97e 100644
--- a/gtk/channel-main.c
+++ b/gtk/channel-main.c
@@ -154,6 +154,12 @@ static const char *agent_caps[] = {
/* --
Related: rhbz#821795
The capabilities have been zeroed after channel reset, which have lead to
publish the wrong caps when both port and tls-port are given, and the
channels are secured (first attempt to connect the channel with "port"
has failed; the channel got reset, and then reconnected with "
v2:
move SPICE_CHANNEL_GET_CLASS(channel)->channel_reset_capabilities from
chane_reset to spice_channel_reset_capabilities
Yonit Halperin (5):
Fix not setting channel specific capabilities upon channel reset
main channel: reseting channel caps
display channel: reseting channel caps
playb
On 05/17/2012 02:11 PM, Marc-André Lureau wrote:
On Thu, May 17, 2012 at 11:20 AM, Yonit Halperin wrote:
+static void spice_main_channel_reset_capabilties(SpiceChannel *channel)
+{
+spice_channel_set_capability(SPICE_CHANNEL(channel),
SPICE_MAIN_CAP_SEMI_SEAMLESS_MIGRATE);
+spice_chann
On Thu, May 17, 2012 at 11:20 AM, Yonit Halperin wrote:
> +static void spice_main_channel_reset_capabilties(SpiceChannel *channel)
> +{
> + spice_channel_set_capability(SPICE_CHANNEL(channel),
> SPICE_MAIN_CAP_SEMI_SEAMLESS_MIGRATE);
> + spice_channel_set_capability(SPICE_CHANNEL(channel),
---
gtk/channel-record.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-record.c b/gtk/channel-record.c
index d93d908..0ae9e4c 100644
--- a/gtk/channel-record.c
+++ b/gtk/channel-record.c
@@ -89,15 +89,20 @@ static void channel_up(SpiceChannel *chan
---
gtk/channel-playback.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-playback.c b/gtk/channel-playback.c
index 37b260e..1485267 100644
--- a/gtk/channel-playback.c
+++ b/gtk/channel-playback.c
@@ -83,15 +83,20 @@ static void spice_playback_hand
---
gtk/channel-display.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index 578cb03..801d867 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@ -103,6 +103,7 @@ static void clear_streams(SpiceChannel
---
gtk/channel-main.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index 6d5281e..fc6c97e 100644
--- a/gtk/channel-main.c
+++ b/gtk/channel-main.c
@@ -154,6 +154,12 @@ static const char *agent_caps[] = {
/* --
Related: rhbz#821795
The capabilities have been zeroed after channel reset, which have lead to
publish the wrong caps when both port and tls-port are given, and the
channels are secured (first attempt to connect the channel with "port"
has failed; the channel got reset, and then reconnected with "
Hi Alon,
We created a qcow2 based-image for a VM whose size is bigger when it is
created. When a VM is launched, it is a instance VM image which refers
to the based-image. Initially, the image size of instance VM is smaller than
that of the based-mage. But we found the image siz
27 matches
Mail list logo
