[Spice-devel] Adaptive compression choice? [was: Re: [PATCH spice 1/3] dcc_compress_image: Handle NULL drawable]

[David Jaša]

Hi Frediano,

On Čt, 2016-01-14 at 12:52 -0500, Frediano Ziglio wrote:

> > 
> > On Thu, 2016-01-14 at 12:07 -0500, Frediano Ziglio wrote:
> > > > 
> > > > On Thu, Jan 14, 2016 at 10:27:02AM -0500, Frediano Ziglio wrote:
> > > > > Had a small discussion with Pavel.
> > > > > We agree that original code is quite complicated and is hard to
> > > > > understand
> > > > > the final compression format used.
> > > > > 
> > > > > So we would like to have some public discussion about the topic.
> > > > > 
> > > > > I personally agree we should have a single code deciding the
> > > > > compression
> > > > > to use.
> > > > 
> > > > I definitely agree here. For one, having different compression being
> > > > used depending on whether the qxl driver is used or not is unexpected
> > > > (eg if you set image compression to glz, lz will still be used during
> > > > initial bootup, and then will 'switch' to glz later on. I haven't looked
> > > > at the code, so there might be good reasons for that).
> > > > 
> > > > > 
> > > > > This is the list of actual compressions:
> > > > > - AUTO_GLZ;
> > > > > - AUTO_LZ;
> > > > > - QUIC;
> > > > > - GLZ;
> > > > > - LZ;
> > > > > - LZ4.
> > > > > A client can also decide to disable compression.
> > > > > 
> > > > > The AUTO_XXX looks like they should use QUIC as a fallback if XXX is
> > > > > not
> > > > > possible or if an image with high graduality is detected.
> > > > 
> > > > (side question, do we have numbers on compression ratio and cpu usage
> > > > for quic/lz/glz/lz4?)
> > > > 
> > > 
> > > Brief and raw of a Windows replay capture
> > > 
> > > Images  MB before   MB after  Ratio CPU time
> > > LZ4 193 24.21   2.43  10.04%0.04
> > > QUIC204 23.11   1.66   7.18%0.44
> > > GLZ 190 20.05   1.25.99%0.14
> > > LZ  202 20.42   2.04   9.99%0.15
> > > 
> > > So why use Quic ?
> > 
> > Interesting data. Indeed, QUIC seems to be the worst choice. from this data,
> > it
> > seems that you'd want GLZ if you were optimizing for network bandwidth, and
> > LZ4
> > if you're optimizing for CPU usage. Might be nice to see data for a slightly
> > larger sample as well.
> > 
> > Out of curiosity, did you write a little utility for doing this benchmark, 
> > or
> > did you just modify the code in-place?? Having a little benchmark utility
> > that
> > you could run on different replay captures might be a useful thing to have 
> > in
> > the repository...
> > 
> > Jonathon
> > 
> > 
> 
> No code modification at all. Compile with COMPRESS_STAT enabled, run replay
> utility with SPICE_DEBUG_LEVEL=3 set at the end you see a similar table
> (I added just ratio with LibreOffice calc).
> Oh... you just need to use -C replay option with
> - 4 quic
> - 5 glz
> - 6 lz
> - 7 lz4
> (not sure about 5/6, maybe swapped).


would you mind running with no compression so that we can get CPU
baseline? FWIW I've put inverted numbers to a chart (1/cpu time,
orig_size/compressed_size, so that greater number is better) and the
result is here:

You can imagine the numbers as a number of VMs you can squeeze into a
single host given a cpu/network constraint.

I was wondering, if the current code is indeed messy if it couldn't be
replaced with an adaptive algorithm e.g. starting with some "middle
ground" algorithm (LZ4 looks like the candidate) and move up if server
detects packet loss or move right if server can't compress images fast
enough...


> I think would be really helpful to collect different replay captures of
> normal day job.


IIRC VDI benchmark could be the tool to get such a capture.

David


> Frediano
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice udp support

[David Jaša]

On Út, 2016-02-02 at 10:24 +0100, Christophe Fergeau wrote:
> Hey,
> 
> On Tue, Feb 02, 2016 at 06:10:28PM +0900, Sunny Shin wrote:
> > I have a few questions about udp version of spice protocol.
> > 
> > Is there a plan to support udp in spice protocol?
> > 
> > If we support udp, what do we need to implement?
> > Is it enough to change tcp channels to udp ones?
> 
> Maybe that would be enough, maybe more changes would be needed, I cannot
> exactly tell you. My main worries with UDP would be packet drops as
> there is nothing guaranteeing you that the packets you send will arrive
> at all to the other end of the connexion.
> 
> > Would there be any benefits over tcp version? possibly better performance?
> 
> There would most likely be less overhead, but at the cost of not having
> guarantees of packet delivery, so I'm not sure how good this tradeoff
> would be..
> Experimenting with this sounds interesting though!

Yonit did some experiments with video streaming over UDP and there was
no performance gain IIRC.

David

> Christophe
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] connection lost after 1 Hour

[David Jaša]

Hi Nikhil,

your issue seems to be network inactivity. This will be resolved in the
next release of spice-server by use of tcp_keepalive but for the time
being, the only cure is to use the VM from time to time so that the TCP
connections don't get closed (NAT records don't expire, ...)

David

On Po, 2016-02-22 at 09:24 +, Nikhil Korde wrote:
> Hi Team,
> 
> 
> I like to use spice client. At this time we are testing Spice client
> from remote window7 to Proxmox Guest.
> 
> 
> I can able to connect using spice client to guest os window7 and
>  ubunut. 
> 
> 
> Now,  I am facing issue , after  1 hour suddenly connection has lost
> and showing that Connected to graphics.
> 
> 
> 
> 
> Please help to resolve this issue.
> 
> 
> 
> 
> Thanks,
> Nikhil 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk v3 18/19] log: create subdomains for spice-gtk

[David Jaša]

Will it be possible to print all existing subdomains? Or would it be
hard to add?

On So, 2016-03-12 at 15:32 +0100, Victor Toso wrote:
> "audio"  : spice-audio.c spice-gstaudio.c spice-pulse.c
> "base"   : channel-base.c
> "channel": spice-channel.c
> "coroutine"  : coroutine_gthread.c coroutine_ucontext.c
>coroutine_winfibers.c
> "cursor" : channel-cursor.c
> "decode" : decode-glz.c decode-jpeg.c decode-zlib.c
> "display": channel-display.c channel-display-mjpeg.c
> "egl": spice-widget-egl.c
> "giopipe": giopipe.c
> "gtk-session": spice-gtk-session.c
> "input"  : channel-inputs.c
> "log": bio-gio.c continuation.c desktop-integration.c
>spice-option.c spice-grabsequence.c spice-uri.c
>spice-util.c
> "main"   : channel-main.c
> "playback"   : channel-playback.c
> "port"   : channel-port.c
> "record" : channel-record.c
> "session": spice-session.c
> "smartcard"  : channel-smartcard.c smartcard-manager.c
> "usbredir"   : channel-usbredir.c
> "usb": usb-device-manager.c usb-device-widget.c usbutil.c
>win-usb-dev.c win-usb-driver-install.c
> "vmcstream"  : vmcstream.c
> "vnc-keymap" : vncdisplaykeymap.c
> "webdav" : channel-webdav.c
> "widget" : spice-widget.c
> ---
>  src/Makefile.am| 3 +++
>  src/bio-gio.c  | 2 ++
>  src/channel-base.c | 2 ++
>  src/channel-cursor.c   | 2 ++
>  src/channel-display-mjpeg.c| 2 ++
>  src/channel-display.c  | 2 ++
>  src/channel-inputs.c   | 2 ++
>  src/channel-main.c | 2 ++
>  src/channel-playback.c | 2 ++
>  src/channel-port.c | 2 ++
>  src/channel-record.c   | 2 ++
>  src/channel-smartcard.c| 2 ++
>  src/channel-usbredir.c | 2 ++
>  src/channel-webdav.c   | 2 ++
>  src/coroutine_gthread.c| 2 ++
>  src/coroutine_ucontext.c   | 3 +++
>  src/coroutine_winfibers.c  | 3 +++
>  src/decode-glz.c   | 2 ++
>  src/decode-jpeg.c  | 2 ++
>  src/decode-zlib.c  | 2 ++
>  src/desktop-integration.c  | 2 ++
>  src/giopipe.c  | 3 +++
>  src/map-file   | 1 +
>  src/smartcard-manager.c| 2 ++
>  src/spice-audio.c  | 2 ++
>  src/spice-channel.c| 2 ++
>  src/spice-client-glib-usb-acl-helper.c | 3 +++
>  src/spice-common.h | 1 -
>  src/spice-grabsequence.c   | 1 +
>  src/spice-gstaudio.c   | 2 ++
>  src/spice-gtk-session.c| 2 ++
>  src/spice-option.c | 2 ++
>  src/spice-pulse.c  | 2 ++
>  src/spice-session.c| 2 ++
>  src/spice-uri.c| 2 ++
>  src/spice-util.c   | 2 ++
>  src/spice-util.h   | 1 -
>  src/spice-widget-egl.c | 2 ++
>  src/spice-widget.c | 2 ++
>  src/usb-device-manager.c   | 2 ++
>  src/usb-device-widget.c| 3 +++
>  src/usbutil.c  | 2 ++
>  src/vmcstream.c| 2 ++
>  src/vncdisplaykeymap.c | 2 ++
>  src/win-usb-dev.c  | 2 ++
>  src/win-usb-driver-install.c   | 2 ++
>  46 files changed, 92 insertions(+), 2 deletions(-)
> 
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 68884e6..81eed02 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -420,6 +420,8 @@ spice_client_glib_usb_acl_helper_SOURCES =\
>   $(NULL)
>  
>  spice_client_glib_usb_acl_helper_LDADD = \
> + $(top_builddir)/spice-common/common/libspice-common.la  \
> + $(top_builddir)/spice-common/common/libspice-common-client.la   \
>   $(GLIB2_LIBS)   \
>   $(GIO_LIBS) \
>   $(POLKIT_LIBS)  \
> @@ -428,6 +430,7 @@ spice_client_glib_usb_acl_helper_LDADD =  \
>   $(NULL)
>  
>  spice_client_glib_usb_acl_helper_CPPFLAGS =  \
> + $(SPICE_COMMON_CPPFLAGS)\
>   $(SPICE_CFLAGS) \
>   $(GLIB2_CFLAGS) \
>   $(GIO_CFLAGS)   \
> diff --git a/src/bio-gio.c b/src/bio-gio.c
> index 04d6613..c8d2a89 100644
> --- a/src/bio-gio.c
> +++ b/src/bio-gio.c
> @@ -16,6 +16,8 @@
> License along with this library; if not, see 
> .
>  */
>  #include "config.h"
> +#include "common/log.h"
> +SPICE_LOG_DOMAIN_STATIC("log");
>  
>  #include 
>  #include 
> diff --git a/src/channel-base.c b/src/channel-base.c
> index 93609d4..67dc311 100644
> --- a/src/channel

Re: [Spice-devel] [spice-common v3] use specific subdomains for better filtering

[David Jaša]

Hi, I like the approach a lot. It seems quite clear and nice to me,
but ...

On So, 2016-03-12 at 15:32 +0100, Victor Toso wrote:
> Hi! I've rebased this series and pushed to my remote branch in
> freedesktop [0] [1]. I'll try to clarify the ideia for working on this
> and if it does not get any positive feedback I'll take it as something
> not interesting to have...
> 
> [0] (common) https://cgit.freedesktop.org/~victortoso/spice-common/log/?h=logs
> [1] (gtk) https://cgit.freedesktop.org/~victortoso/spice-gtk/log/?h=logs
> fdo: https://bugs.freedesktop.org/show_bug.cgi?id=91838
> 
> So, first of all, I don't want to introduce something that everybody
> need to understand in order to get proper debug. The main idea is able
> to filter in/out stuff that you don't want to see without the need to
> | grep -v and | grep -i it.
> 
> With that said, SPICE_DEBUG=6 should work to get G_LOG_LEVEL_DEBUG of
> all code that uses spice logging functions.

... this essentially breaks compatibility in a bad way. IMO it has
already "sunk in" that G_MESSAGES_DEBUG=(GSpice|all) SPICE_DEBUG=1 means
all debug output from spice_gtk. Having just a trickle instead of
expected flood would be surprising.

I suggest adding a brief message when SPICE_DEBUG is set outlining the
new usage so that you don't have to bother with backwards compatibility
and users are warned.

The same would be suitable eventually for spice server when it's
SPICE_DEBUG_LEVEL-controlled debugging is replaced with a new one.

> With all debug enable you would see all lines prefixed with
> "[subdomain-name]" so, in case you don't want to see it (filter out),
> you could:
> 
> $SPICE_DEBUG=6,subdomain-name:- remote-viwer ...
> 
> And voilà, nothing from it will be showed as '-' is the same as '0'
> which is *no debug*. The opposite of it would be '*' or '6'.
> * Both '-' and 0 would work and "none" as well;
> * Both '*' and 6 would work and "debug" as well;
> 

+1 to Marc-André's suggestion to remove multiple choices.

> In case you only want to see some debug info, you could do something
> like:
> 
> SPICE_DEBUG=audio:*,playback:*
>
> This would show spice-audio, spice-gstaduio, spice-pulse,
> channel-playback debugs and nothing else.

I don't like asterisks because they need to be escaped in shell. For
subdomains, "all" would be IMO better and for log levels, highest
verbosity level should be sufficient. The highest level could be printed
in the logging overview message (and either taken out of the actual
code, or standardized in coding style to avoid surprises).

HTH,

David

> 
> Q: Do you want this just to avoid grep?
> A: No! We should not avoid inserting debug into the code because it
> could get verbose, we should smart handling it with something like this
> IMHO. We have a few #ifdef #DEBUG_THIS which is not useful when asking
> debug info to reporter in open bugs.
> 
> I really think that this could be improved a lot yet but it would need a
> proper discussion. If this does not seem useful, then it's fine :)
> 
> Another misc info:
> * I did not try this with spice server yet;
> * We can use spice logging tools or glib ones, I choosed spice first as
>   I think we can have better control with it;
> * I did not try to fix the spice-common tests yet;
> 
> changes from v2:
> * rebased to latest version upstream
> * Kept usage of SPICE_LOG_DOMAIN instead of G_LOG_DOMAIN that I
>   previously proposed
> * moved some changes that should be in another commit
> * changed the static variable from SPICE_LOG_DOMAIN to
>   SPICE_LOG_SUB_DOMAIN
> 
> changes from v1:
> * Use one-static-per-file approach to define each subdomain. This is
>   similar to how libvirt does and seems much cleaner.
> * Removed f(printf) debugs
> * Created subdomains for spice-common as well as now this is a must.
> 
> [spice-common]
> Victor Toso (6):
>   log: simplify log defines with SPICE_LOG
>   log: include message log level for parity with glib
>   log: allow filtering logs with subdomains
>   log: create specific subdomains for filtering
>   log: Disable multiple domains in Spice
>   don't break the build with this wip patches
> 
>  common/canvas_base.c  |   3 +-
>  common/canvas_utils.c |   1 +
>  common/log.c  | 174 
> ++
>  common/log.h  |  87 -
>  common/lz.c   |   2 +
>  common/marshaller.c   |   1 +
>  common/mem.c  |   1 +
>  common/pixman_utils.c |   1 +
>  common/quic.c |   4 +-
>  common/region.c   |   2 +
>  common/rop3.c |   4 +-
>  common/ssl_verify.c   |   3 +-
>  tests/test-logging.c  |   3 +-
>  13 files changed, 238 insertions(+), 48 deletions(-)
> 
> [spice-gtk]
> Victor Toso (13):
>   log: use glib logging on testing tools
>   log: use spice_debug instead of SPICE_DEBUG
>   log: nitpick at channel name in CHANNEL_DEBUG
>   log: remove unused SPICE_DEBUG
>   log: use spice_debug instead of g_debug
>   log: use spice_warning instead of g_war

Re: [Spice-devel] [PATCH] fix 16 bpp LZ image decompression

[David Jaša]

On Čt, 2016-04-14 at 17:56 +0100, Frediano Ziglio wrote:
> LZ image decompression was broken for 16 bpp:
> - stride was computed not computed correctly (as width*4). This caused

IMO one extra 'computed' here.

>   also a buffer underflow;
> - stride in pixman is always multiple of 4 bytes (so for 16 bpp is
>   ALIGN(width*2, 4)) so image decompressed by lz_decode as some missing
>   bytes to be fixed.
> 
> The alignment code is reused from LZ4 function.
> 
> This fix also https://bugzilla.redhat.com/show_bug.cgi?id=1285469.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  common/canvas_base.c | 54 
> +++-
>  1 file changed, 32 insertions(+), 22 deletions(-)
> 
> diff --git a/common/canvas_base.c b/common/canvas_base.c
> index fa4d373..45dd75f 100644
> --- a/common/canvas_base.c
> +++ b/common/canvas_base.c
> @@ -515,13 +515,30 @@ static pixman_image_t *canvas_get_jpeg(CanvasBase 
> *canvas, SpiceImage *image)
>  return surface;
>  }
>  
> +static void canvas_fix_alignment(uint8_t *bits,
> + int stride_encoded, int stride_pixman,
> + int height)
> +{
> +if (stride_pixman > stride_encoded) {
> +// Fix the row alignment
> +int row;
> +uint8_t *dest = bits;
> +for (row = height - 1; row > 0; --row) {
> +uint32_t *dest_aligned, *dest_misaligned;
> +dest_aligned = (uint32_t *)(dest + stride_pixman*row);
> +dest_misaligned = (uint32_t*)(dest + stride_encoded*row);
> +memmove(dest_aligned, dest_misaligned, stride_encoded);
> +}
> +}
> +}
> +
>  #ifdef USE_LZ4
>  static pixman_image_t *canvas_get_lz4(CanvasBase *canvas, SpiceImage *image)
>  {
>  pixman_image_t *surface = NULL;
>  int dec_size, enc_size, available;
>  int stride, stride_abs, stride_encoded;
> -uint8_t *dest, *data, *data_end;
> +uint8_t *dest, *data, *data_end, *bits;
>  int width, height, top_down;
>  LZ4_streamDecode_t *stream;
>  uint8_t spice_format;
> @@ -576,6 +593,7 @@ static pixman_image_t *canvas_get_lz4(CanvasBase *canvas, 
> SpiceImage *image)
>  if (!top_down) {
>  dest -= (stride_abs * (height - 1));
>  }
> +bits = dest;
>  
>  do {
>  // Read next compressed block
> @@ -594,20 +612,7 @@ static pixman_image_t *canvas_get_lz4(CanvasBase 
> *canvas, SpiceImage *image)
>  data += enc_size;
>  } while (data < data_end);
>  
> -if (stride_abs > stride_encoded) {
> -// Fix the row alignment
> -int row;
> -dest = (uint8_t *)pixman_image_get_data(surface);
> -if (!top_down) {
> -dest -= (stride_abs * (height - 1));
> -}
> -for (row = height - 1; row > 0; --row) {
> -uint32_t *dest_aligned, *dest_misaligned;
> -dest_aligned = (uint32_t *)(dest + stride_abs*row);
> -dest_misaligned = (uint32_t*)(dest + stride_encoded*row);
> -memmove(dest_aligned, dest_misaligned, stride_encoded);
> -}
> -}
> +canvas_fix_alignment(bits, stride_encoded, stride_abs, height);
>  
>  LZ4_freeStreamDecode(stream);
>  return surface;
> @@ -782,7 +787,6 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>  uint8_t *comp_buf = NULL;
>  int comp_size;
>  uint8_t*decomp_buf = NULL;
> -uint8_t*src;
>  pixman_format_code_t pixman_format;
>  LzImageType type, as_type;
>  SpicePalette *palette;
> @@ -790,6 +794,7 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>  int width;
>  int height;
>  int top_down;
> +int stride_encoded;
>  int stride;
>  int free_palette;
>  
> @@ -818,10 +823,12 @@ static pixman_image_t *canvas_get_lz(CanvasBase 
> *canvas, SpiceImage *image,
>  lz_decode_begin(lz_data->lz, comp_buf, comp_size, &type,
>  &width, &height, &n_comp_pixels, &top_down, palette);
>  
> +stride_encoded = width;
>  switch (type) {
>  case LZ_IMAGE_TYPE_RGBA:
>  as_type = LZ_IMAGE_TYPE_RGBA;
>  pixman_format = PIXMAN_LE_a8r8g8b8;
> +stride_encoded *= 4;
>  break;
>  case LZ_IMAGE_TYPE_RGB32:
>  case LZ_IMAGE_TYPE_RGB24:
> @@ -832,6 +839,7 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>  case LZ_IMAGE_TYPE_PLT8:
>  as_type = LZ_IMAGE_TYPE_RGB32;
>  pixman_format = PIXMAN_LE_x8r8g8b8;
> +stride_encoded *= 4;
>  break;
>  case LZ_IMAGE_TYPE_A8:
>  as_type = LZ_IMAGE_TYPE_A8;
> @@ -843,9 +851,11 @@ static pixman_image_t *canvas_get_lz(CanvasBase *canvas, 
> SpiceImage *image,
>   canvas->format == SPICE_SURFACE_FMT_32_ARGB)) {
>  as_type = LZ_IMAGE_TYPE_RGB32;
>  pixman_format = PIXMAN_LE_x8r8g8b8;
> +stride_encoded *= 4;
>  } else

Re: [Spice-devel] [spice-common v3] use specific subdomains for better filtering

[David Jaša]

On Po, 2016-04-18 at 15:58 +0200, Victor Toso wrote:
> Hi,
> 
> On Fri, Apr 15, 2016 at 04:22:05PM +0200, David Jaša wrote:
> > Hi, I like the approach a lot. It seems quite clear and nice to me,
> > but ...
> >
> > On So, 2016-03-12 at 15:32 +0100, Victor Toso wrote:
> > > Hi! I've rebased this series and pushed to my remote branch in
> > > freedesktop [0] [1]. I'll try to clarify the ideia for working on this
> > > and if it does not get any positive feedback I'll take it as something
> > > not interesting to have...
> > >
> > > [0] (common) 
> > > https://cgit.freedesktop.org/~victortoso/spice-common/log/?h=logs
> > > [1] (gtk) https://cgit.freedesktop.org/~victortoso/spice-gtk/log/?h=logs
> > > fdo: https://bugs.freedesktop.org/show_bug.cgi?id=91838
> > >
> > > So, first of all, I don't want to introduce something that everybody
> > > need to understand in order to get proper debug. The main idea is able
> > > to filter in/out stuff that you don't want to see without the need to
> > > | grep -v and | grep -i it.
> > >
> > > With that said, SPICE_DEBUG=6 should work to get G_LOG_LEVEL_DEBUG of
> > > all code that uses spice logging functions.
> >
> > ... this essentially breaks compatibility in a bad way. IMO it has
> > already "sunk in" that G_MESSAGES_DEBUG=(GSpice|all) SPICE_DEBUG=1 means
> > all debug output from spice_gtk. Having just a trickle instead of
> > expected flood would be surprising.
> >
> > I suggest adding a brief message when SPICE_DEBUG is set outlining the
> > new usage so that you don't have to bother with backwards compatibility
> > and users are warned.
> 
> Yes, SPICE_DEBUG should always work as boolean (agreed with Marc-Andre about 
> it
> before, I think). I still think that it is okay to filter subdomains under
> SPICE_DEBUG.
> >

I'm OK even with behaviour change, it just needs to be accompanied with
a notice that users won't see everything with that setting.

David

> > The same would be suitable eventually for spice server when it's
> > SPICE_DEBUG_LEVEL-controlled debugging is replaced with a new one.
> >
> > > With all debug enable you would see all lines prefixed with
> > > "[subdomain-name]" so, in case you don't want to see it (filter out),
> > > you could:
> > >
> > > $SPICE_DEBUG=6,subdomain-name:- remote-viwer ...
> > >
> > > And voilà, nothing from it will be showed as '-' is the same as '0'
> > > which is *no debug*. The opposite of it would be '*' or '6'.
> > > * Both '-' and 0 would work and "none" as well;
> > > * Both '*' and 6 would work and "debug" as well;
> > >
> >
> > +1 to Marc-André's suggestion to remove multiple choices.
> 
> Okay :)
> 
> >
> > > In case you only want to see some debug info, you could do something
> > > like:
> > >
> > > SPICE_DEBUG=audio:*,playback:*
> > >
> > > This would show spice-audio, spice-gstaduio, spice-pulse,
> > > channel-playback debugs and nothing else.
> >
> > I don't like asterisks because they need to be escaped in shell. For
> > subdomains, "all" would be IMO better and for log levels, highest
> > verbosity level should be sufficient. The highest level could be printed
> > in the logging overview message (and either taken out of the actual
> > code, or standardized in coding style to avoid surprises).
> >
> > HTH,
> >
> > David
> 
> Sure.
> I'm taking a closer look to the outcome from support under glib for structured
> logging API [0]. Hopefully we can reduce the work to have this RFE in spice 
> with
> this glib support... Let's see ;)
> 
> [0] https://bugzilla.gnome.org/show_bug.cgi?id=744456
> 
> Thanks for taking a look on this series,
>   Victor Toso
> 
> >
> > >
> > > Q: Do you want this just to avoid grep?
> > > A: No! We should not avoid inserting debug into the code because it
> > > could get verbose, we should smart handling it with something like this
> > > IMHO. We have a few #ifdef #DEBUG_THIS which is not useful when asking
> > > debug info to reporter in open bugs.
> > > 
> > > I really think that this could be improved a lot yet but it would need a
> > > proper discussion. If this does not seem useful, then it's fine :)
> > > 
> > > Another misc info:
>

Re: [Spice-devel] Protocol extensions

[David Jaša]

Hi Thomas,

Spice supports proxying over HTTP CONNECT method to achieve connecting
to spice servers in DMZs or with private addresses from general
internet. The spice client has to know the internal name/IP of the host
system so you can use .vv file to abstract users from these details.
Connection to oVirt VMs work this way. The scheme is then

"Dispatcher"
   |
   | .vv file
   |
   v  internet private network
client (remote-viewer) -> proxy > host1
  host2

If you use single host, you can also use SSH tunnelling by libvirt
(pointing virt-viewer or virt-manager to qemu+ssh:// URI).

HTH,

David

On So, 2016-04-16 at 23:09 +, thke...@bluewin.ch wrote:
> Hi all,
> 
> I have studied the protocol that a spice client sends to a spice
> server.
> 
> If I have a socket listening on a specific port (in spice for example
> the port 5900). I get on the socket listener a RED_LINK message. From
> this message I cannot
> get additional parameters like for example
> spice://myhost.com:5900/hosteddomain/jack where
> - myhost.com is the public IP to connect
> - hosteddomain is for example a identifier for a subscriber of a VM
> (Vitual Machine) cluster
> - jack is the end user or some abstract path for a location in the
> internal net 
> 
> The usage is simple. For example I assume to host seven VM all running
> some Linux distribution for a university or a company.
> 
> Internally I like to make some redirection of the spice request.
> - say it's a server at myhost.com listening to port 5900.
> - It parses the connection string and looks up in a IP table of the
> internal network where the VM's are located for the hosteddomain. With
> the additional identifier jack I know
> to which VM cluster I have to connect. On each host for VM's are for
> example 4 VM's. 
> 
> spice client  --- spice dispatcher  --- (hosteddomain1:192.168.1.20)
> 
> 
> jack ---> 192.168.1.30---> spice-server (using
> port 9500)-->connection to VM001
> 
> anna --> 192.168.1.30---> spice-server (using port
> 9502) 
> 
>  ---
> (hosteddomain2:192.168.2.40)   
> 
>  fred --> 192.168.2.59---> spice-server (using
> port 9500)
>  
> 
>  Such a spice dispatcher is relativ easely to program for an
> administrator.
>  
> 
> The protocol on the website is in the draft release.
> 
> My questions:
> - Is there a way to already achieve this?
> - Or are there planned steps forwarding in this direction?
> 
> Best regards
> 
> Thomas
> 
> 
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH 14/20] Use GQueue for RedCharDevice::send_queue

[David Jaša]

On Po, 2016-04-18 at 05:17 -0400, Frediano Ziglio wrote:
> > On Thu, 2016-04-14 at 16:50 -0500, Jonathon Jongsma wrote:
> > > From: Christophe Fergeau 
> > > 
> > > There was an extra RedCharDeviceMsgToClientItem type whose only
> > > purpose was to manage a linked list of items to send. GQueue has the
> > > same purpose as this type in addition to being generic. As the length of
> > > the send queue is tracked, a GQueue is more appropriate than a GList and
> > > allow to remove RedCharDevice::send_queue_size.
> > > ---
> > >  server/char-device.c | 69
> > >  ++-
> > > -
> > >  1 file changed, 23 insertions(+), 46 deletions(-)
> > > 
> > > diff --git a/server/char-device.c b/server/char-device.c
> > > index f3e16da..6b9596e 100644
> > > --- a/server/char-device.c
> > > +++ b/server/char-device.c
> > > @@ -41,8 +41,7 @@ struct RedCharDeviceClient {
> > >  uint64_t num_send_tokens; /* send to client */
> > >  SpiceTimer *wait_for_tokens_timer;
> > >  int wait_for_tokens_started;
> > > -Ring send_queue;
> > > -uint32_t send_queue_size;
> > > +GQueue *send_queue;
> > >  uint32_t max_send_queue_size;
> > >  };
> > >  
> > > @@ -105,11 +104,6 @@ static guint signals[RED_CHAR_DEVICE_LAST_SIGNAL];
> > >  static void red_char_device_write_buffer_unref(RedCharDeviceWriteBuffer
> > > *write_buf);
> > >  static void red_char_device_write_retry(void *opaque);
> > >  
> > > -typedef struct RedCharDeviceMsgToClientItem {
> > > -RingItem link;
> > > -PipeItem *msg;
> > > -} RedCharDeviceMsgToClientItem;
> > > -
> > >  static PipeItem *
> > >  red_char_device_read_one_msg_from_device(RedCharDevice *dev)
> > >  {
> > > @@ -187,19 +181,10 @@ static void
> > > red_char_device_write_buffer_pool_add(RedCharDevice *dev,
> > >  static void red_char_device_client_send_queue_free(RedCharDevice *dev,
> > > RedCharDeviceClient
> > > *dev_client)
> > >  {
> > > -spice_debug("send_queue_empty %d", ring_is_empty(&dev_client
> > > ->send_queue));
> > > -while (!ring_is_empty(&dev_client->send_queue)) {
> > > -RingItem *item = ring_get_tail(&dev_client->send_queue);
> > > -RedCharDeviceMsgToClientItem *msg_item = SPICE_CONTAINEROF(item,
> > > -
> > >  RedCharDeviceMsgToClientItem,
> > > -   link);
> > > -
> > > -ring_remove(item);
> > > -pipe_item_unref(msg_item->msg);
> > > -free(msg_item);
> > > -}
> > > -dev_client->num_send_tokens += dev_client->send_queue_size;
> > > -dev_client->send_queue_size = 0;
> > > +spice_debug("send_queue_empty %d", g_queue_is_empty(dev_client
> > > ->send_queue));
> > > +g_queue_free_full(dev_client->send_queue, pipe_item_unref);
> > > +g_queue_clear(dev_client->send_queue);
> > > +dev_client->num_send_tokens += g_queue_get_length(dev_client
> > > ->send_queue);
> > 
> > This looks wrong. We're calling g_queue_get_length() immediately after
> > clearing
> > the queue, so it's guaranteed to be 0. This last line should be moved before
> > the
> > g_queue_free_full() call.
> > 
> > >  }
> > >  
> > >  static void red_char_device_client_free(RedCharDevice *dev,
> > > @@ -303,17 +288,14 @@ static void
> > > red_char_device_add_msg_to_client_queue(RedCharDeviceClient *dev_cli
> > >  PipeItem *msg)
> > >  {
> > >  RedCharDevice *dev = dev_client->dev;
> > > -RedCharDeviceMsgToClientItem *msg_item;
> > >  
> > > -if (dev_client->send_queue_size >= dev_client->max_send_queue_size) {
> > > +if (g_queue_get_length(dev_client->send_queue) >= dev_client
> > > ->max_send_queue_size) {
> > >  red_char_device_handle_client_overflow(dev_client);
> > >  return;
> > >  }
> > >  
> > > -msg_item = spice_new0(RedCharDeviceMsgToClientItem, 1);
> > > -msg_item->msg = pipe_item_ref(msg);
> > > -ring_add(&dev_client->send_queue, &msg_item->link);
> > > -dev_client->send_queue_size++;
> > > +pipe_item_ref(msg);
> > > +g_queue_push_head(dev_client->send_queue, msg);
> > >  if (!dev_client->wait_for_tokens_started) {
> > >  reds_core_timer_start(dev->priv->reds, dev_client
> > > ->wait_for_tokens_timer,
> > >RED_CHAR_DEVICE_WAIT_TOKENS_TIMEOUT);
> > > @@ -332,7 +314,7 @@ static void
> > > red_char_device_send_msg_to_clients(RedCharDevice *dev,
> > >  dev_client = SPICE_CONTAINEROF(item, RedCharDeviceClient, link);
> > >  if (red_char_device_can_send_to_client(dev_client)) {
> > >  dev_client->num_send_tokens--;
> > > -spice_assert(ring_is_empty(&dev_client->send_queue));
> > > +spice_assert(g_queue_is_empty(dev_client->send_queue));
> > >  red_char_device_send_msg_to_client(dev, msg,
> > >  dev_client->client);
> > >  
> > >

Re: [Spice-devel] [spice-devel]How to reduce the image resolution or definition ?

[David Jaša]

Hi,

This code comment suggests that during streaming, JPG quality adjustment
takes place:

/*
 * Adjusting the stream jpeg quality and frame rate (fps):
 * When during_quality_eval=TRUE, we compress different frames with different
 * jpeg quality. By considering (1) the resulting compression ratio, and (2) 
the available
 * bit rate, we evaluate the max frame frequency for the stream with the given 
quality,
 * and we choose the highest quality that will allow a reasonable frame rate.
 * during_quality_eval is set for new streams and can also be set any time we 
want
 * to re-evaluate the stream parameters (e.g., when the bit rate and/or
 * compressed frame size significantly change).
 */
- taken from 
https://cgit.freedesktop.org/spice/spice/tree/server/mjpeg-encoder.c#n122

That should do pretty much exactly what you want - adjust stream
bandwidth to available network throughput, albeit by using jpeg quality
instead of downscaling. That's better approach IMO as b/w savings can be
as big as with downscaling but CPU load will be significantly lower.

Regards,

David


On Út, 2016-04-12 at 17:18 +0800, hongzhen_...@sina.com wrote:
>  Hello  
> 
> 
>Could you tell  me how to reduce the image resolution or
> definition ?
> 
>I plan to reduce the image definition so that  decrease data
> transmission from server to client .
> 
>For example ,I assume if I have a low bandwidth in my network
> environment,but it's stable , I want to reduce the image definition
> to ensure a small quantity of data were sent  between the server and
> client  ,for the client can be worked normally (such as basic
> operation).
> 
> 
>   But I don't know how to modify and control it (which functions
> or attributes),  if you know that ,please help  me . Thank you very
> much ...
> 
> Best Regards 
> 
> 
> 
> 
>  
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Seeking kind help

[David Jaša]

Hello,

this list is for Spice the VDI protocol, not Spice the Circuit
simulator. What you're probably looking for is some of ngspice project
mailing lists: http://ngspice.sourceforge.net/mlarch.html

David

On Ne, 2016-05-08 at 19:31 +0800, jakkula bhoolaxmi wrote:
> Dear Sir/Madam,
> 
> 
> I have simulated one circuit which is from one of the IEEE paper, they
> have got power dissipation in micro watts,  but I am getting power
> dissipation in nano watts for the same circuit. May I seek your kind
> help whats wrong in my code. Many thanks in advance for your kind
> help.
> 
> 
> 
> 
>  1. The Circuit I referred,
> Inline image 2
> 
> 
> 
> 
> 
>  The referred paper is attached herewith.
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Add Czech translation

[David Jaša]

At last. :)

Signed-off-by: David Jaša 
---
 po/cs.po | 336 +++
 1 file changed, 336 insertions(+)
 create mode 100644 po/cs.po

diff --git a/po/cs.po b/po/cs.po
new file mode 100644
index 000..f5cbc5f
--- /dev/null
+++ b/po/cs.po
@@ -0,0 +1,336 @@
+# Czech translations for spice-gtk package.
+# Copyright (C) 2009-2019 Red Hat, Inc.
+# This file is distributed under the same license as the spice-gtk package.
+# David Jaša , 2019.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: spice-gtk master\n"
+"Report-Msgid-Bugs-To: spice-devel@lists.freedesktop.org\n"
+"POT-Creation-Date: 2019-04-11 15:17+0200\n"
+"PO-Revision-Date: 2019-04-12 09:22+0200\n"
+"Last-Translator: David Jaša \n"
+"Language-Team: Czech < >\n"
+"Language: cs\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2\n"
+"X-Generator: Gtranslator 3.32.0\n"
+
+#: src/channel-main.c:1896
+msgid "The spice agent cancelled the file transfer"
+msgstr "Spice agent zrušil přenos souboru"
+
+#: src/channel-main.c:1900
+msgid "The spice agent reported an error during the file transfer"
+msgstr "Spice agent hlásí chybu při přenosu souboru"
+
+#: src/channel-main.c:1907
+#, c-format
+msgid ""
+"File transfer failed due to lack of free space on remote machine (%s free, "
+"%s to transfer)"
+msgstr ""
+"Přenos souboru zrušen kvůli nedostatku místa na vzdáleném stroji (%s "
+"volných, %s zbývá přenést)"
+
+#: src/channel-main.c:1915
+msgid ""
+"User's session is locked and cannot transfer files, unlock it and try again."
+msgstr ""
+"Sezení je zamčené a nemůže přijímat soubory, odemčete ho a zkuste znovu."
+
+#: src/channel-main.c:1920
+msgid "Session agent not connected."
+msgstr "Agent sezení není připojen"
+
+#: src/channel-main.c:1924
+msgid "File transfer is disabled."
+msgstr "Přenos souboru je vypnutý."
+
+#: src/channel-main.c:3307
+#, c-format
+msgid "The file transfer is disabled"
+msgstr "Přenos souboru je vypnutý!"
+
+#: src/channel-usbredir.c:914
+#, c-format
+msgid "usbredir protocol parse error for %s"
+msgstr "Chyba zpracování protokolu usbredir pro %s"
+
+#: src/channel-usbredir.c:919
+#, c-format
+msgid "%s rejected by host"
+msgstr "%s byl hostitelem odmítnut"
+
+#: src/channel-usbredir.c:924
+#, c-format
+msgid "%s disconnected (fatal IO error)"
+msgstr "%s odpojeno (fatální chyba vstupu/výstupu)"
+
+#: src/channel-usbredir.c:928
+#, c-format
+msgid "Unknown error (%d) for %s"
+msgstr "Neznámá chyba (%d) pro %s"
+
+#: src/desktop-integration.c:99
+msgid "Automounting has been inhibited for USB auto-redirecting"
+msgstr ""
+"Automatické připojování je potlačené kvůli automatickému přesměrování USB"
+
+#: src/spice-channel.c:1177
+msgid "Authentication failed"
+msgstr "Přihlášení selhalo"
+
+#: src/spice-channel.c:1195
+msgid "Authentication failed: password is too long"
+msgstr "Přihlášení selhalo: příliš dlouhé heslo"
+
+#: src/spice-channel.c:1200
+msgid "Authentication failed: wrong password?"
+msgstr "Přihlášení selhalo: špatné heslo?"
+
+#: src/spice-option.c:60
+msgid "--spice-color-depth is deprecated. Use guest's display settings instead"
+msgstr "--spice-color-depth je zastaralé. Použijte natavení obrazovky"
+
+#: src/spice-option.c:80
+#, c-format
+msgid ""
+"invalid effect name (%s), must be 'wallpaper', 'font-smooth', 'animation' or "
+"'all'"
+msgstr ""
+"Neplatné jméno efektu (%s), musí být „wallpaper“ (pozadí), „font-"
+"smooth“ (vyhlazení písem), „animation“ (animace) nebo „all“ (vše)"
+
+#: src/spice-option.c:104
+#, c-format
+msgid "invalid channel name (%s), valid names: all, %s"
+msgstr "neplatný název kanálu (%s), platné názvy: all, %s"
+
+#: src/spice-option.c:140
+#, c-format
+msgid "Image compression algorithm %s not supported"
+msgstr "Algoritmus komprese obrazu %s není podporován"
+
+#: src/spice-option.c:162
+msgid "Force the specified channels to be secured"
+msgstr "Vynutit šifrování vyjmenovaných kanálů"
+
+#: src/spice-option.c:164
+msgid "Disable guest display effects"
+msgstr "Vypnout efekty zobrazení na vzdáleném stroji"
+
+#: src/spice-option.c:167
+msgid "Guest display color depth (depr

[Spice-devel] [PATCH spice-gtk v2] Add Czech Translation

[David Jaša]

Changes since v1:
* added 'cs' to LINGUAS
* added both plurals after fix of 
https://gitlab.freedesktop.org/spice/spice-gtk/issues/95
* tried to address review comments by Jakub

Signed-off-by: David Jaša 
---
 po/LINGUAS |   1 +
 po/cs.po   | 336 +
 2 files changed, 337 insertions(+)
 create mode 100644 po/cs.po

diff --git a/po/LINGUAS b/po/LINGUAS
index b703d74..8480346 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -1,4 +1,5 @@
 # keep this file sorted alphabetically, one language code per line
+cs
 de
 fr
 it
diff --git a/po/cs.po b/po/cs.po
new file mode 100644
index 000..46fa1c6
--- /dev/null
+++ b/po/cs.po
@@ -0,0 +1,336 @@
+# Czech translations for spice-gtk package.
+# Copyright (C) 2009-2019 Red Hat, Inc.
+# This file is distributed under the same license as the spice-gtk package.
+# David Jaša , 2019.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: spice-gtk master\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2019-04-18 10:54+0200\n"
+"PO-Revision-Date: 2019-04-12 09:22+0200\n"
+"Last-Translator: David Jaša \n"
+"Language-Team: Czech < >\n"
+"Language: cs\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2\n"
+"X-Generator: Gtranslator 3.32.0\n"
+
+#: src/channel-main.c:1896
+msgid "The spice agent cancelled the file transfer"
+msgstr "Spice agent zrušil přenos souboru"
+
+#: src/channel-main.c:1900
+msgid "The spice agent reported an error during the file transfer"
+msgstr "Spice agent hlásí chybu při přenosu souboru"
+
+#: src/channel-main.c:1907
+#, c-format
+msgid ""
+"File transfer failed due to lack of free space on remote machine (%s free, "
+"%s to transfer)"
+msgstr ""
+"Přenos souboru zrušen kvůli nedostatku místa na vzdáleném stroji (%s "
+"volných, %s k přenosu)"
+
+#: src/channel-main.c:1915
+msgid ""
+"User's session is locked and cannot transfer files, unlock it and try again."
+msgstr ""
+"Obrazovka vzdáleného počítače je zamčena a ten tedy nemůže přijímat soubory, "
+"odemčete ji a zkuste soubor přenést znovu."
+
+#: src/channel-main.c:1920
+msgid "Session agent not connected."
+msgstr "Uživatelská část agenta není připojena."
+
+#: src/channel-main.c:1924
+msgid "File transfer is disabled."
+msgstr "Přenos souborů je vypnutý."
+
+#: src/channel-main.c:3307
+#, c-format
+msgid "The file transfer is disabled"
+msgstr "Přenos souborů je vypnutý"
+
+#: src/channel-usbredir.c:914
+#, c-format
+msgid "usbredir protocol parse error for %s"
+msgstr "Chyba zpracování protokolu usbredir pro %s"
+
+#: src/channel-usbredir.c:919
+#, c-format
+msgid "%s rejected by host"
+msgstr "Zařízení %s byl hostitelem odmítnuto"
+
+#: src/channel-usbredir.c:924
+#, c-format
+msgid "%s disconnected (fatal IO error)"
+msgstr "Zařízení %s odpojeno (fatální chyba vstupu/výstupu)"
+
+#: src/channel-usbredir.c:928
+#, c-format
+msgid "Unknown error (%d) for %s"
+msgstr "Neznámá chyba (%d) pro %s"
+
+#: src/desktop-integration.c:99
+msgid "Automounting has been inhibited for USB auto-redirecting"
+msgstr ""
+"Automatické připojování USB disků je potlačeno kvůli automatickému "
+"přesměrování USB"
+
+#: src/spice-channel.c:1177
+msgid "Authentication failed"
+msgstr "Přihlášení selhalo"
+
+#: src/spice-channel.c:1195
+msgid "Authentication failed: password is too long"
+msgstr "Přihlášení selhalo: příliš dlouhé heslo"
+
+#: src/spice-channel.c:1200
+msgid "Authentication failed: wrong password?"
+msgstr "Přihlášení selhalo: špatné heslo?"
+
+#: src/spice-option.c:60
+msgid "--spice-color-depth is deprecated. Use guest's display settings instead"
+msgstr "--spice-color-depth je zastaralé. Použijte natavení obrazovky"
+
+#: src/spice-option.c:80
+#, c-format
+msgid ""
+"invalid effect name (%s), must be 'wallpaper', 'font-smooth', 'animation' or "
+"'all'"
+msgstr ""
+"Neplatné jméno efektu (%s), musí být „wallpaper“ (pozadí), „font-"
+"smooth“ (vyhlazení písem), „animation“ (animace) nebo „all“ (vše)"
+
+#: src/spice-option.c:104
+#, c-format
+msgid "invalid channel name (%s), valid names: all, %s"
+msgstr "neplatný název kanálu (%s), platné názvy: all, %s"
+
+#: src/spice-option.c:140
+#, c-format
+msgid "Image compressi

[Spice-devel] [PATCH] Add Czech Translation

[David Jaša]

Changes since v1:
* added 'cs' to LINGUAS
* added both plurals after fix of 
https://gitlab.freedesktop.org/spice/spice-gtk/issues/95
* tried to address review comments by Jakub

Changes since v2:
* fixed the remaining typos

Signed-off-by: David Jaša 
---
 po/LINGUAS |   1 +
 po/cs.po   | 336 +
 2 files changed, 337 insertions(+)
 create mode 100644 po/cs.po

diff --git a/po/LINGUAS b/po/LINGUAS
index b703d74..8480346 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -1,4 +1,5 @@
 # keep this file sorted alphabetically, one language code per line
+cs
 de
 fr
 it
diff --git a/po/cs.po b/po/cs.po
new file mode 100644
index 000..20bfba8
--- /dev/null
+++ b/po/cs.po
@@ -0,0 +1,336 @@
+# Czech translations for spice-gtk package.
+# Copyright (C) 2009-2019 Red Hat, Inc.
+# This file is distributed under the same license as the spice-gtk package.
+# David Jaša , 2019.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: spice-gtk master\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2019-04-18 10:54+0200\n"
+"PO-Revision-Date: 2019-04-12 09:22+0200\n"
+"Last-Translator: David Jaša \n"
+"Language-Team: Czech < >\n"
+"Language: cs\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2\n"
+"X-Generator: Gtranslator 3.32.0\n"
+
+#: src/channel-main.c:1896
+msgid "The spice agent cancelled the file transfer"
+msgstr "Spice agent zrušil přenos souboru"
+
+#: src/channel-main.c:1900
+msgid "The spice agent reported an error during the file transfer"
+msgstr "Spice agent hlásí chybu při přenosu souboru"
+
+#: src/channel-main.c:1907
+#, c-format
+msgid ""
+"File transfer failed due to lack of free space on remote machine (%s free, "
+"%s to transfer)"
+msgstr ""
+"Přenos souboru zrušen kvůli nedostatku místa na vzdáleném stroji (%s "
+"volných, %s k přenosu)"
+
+#: src/channel-main.c:1915
+msgid ""
+"User's session is locked and cannot transfer files, unlock it and try again."
+msgstr ""
+"Obrazovka vzdáleného počítače je zamčena a ten tedy nemůže přijímat soubory, "
+"odemkněte ji a zkuste soubor přenést znovu."
+
+#: src/channel-main.c:1920
+msgid "Session agent not connected."
+msgstr "Uživatelská část agenta není připojena."
+
+#: src/channel-main.c:1924
+msgid "File transfer is disabled."
+msgstr "Přenos souborů je vypnutý."
+
+#: src/channel-main.c:3307
+#, c-format
+msgid "The file transfer is disabled"
+msgstr "Přenos souborů je vypnutý"
+
+#: src/channel-usbredir.c:914
+#, c-format
+msgid "usbredir protocol parse error for %s"
+msgstr "Chyba zpracování protokolu usbredir pro %s"
+
+#: src/channel-usbredir.c:919
+#, c-format
+msgid "%s rejected by host"
+msgstr "Zařízení %s bylo hostitelem odmítnuto"
+
+#: src/channel-usbredir.c:924
+#, c-format
+msgid "%s disconnected (fatal IO error)"
+msgstr "Zařízení %s odpojeno (fatální chyba vstupu/výstupu)"
+
+#: src/channel-usbredir.c:928
+#, c-format
+msgid "Unknown error (%d) for %s"
+msgstr "Neznámá chyba (%d) pro %s"
+
+#: src/desktop-integration.c:99
+msgid "Automounting has been inhibited for USB auto-redirecting"
+msgstr ""
+"Automatické připojování USB disků je potlačeno kvůli automatickému "
+"přesměrování USB"
+
+#: src/spice-channel.c:1177
+msgid "Authentication failed"
+msgstr "Přihlášení selhalo"
+
+#: src/spice-channel.c:1195
+msgid "Authentication failed: password is too long"
+msgstr "Přihlášení selhalo: příliš dlouhé heslo"
+
+#: src/spice-channel.c:1200
+msgid "Authentication failed: wrong password?"
+msgstr "Přihlášení selhalo: špatné heslo?"
+
+#: src/spice-option.c:60
+msgid "--spice-color-depth is deprecated. Use guest's display settings instead"
+msgstr "--spice-color-depth je zastaralé. Použijte natavení obrazovky"
+
+#: src/spice-option.c:80
+#, c-format
+msgid ""
+"invalid effect name (%s), must be 'wallpaper', 'font-smooth', 'animation' or "
+"'all'"
+msgstr ""
+"Neplatné jméno efektu (%s), musí být „wallpaper“ (pozadí), „font-"
+"smooth“ (vyhlazení písem), „animation“ (animace) nebo „all“ (vše)"
+
+#: src/spice-option.c:104
+#, c-format
+msgid "invalid channel name (%s), valid names: all, %s"
+msgstr "neplatný název kanálu (%s), platné názvy: all, %s"
+
+#: src/spice-opti

Re: [Spice-devel] [PATCH spice-gtk 1/4] tests: Add test for SpiceUri

[David Jaša]

On Po, 2016-05-16 at 10:10 -0400, Frediano Ziglio wrote:
> > 
> > Related: rhbz#1335239
> > ---
> >  tests/Makefile.am  |  2 ++
> >  tests/test-spice-uri.c | 64
> >  ++
> >  2 files changed, 66 insertions(+)
> >  create mode 100644 tests/test-spice-uri.c
> > 
> > diff --git a/tests/Makefile.am b/tests/Makefile.am
> > index c1d95c1..fb97138 100644
> > --- a/tests/Makefile.am
> > +++ b/tests/Makefile.am
> > @@ -4,6 +4,7 @@ noinst_PROGRAMS =
> >  TESTS = coroutine  \
> > util\
> > session \
> > +   test-spice-uri  \
> > $(NULL)
> >  
> >  if WITH_PHODAV
> > @@ -35,6 +36,7 @@ util_SOURCES = util.c
> >  coroutine_SOURCES = coroutine.c
> >  session_SOURCES = session.c
> >  pipe_SOURCES = pipe.c
> > +test_spice_uri_SOURCES = test-spice-uri.c
> >  usb_acl_helper_SOURCES = usb-acl-helper.c
> >  usb_acl_helper_CFLAGS = -DTESTDIR=\"$(abs_builddir)\"
> >  mock_acl_helper_SOURCES = mock-acl-helper.c
> > diff --git a/tests/test-spice-uri.c b/tests/test-spice-uri.c
> > new file mode 100644
> > index 000..993cc78
> > --- /dev/null
> > +++ b/tests/test-spice-uri.c
> > @@ -0,0 +1,64 @@
> > +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mode: nil -*- */
> > +/*
> > +   Copyright (C) 2016 Red Hat, Inc.
> > +
> > +   This library is free software; you can redistribute it and/or
> > +   modify it under the terms of the GNU Lesser General Public
> > +   License as published by the Free Software Foundation; either
> > +   version 2.1 of the License, or (at your option) any later version.
> > +
> > +   This library is distributed in the hope that it will be useful,
> > +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > +   Lesser General Public License for more details.
> > +
> > +   You should have received a copy of the GNU Lesser General Public
> > +   License along with this library; if not, see
> > .
> > +*/
> > +#include 
> > +#include 
> > +#include "spice-uri-priv.h"
> > +
> > +static void test_spice_uri_ipv4(void)
> > +{
> > +SpiceURI *uri = spice_uri_new();
> > +g_assert_nonnull(uri);
> > +
> > +/* missing hostname */
> > +g_assert_false(spice_uri_parse(uri, "http://:80";, NULL));
> > +/* invalid port */
> > +g_assert_false(spice_uri_parse(uri, "http://127.0.0.1:port";, NULL));
> > +
> > +g_assert_true(spice_uri_parse(uri, "http://127.0.0.1/";, NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "http");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "127.0.0.1");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 3128);
> > +
> > +g_assert_true(spice_uri_parse(uri, "https://127.0.0.1";, NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "https");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "127.0.0.1");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 3129);
> > +
> > +g_assert_true(spice_uri_parse(uri, "127.0.0.1", NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "http");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "127.0.0.1");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 3128);
> > +
> > +g_assert_true(spice_uri_parse(uri, "http://user:password@host:80";,
> > NULL));
> > +g_assert_cmpstr(spice_uri_get_scheme(uri), ==, "http");
> > +g_assert_cmpstr(spice_uri_get_hostname(uri), ==, "host");
> > +g_assert_cmpstr(spice_uri_get_user(uri), ==, "user");
> > +g_assert_cmpstr(spice_uri_get_password(uri), ==, "password");
> > +g_assert_cmpuint(spice_uri_get_port(uri), ==, 80);
> > +
> > +g_object_unref(uri);
> > +}
> > +
> > +int main(int argc, char* argv[])
> > +{
> > +g_test_init(&argc, &argv, NULL);
> > +
> > +g_test_add_func("/spice_uri/ipv4", test_spice_uri_ipv4);
> > +
> > +return g_test_run();
> > +}
> > --
> > 2.8.2
> > 
> 
> Looks ok, a bit weird that default ports are 3128 and 3129, looks different
> from the "URI" definition.

IIUC there is no real standard port for http CONNECT proxies, let alone
for much less used https. 3128 is default for squid, some other default
to 8080/8443 and some use just standard http(s) ports of 80/443 (e.g.
apache's mod_proxy).

David

> 
> Frediano
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [ovirt-users] Accessing VM over WAN

[David Jaša]

On Ne, 2016-06-26 at 09:36 +0530, RK RK wrote:
> Hi,
> 
> 
> I am planning to deploy oVirt 4.0.0 in a production environment where
> initially it will host 150 VDIs and will expand by 20 to 25 in
> subsequent years with Windows 7, 8.1 and 10.
> 

Please note that official win8+ qxl driver is not ready yet so you won't
have continuous resolution change (just in steps of well-known
resolutions), multi monitor support and some video performance
optimizations with those OSs

> 
> Users will be accessing these VDIs from their android tab or any tiny
> thin client devices which will have only very small footprint OS with
> HTML5 supported browser. 
> 

Please consider use of native apps: aSpice/Opaque [1] or "flexVDI
Client" [2] or moVirt [3]. Opaque and moVirt give you oVirt integration
right away, flexVDI has iOS support

[1] 
https://play.google.com/store/apps/developer?id=Iordan%20Iordanov%20%28Undatech%29
[2] https://github.com/flexVDI/launcher-mobile
[3] https://play.google.com/store/apps/details?id=org.ovirt.mobile.movirt

All of them are going to have better UX than spice-html5. FlexVDI also
developed their own html5 client (available at their github as well)
with some stuff better and some worse than spice-html5 client.

> I wish to give users to access the VDIs over WAN(from their home or on
> travel). Is it possible to access the VDIs via spice-html5 over the
> WAN.
> 

IIRC spice-html5 supports all the compression types so protocol-side
optimizations should be available automatically and without issues.

The "WAN options" of user portal mean that agent disables "fancy" bits
of Windows graphics, the only support from client is to do the setting
when establishing connection. You could give it a try

> 
> Any special configurations to be made to enable it? How should I make
> spice-html5 as the default protocol to access the VDIs?

set ClientModeSpiceDefault engine-config variable to Html5 (as per
https://bugzilla.redhat.com/show_bug.cgi?id=1311408 )

HTH,

David

> 
> -- 
> 
> With Regards,
> RK,
> +91 9840483044
> 
> ___
> Users mailing list
> us...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH RFC 00/12] Remote Virgl support

[David Jaša]

Hi,

On Po, 2016-07-18 at 16:16 +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > What is the state of the hardware supported encoding?
> > > How can we pass buffers to the hardware encoder? 
> > 
> > The state here is a bit of a mess.
> > One reason to pass texture instead of dma buffers is that we use gstreamer
> > and gstreamer for hardware acceleration uses VAAPI and one way to pass
> > frames to VAAPI is to use GL textures. There is a quite strong requirement
> > that dma buffers should be mmap-able in gstreamer but this is not true.
> > Note that in theory VAAPI can import DRM prime/dma buffers however this is
> > currently not exported/implemented by gstreamer-vaapi.
> 
> Any chance to extend gstreamer-vaapi?
> 
> > The current status of hardware encoding is a bit confusing.
> > On one side there is VAAPI which should be an independent (from card brand)
> > library to use hardware decoding/encoding however some vendor (like Nvidia)
> > seems not really keen on supporting it for encoding (the binding for Nvidia
> > is using vdpau which is limited to decoding). VAAPI was proposed by Intel
> > so for Intel is really good.
> 
> Hmm.  But vaapi support is pretty much required to have gstreamer handle
> video encoding for us I guess?
> 
> > On the other side we could have patent/licensing issues due to the fact that
> > main encoding supported (basically mpeg2, h264, hevc) all have patents while
> > more open encoding (vp8, vp9) are not currently widely supported.
> 
> That is nasty indeed.  Recent intel hardware supports vp8 + vp9 too.
> Nvidia is H.264 only as far I know.
> 
> Not sure if offloading the encoding to the hardware helps with the
> patent situation.  At least we don't have to ship a (cpu) software
> encoder then.  But possibly some kind of firmware or gpu program must be
> uploaded ...
> 

Cisco's OpenH264 encodes and decodes basic profile of h.264 and Cisco is
covering patent fees for anybody who uses it. It is not shipped with
everybody's OS by default but given the motivation and implementation,
it should be available pretty much anywhere in quite near term (it
actually is available on most systems running Firefox - but it Firefox's
directories, not system ones).

Cisco already provides a Fedora repo with decoder packaged for Firefox
and Gstreamer. Given that, we could probably depend on h.264 basic being
available universally pretty soon.

David

Fedora's OpenH264 wiki page: https://fedoraproject.org/wiki/OpenH264

> > >  (1) Extend the display channel interface to have callbacks for these
> > >  (and thin wrapper functions which map spice display channel to
> > >  QemuConsole so spice-server doesn't need to worry about that).
> > > 
> > 
> > So you mean a way for spice-server display channel to call some Qemu
> > function, right?
> 
> Yes.  Add function pointers to QXLInterface & raise minor display
> channel interface version should do.
> 
> > >  (2) Have qemu create one context per spice-server (or per display
> > >  channel) and create a new spice_server_set_egl_context() function
> > >  to hand over the context to spice-server.
> > > 
> > 
> > Yes, I added a spice_qxl_gl_init function which set display and context.
> 
> Ah, didn't notice that on the first check.  Yes, that looks good
> interface-wise.  Possibly we should create a new context instead of
> reusing qemu_egl_rn_ctx.  But that doesn't affect the spice-server
> interface.
> 
> But can you make that a separate patch please?
> 
> > Probably I feel more confident having more flexibility as is not clear
> > the resulting information we need.
> 
> I surely don't want to rush things on the interface side.  I think we
> should have at least a proof-of-concept implementation showing the
> qemu/spice-server we created actually works before merging things.
> 
> > Another stuff I would like to have changed in Qemu is the number of
> > pending frames sent by it. I think that a single frame is not enough.
> > There should be at least 2/3 frames. The reason is that streaming/network
> > requires more time and would be better if there could be one frame which
> > is encoding/pending and one which is new which could be replaced by a
> > new frame that will arrive if encoding/network is not fast enough.
> 
> Hmm.  The guest will not give us 2-3 frames though.  We'll have either
> one or two, depending on whenever the guest uses page-flips or not.  So
> implementing a buffering scheme as outlined above requires us to copy
> (or let the gpu copy) the frames.
> 
> Question is where to do it best.  It is doable in qemu and spice-server.
> But spice-server knows more about the network/encoder state and can
> possibly avoid the copy, for example in case it isn't going the encode
> the frame anyway due to full network buffers, or in case no client is
> connected in the first place.
> 
> cheers,
>   Gerd
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.

Re: [Spice-devel] question: how to test the gstreamer:h264 with qemu ?

[David Jaša]

On Pá, 2016-07-29 at 10:19 +0200, cferg...@redhat.com wrote:
> On Fri, Jul 29, 2016 at 08:10:46AM +, Li, ZhijianX wrote:
> > 
> > > -Original Message-
> > > From: cferg...@redhat.com [mailto:cferg...@redhat.com]
> > > Sent: Friday, July 29, 2016 3:17 PM
> > > To: Li, ZhijianX 
> > > Cc: gou...@codeweavers.com; Spice-devel@lists.freedesktop.org
> > > Subject: Re: [Spice-devel] question: how to test the gstreamer:h264 with
> > > qemu ?
> > > 
> > > Hey,
> > > 
> > > On Fri, Jul 29, 2016 at 03:05:21AM +, Li, ZhijianX wrote:
> > > > Hello  guys,
> > > >
> > > > Recently, I found that spice have supported gstremer:h264 encoding, so I
> > > want to have a try.
> > > > But I'm not sure how to test this feature(I am a spice newbie)
> > > >
> > > > If I play a h264 encoding video in the guest, how can I *confirm* that
> > > > the gstremer:h264 works or not ?
> > > >
> > > > If I miss something, please let me know.
> > > > Below is my environment:
> > > > Host, Ubuntu 16.04 lts
> > > > 1.  guest
> > > > Win7 +" Red Hat QXL GPU(6.1.0.10020)"
> > > > 2. qemu
> > > > Branch: master + gstreamer related
> > > > patch(https://lists.freedesktop.org/archives/spice-devel/2015-May/0197
> > > > 71.html) Start qemu with " -spice video-codes=gstreamer:h264" options
> > > > 3. spice
> > > > Branch: master(comit: 29caba2)
> > > > Configuration with "--enable-gstreamer=1.0"
> > > > 4. spice-gtk
> > > > Branch: master(commit: 9b82e92)
> > > > Configuration with "--enable-gstvideo=yes"
> > > > 5. spice-protocol
> > > > Branch: master
> > > 
> > > Usually I just change default_video_codecs in spice-server/server/reds.c 
> > > so
> > > that it starts with gstreamer:h264.
> > That's interesting  :)  
> > More question: Does the spice-client side(remote-viewer) or the guest
> > driver need some special options to notify the client 
> > to use the gstreamer:h264. 
> 
> Once the streaming code triggers, use of h264 instead of mjpeg should be
> automatic if both the server and the client have the required gstreamer
> plugins.

Are we going to use some automagic decision between video formats based
on CPU and network conditions? (We were discussing something in that
vein for image compression in last months).

David

> 
> Christophe
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice-devel Digest, Vol 80, Issue 35

[David Jaša]

This very mail contains unsubscribe links in header:


List-Unsubscribe:
 , 
 


First link is web interface and 2nd one is mail - just click, send,
maybe confirm and that's it.

David

On St, 2016-09-07 at 11:49 +0800, nlx wrote:
> 
> 
> 
> Hi
>   I want to unsubscribe this mailing list , please help me.
> Thank you very much 
> 
> 
> BR.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 2016-09-05 16:34:42, spice-devel-requ...@lists.freedesktop.org wrote:
> >Send Spice-devel mailing list submissions to
> > spice-devel@lists.freedesktop.org
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> >or, via email, send a message with subject or body 'help' to
> > spice-devel-requ...@lists.freedesktop.org
> >
> >You can reach the person managing the list at
> > spice-devel-ow...@lists.freedesktop.org
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of Spice-devel digest..."
> >
> >
> >Today's Topics:
> >
> >   1. [PATCH qxl-wddm-dod v2 00/25] Win10 support patches
> >  (Sameeh Jubran)
> >   2. [PATCH qxl-wddm-dod v2 01/25] Upgrade to Windows 10WDK
> >  (Sameeh Jubran)
> >
> >
> >--
> >
> >Message: 1
> >Date: Mon,  5 Sep 2016 11:33:57 +0300
> >From: Sameeh Jubran 
> >To: spice-devel@lists.freedesktop.org
> >Cc: Dmitry Fleytman 
> >Subject: [Spice-devel] [PATCH qxl-wddm-dod v2 00/25] Win10 support
> > patches
> >Message-ID: <1473064462-8220-1-git-send-email-sam...@daynix.com>
> >
> >This series contains the latest patches to support Windows 10.
> >
> >Visual Studio 2015 with Win10 WDK is required to compile this code,
> >Current patches may be compiled and will work for Windows 10.
> >
> >To ease the process of the reviews, those patches are avilable on:
> >https://github.com/daynix/qxl-wddm-dod branch: gitlab_win10_v2
> >
> >The patches were applied on the master branch of 
> >https://gitlab.com/spice/qxl-wddm-dod
> >
> >Dmitry Fleytman (2):
> >  Fixing framebuffer usage logic
> >  Support future Qxl revisions
> >
> >Sameeh Jubran (16):
> >  Upgrade to Windows 10 WDK
> >  Add delete operator
> >  Add debug print macro to dump debug print statements to kernel
> >debugger output
> >  Add type enum to qxl/vga device
> >  On power wake call the init functions before setting the vidpn to
> >black. Otherwise, BSOD.
> >  Fix interrupt mask
> >  Remove unused notify present display only interrupt
> >  Add arbitrary resolution and monitors_config Escape
> >  Rename mspace.c to mspace.cpp
> >  Code Analysis clean up
> >  Replacing tabs with spaces
> >  Fixing Move rectangles implementation
> >  Reserved must be set to 0
> >  Fixing monitor flicker on resolution change
> >  Removing unnecessary call to BlackOutScreen
> >  Fixing possible BSOD
> >
> >Sandy Stutsman (7):
> >  Set DriverStarted flag at the begining of the StartDriver function
> >  Fix Code Integrity error generated by the Drive Verifier
> >  Use SrcPitch when calculating size of memory to map PresentDisplayOnly
> >  Use the second bar (VRAM) for qxl command buffer.
> >  Enable HW cursor support and fix handling of monochrome cursors.
> >  Remove minimum size restrict for custom resolution.
> >  Use frame buffer in VGA mode only
> >
> > Tools/vs_cmdline.vbs   |   23 +
> > Tools/vs_run.bat   |   26 +
> > buildAll.bat   |   15 +
> > buildAll_NoSign.bat|   19 +
> > qxldod Package/qxldod Package.vcxproj  |  173 +-
> > qxldod Package/qxldod Package.vcxproj.user |   15 +
> > qxldod.sln |  106 +-
> > qxldod/BaseObject.cpp  |   11 +
> > qxldod/BaseObject.h|1 +
> > qxldod/QxlDod.cpp  | 1167 +++--
> > qxldod/QxlDod.h|   44 +-
> > qxldod/buildAll.bat|   31 -
> > qxldod/callVisualStudio.bat|   28 -
> > qxldod/checkWin8Tools.bat  |8 -
> > qxldod/clean.bat   |   12 -
> > qxldod/driver.cpp  |   16 +-
> > qxldod/driver.h|   12 +-
> > qxldod/include/qxl_windows.h   |9 +
> > qxldod/mspace.c| 2437 
> > 
> > qxldod/mspace.cpp  | 2437 
> > 
> > qxldod/qxldod.vcxproj  |  247 ++-
> > qxldod/qxldod.vcxproj.filters  |2 +-
> > qxldod/qxldod.vcxproj.user |   15 +
> > 23 files changed, 3498 insertions(+), 3356 deletions(-)
> > create mode 100644 Tools/vs_cmdline.vbs
> > create mode 100644 Tool

Re: [Spice-devel] I am a China java development engineer, i had achinese keyboard qusetion need to be solved

[David Jaša]

Hi,

just, for information, what app do you use to access VMs over spice, is
it Iordan's aSpice project or something else? What keyboard app do you
use?

How did you find out that "spice and qemu-kvm can't handle chinese
characters"? Did you encounter some qemu crash (then please get the
backtrace and attach it), or were there some errors in qemu log?

Adding more information raises chances that you'll solve your problem.

Best Regards,

David Jaša


On Pá, 2016-12-09 at 09:31 +0800, 史建超 wrote:
>  
> yes， i am  trying to connect to a virtual machine using Spice with an Android 
> pad client(like apple pad,but it is Android 
> 
> system,not ios).
> when i input in chinese with Android pad,i must used  Android system original 
> keyboard,but spice and qemu-kvm can't handle 
> 
> chinese characters ,so the system in the virtual machine can't handle that. 
> I have also tried to use the PC paste interface to achieve the Chinese 
> character transmission on Android keyboard, but the transmission in the past 
> can not be processed, as if being truncated, can only receive a single 
> English character.
>  
>  
> 史建超  Johnny
> 卓朗科技软件事业
> 部
> 手机（Mobile）：18612717308 TROILA TECHNOLOGY
> DEVELOPMENT CO.,LTD
> 
> 
> 座机（Phone）：022-58301500-8048 天津卓朗科技发展有限公司
> 
> 传真（Fax）：022-58301518
> 
> 
> 
> __
> 发件人： Frediano Ziglio 
> 发送时间： 2016-12-08  20:10:46 
> 收件人： 史建超 
> 抄送： spice-devel 
> 主题： Re: [Spice-devel] I am a China java development engineer, i had
> achinese keyboard qusetion need to be solved 
> 
> Which SDK are you referring to? Android?
> 
> Officially we don't provide Android application/library, which website
> are you referring to?
> 
> What's the problem with Android keyboard input you are having?
> 
> I can guess you are trying to connect to a virtual machine using Spice
> and an Android client
> 
> but having problem with input methods. We (as a team) are not that
> used to different input
> 
> methods, can you describe the problem you are having and how do you
> expect it should work?
> 
> 
> 
> Frediano
> 
> 
> 
> 
> __
> From: "史建超" 
> To: "spice-devel" ,
> "spice-devel" 
> Sent: Thursday, December 8, 2016 2:46:11 AM
> Subject: [Spice-devel] I am a China java development
> engineer,i had a chinese keyboard qusetion need to be
> solved
> 
> 
> Hello.
> I am a China java development engineer,  
> My Android mobile project has used spice, 
> but according to the website to download the relevant steps SDK has 4 
> unexpected error resources on the web link is not available, 
> now I need to solve Chinese by Android keyboard input, transmission 
> interface to channel window in the system of virtual desktop, 
> tried before pasting channel, but only the PC end can be realized. 
> Can you give me a full SDK,
> or in the channel to change the keyboard channel interface, do not 
> cut off or read all of the character, to complete the transmission of 
> keyboard input characters. 
> and
> Spice for the Chinese keyboard input in the future whether there is 
> support for the plan? 
>  
> 2016-12-08 
> 
> __
> 
> __
>  
> 史建超  Johnny
> 卓朗科技软件事业
> 部 
>
> 手机（Mobile）：18612717308 TROILA TECHNOLOGY
> DEVELOPMENT CO.,LTD
> 
> 
> 座机（Phone）：022-58301500-8048 天津卓朗科技发展有限
> 公司
> 
> 传真（Fax）：022-58301518
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] mouse mode

[David Jaša]

Hi,

I understand your question only vaguely so I'm writing my best guess
answer. The server mouse mode means that mouse events are sent via
server to the guest OS that in turn renders cursor on it's own. The main
downside is big latency, the mouse pointer position changes with
noticeable delay even on local networks.

Client mouse mode fixes this issue by drawing the cursor right away and
sending it's coordinates to the guest OS. Guest OS however needs to know
that it should not render cursor (to avoid double cursor) and current
pointer position. This is the task for spice agent that receives these
instructions via virtio-serial device.

Linux guests should support client mouse mode right away, if it doesn't
work for you, you have to install and run spice-vdagentd service. On
Windows guests, you have to install virtio-serial driver and spice
vdagent for Windows.
In both cases, spice will use client mouse mode whenever available.

You can also enforce server mouse mode even if all things necessary for
client mouse are in place.

HTH,

David

On Pá, 2016-12-16 at 16:45 +0800, BCFarsight wrote:
> Execue me, you know, Spice supports two mouse modes: server and
> client.
> Now, I want to know the details about server mouse modes. When setting
> server mode about mouse,
> What I need to do any work or change on servers? If you have any
> suggestions, you could tell me.
> Thank you very very much!
> 
> 
> 
> 
>  
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Blurry spice-widget

[David Jaša]

On St, 2016-12-21 at 02:57 +0100, Jason A. Donenfeld wrote:
> Hi folks,
> 
> Since spicy is gtk3, it supports HiDPI scaling of widgets, which is
> great. The menus and icons are all in beautiful proportion, scaled up
> 2x, since I'm on a 192-dpi screen. Yay.
> 
> However, the spice-widget.c view of the Windows 10 VM, which is
> showing what's essentially a bitmap stream, is also scaled 2x. Scaling
> a bitmap 2x makes everything look blurry and awful. The solution is
> for spice-widget.c *not* to scale up 2x. This widget should always be
> at 1x.
> 
> Example: my 15 inch laptop screen has a resolution of 3840x2160.

 
You're actually on 294 dpi screen :)

sqrt(3840**2 + 2160**2) / 15
293.7209560109731

>  All
> icons and menus of Gtk programs are correctly scaled at 2x. At full
> screen, when the spice-widget view is scaled at 2x, it reports to
> Windows 10 over spice that it only is 1920x1080. Windows 10 renders as
> such. Then this 1920x1080 view is scaled up by 2x. This is incorrect
> behavior. The correct behavior would be for the spice-widget to render
> at 1x, and at full screen to report to Windows 10 that it is
> 3840x2160, and then scale the Windows 10 view by 1x (no scaling).
> 
> Is this something that might be possible? Otherwise, spice-gtk won't
> be suitable for HiDPI screens.

This is actually good RFE that can work for different cases both by
extending the normal-DPI guest screen (for older guest systems or apps
that don't need good grahpics - to save bandwidth) or by conveying the
actual DPI to the guest to make all your screen real-estate usable.

David

> Thanks,
> Jason
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Multi Console

[David Jaša]

On Thu, 2017-03-02 at 15:01 +0100, Pavel Grunt wrote:
> On Wed, 2017-03-01 at 10:21 +0100, Christian Rilke wrote:
> > Hi,
> >  
> > first think i have to say is THANK YOU! Spice is the best think
> > happened to the qmeu community since we need graphical consoles.
> >  
> > I just have a short question about multiple console feature. I read
> > that is still experimental? Is this still true? I found out that i
> > need SPICE_DEBUG_ALLOW_MC=1 to get it working.
> > Are there any more concrete plants to improve this feature? We use
> > this daily. The most time we have no trouble but sometimes its
> > buggy. Specially if some change the size of he spice window.
> 
> It is problematic - if one changes the size, the change is
> transferred
> to other users. Sometimes there can be a race - for instance when one
> uses virt-manager as a client - it has a fixed size, so it keeps
> sending a size request matching its size (and possibly overwriting
> request from other clients).
> 
> A solution may be to accept size request only from one client (or
> agent messages in general)

Yeah. It would be good to have receive-only consoles that would allow
e.g. distributed presentations as it is possible with VNC, they should
be also easier to polish than full-featured multiple clients.

David

> 
> 
> If you find some bugs, please report them.
> 
> Thanks,
> Pavel
> 
> >  
> > Cheers,
> > Chris
> > 
> > 
> > Diese E-
> > Mail wurde von einem automatischen Virenscanner überprüft und für v
> > i
> > renfrei befunden.
> > Es kann jedoch nicht ausgeschlossen werden, dass Mails mit noch unb
> > e
> > kannten Viren verseucht sind.
> > IBIX Informationssysteme GmbH übernimmt keine Haftung für Schäden d
> > u
> > rch Virenbefall.
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] gtk client side timeouts

[David Jaša]

Hi,

For the record, I've recently reported bug about pretty much the same
thing:
https://bugzilla.redhat.com/show_bug.cgi?id=1436589

David

On Fri, 2017-03-10 at 10:49 -0600, Jeremy White wrote:
> Hey all,
> 
> We've got an issue with a remote viewer kiosk.  That is, in our
> normal
> mode of operation, if something goes wrong with a client connection
> (e.g. the sessions is killed, server restarted normally), the kiosk
> will
> exit on disconnect, and we get a chance to retry the connection, or
> present the user with a 'server down' style message.
> 
> But in the case of a serious network problem or a server hard power
> cycle (i.e. no TCP FIN packets can flow), our end user behavior is
> not
> ideal - the kiosk appears to hang solid, requiring a power cycle.
> 
> That's because we've got the stock keepalive timeouts, or about 2
> hours
> and 11 minutes, before the client sees the disconnect.
> 
> Now this is a relatively rare occurrence, and arguably a minor
> nuisance,
> but I've been asked to see what it would take to improve the
> situation.
> 
> I looked for past discussions on spice-devel; I only readily found
> discussion of the keepalive parameters on the server side, and it
> looks
> like we take the idle timer down to 10 minutes now, from 2 hours.  I
> didn't find discussion of something similar client side.
> 
> Have we considered tuning them on the spice-gtk client side?
> 
> The attached patch applies a roughly 75 second timeout for me; is
> this
> something that would be viable to add to the gtk client, even if only
> as
> an option?
> 
> Cheers,
> 
> Jeremy
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [RFC spice-gtk 2/5] qos: introduce quality of service to channels

[David Jaša]

When we have overall notion of available bandwidth and the bandwidth is
constrained, we should be able to adjust Opus settings accordingly:
https://opus-codec.org/examples/#bitrate-scalability

The QoS may be as important for uplinks as is for downlinks because
many last-mile connections have asymmetrical bandwidth/latency/jitter.

David

On Fri, 2017-04-07 at 15:19 +0200, Victor Toso wrote:
> From: Victor Toso 
> 
> The QOS over spice channels is splitted in a few patches in order to
> easy review.
> 
> This patch introduces 4 new functions that are only internally
> exposed
> to SpiceChannels, they are:
> 
> * spice_session_qos_can_channel_write()
> * spice_session_qos_can_channel_read()
> * spice_session_qos_channel_has_write_nbytes()
> * spice_session_qos_channel_has_read_nbytes()
> 
> Prior to each read or write, the SpiceChannel should query if it is
> allowed to perform the IO with spice_session_qos_can_channel_write
> (or
> read).
> 
> After each successful read or write, the SpiceChannel should inform
> the QOS system how many bytes it has write/read.
> 
> These functions should perform as fast as possible to not introduce
> delays in each IO.
> 
> The logic behind QOS will be introduced in follow up patches.
> 
> Related: https://bugs.freedesktop.org/show_bug.cgi?id=96598
> 
> Signed-off-by: Victor Toso 
> ---
>  src/spice-channel.c  |  28 
>  src/spice-option.c   |   5 ++
>  src/spice-session-priv.h |   5 ++
>  src/spice-session.c  | 117
> +++
>  4 files changed, 155 insertions(+)
> 
> diff --git a/src/spice-channel.c b/src/spice-channel.c
> index b3fd521..f49950d 100644
> --- a/src/spice-channel.c
> +++ b/src/spice-channel.c
> @@ -837,6 +837,13 @@ static gint
> spice_channel_flush_wire_nonblocking(SpiceChannel *channel,
>  return ret;
>  }
>  
> +static gboolean wait_qos_can_flush(gpointer data)
> +{
> +SpiceChannel *channel = SPICE_CHANNEL(data);
> +SpiceChannelPrivate *c = channel->priv;
> +return spice_session_qos_can_channel_write(c->session, channel);
> +}
> +
>  /*
>   * Write all 'data' of length 'datalen' bytes out to
>   * the wire
> @@ -856,6 +863,12 @@ static void
> spice_channel_flush_wire(SpiceChannel *channel,
>  
>  if (c->has_error) return;
>  
> +if (!g_coroutine_condition_wait(&c->coroutine,
> wait_qos_can_flush, channel)) {
> +CHANNEL_DEBUG(channel, "Closing the channel:
> spice_channel_flush failed qos");
> +c->has_error = TRUE;
> +return;
> +}
> +
>  ret = spice_channel_flush_wire_nonblocking(channel,
> ptr+offset, datalen-offset, &cond);
>  if (ret == -1) {
>  if (cond != 0) {
> @@ -875,6 +888,7 @@ static void spice_channel_flush_wire(SpiceChannel
> *channel,
>  }
>  offset += ret;
>  c->total_write_bytes += ret;
> +spice_session_qos_channel_has_write_nbytes(c->session,
> channel, ret);
>  }
>  }
>  
> @@ -1063,6 +1077,13 @@ static int
> spice_channel_read_wire_nonblocking(SpiceChannel *channel,
>  return ret;
>  }
>  
> +static gboolean wait_qos_can_read(gpointer data)
> +{
> +SpiceChannel *channel = SPICE_CHANNEL(data);
> +SpiceChannelPrivate *c = channel->priv;
> +return spice_session_qos_can_channel_read(c->session, channel);
> +}
> +
>  /*
>   * Read at least 1 more byte of data straight off the wire
>   * into the requested buffer.
> @@ -1081,6 +1102,12 @@ static int
> spice_channel_read_wire(SpiceChannel *channel, void *data, size_t len
>  return 0;
>  }
>  
> +if (!g_coroutine_condition_wait(&c->coroutine,
> wait_qos_can_read, channel)) {
> +CHANNEL_DEBUG(channel, "Closing the channel:
> spice_channel_read failed qos");
> +c->has_error = TRUE;
> +return 0;
> +}
> +
>  ret = spice_channel_read_wire_nonblocking(channel, data,
> len, &cond);
>  
>  if (ret == -1) {
> @@ -1099,6 +1126,7 @@ static int spice_channel_read_wire(SpiceChannel
> *channel, void *data, size_t len
>  return 0;
>  }
>  
> +spice_session_qos_channel_has_read_nbytes(c->session,
> channel, ret);
>  return ret;
>  }
>  }
> diff --git a/src/spice-option.c b/src/spice-option.c
> index c04e978..bf81dea 100644
> --- a/src/spice-option.c
> +++ b/src/spice-option.c
> @@ -36,6 +36,7 @@ static char *usbredir_redirect_on_connect = NULL;
>  static gboolean smartcard = FALSE;
>  static gboolean disable_audio = FALSE;
>  static gboolean disable_usbredir = FALSE;
> +static gboolean disable_qos = FALSE;
>  static gint cache_size = 0;
>  static gint glz_window_size = 0;
>  static gchar *secure_channels = NULL;
> @@ -203,6 +204,8 @@ GOptionGroup* spice_get_option_group(void)
>    N_("Subject of the host certificate (field=value pairs
> separated by commas)"), N_("") },
>  { "spice-disable-audio", '\0', 0, G_OPTION_ARG_NONE,
> &disable_audio,
>    

Re: [Spice-devel] Feature suggestion: Port tunneling between VM & client over spice-channel

[David Jaša]

Hi Boris,

On Wed, 2018-11-14 at 11:38 +0900, Boris Morozov wrote:
> Hello, dear friends. I would like a share idea with you about new feature. 
> Please forgive me if i wrong.
> 
> Current approach to publish ports from virtual machine is connecting it to 
> network by network adapter.
> 
> In this case administrator should to write:
> - Routes
> - DNS-records
> - Firewall rules
> 
> In final result: 
> - Virtual machine start going to Internet from host local or ISP network.
> - Virtual machine user can attack gateways and peer nodes in host network.
> - Virtual machine user can attack global sites, services and leave host IP it 
> will raise problems with owners of attacked sites and services, authorities.
> - Virtual machine user can download illegal or forbidden content and leave 
> host IP it will raise problems with authorities.
> - Virtual machine can be attacked from other nodes in host network and 
> internet.
> Internet gateway on host network should open extra ports to perform access to 
> virtual machine.
> - Some computing power of host is begin to spent on NIC and network 
> emulation. 
> - Some time of administrator was spent to configuring and testing routing, 
> dns, firewall.

All of these are standard and both software and people are used to it.
I dare say that it's actually a feature in most cases as administrators
need to keep track of network metadata. Anyway...

> 
> To avoid this responibility and performance problems and reduce time on 
> configuration when public access to virtual machine not needed it's better 
> way to tunnel ports on virtual machine from guest and vice-versa by SPICE.
> 

You're introducing extra latency and limitation on network bandwidth
when connecting to outside networks as network traffic from the VM has
to hairpin through client computer.

> In case of port tunneling over SPICE 
> 
> 1. In virtual machine running services and they opened ports (HTTP, SSH for 
> example) on localhost (127.0.0.1). 
> 2. Spice guest agent in virtual machine open client-port and become ready to 
> connect to services ports from client-port and redirect data to spice 
> channel. 
> 3. In other end of spice channel on client spice client open ports for 
> listening incoming connections on client localhost (127.0.0.1). 
> 4. Client user connect to tunneled ports on client-side localhost and start 
> working with tunneled ports as with local ones. 
> 5. Spice client & guest agent perform traffic redirection.
> 
> As we can see offered approach is more simple. It can't be used against 
> traditional approach in public access but in personal access it's look 
> better. Also it's looks possible to tunnel not only localhost ports on 
> virtual machine and others nodes ones if network is working. 
> 
> Use cases:
> - Web-browsing virtual machine sites on client machine
> - Web-sites, network services (daemons) development
> - Internet access in virtual machine via proxies on client (TOR, VPN, SOCKS, 
> HTTP)
> - Monitoring (getting access to API and dashboards) of various services: 
> printers, miners, solar power chargers, UPS and others. 
> - File transfer between client and virtual machine via FTP, SFTP, HTTP
> - Stream transfer between client and virtual machine video, audio and others.
> - VDI-hosting (Isolated preinstalled VM without NIC)
> 
> 

I think that you could use spiceport channel as a building block with
TUN/TAP device attached to virtio device inside the guest. On client
side, you'd have to write the connector however (similarly to file
transfer or webdav features).

Cheers,

David

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-server] sound: Use bool type coherently

[David Jaša]

On Wed, 2017-04-19 at 16:51 +0100, Frediano Ziglio wrote:
> Many function already used bool as boolean type.
> Change last gboolean occurrencies and values.

Probably already merged, but: "occurrences"

> 
> Signed-off-by: Frediano Ziglio 
> ---
>  server/sound.c | 70 +---
> --
>  1 file changed, 35 insertions(+), 35 deletions(-)
> 
> diff --git a/server/sound.c b/server/sound.c
> index 72dfefb..0d8e154 100644
> --- a/server/sound.c
> +++ b/server/sound.c
> @@ -86,8 +86,8 @@ GType snd_channel_client_get_type(void)
> G_GNUC_CONST;
>  struct SndChannelClient {
>  RedChannelClient parent;
>  
> -gboolean active;
> -gboolean client_active;
> +bool active;
> +bool client_active;
>  
>  uint32_t command;
>  
> @@ -117,7 +117,7 @@ struct AudioFrame {
>  PlaybackChannelClient *client;
>  AudioFrame *next;
>  AudioFrameContainer *container;
> -gboolean allocated;
> +bool allocated;
>  };
>  
>  #define NUM_AUDIO_FRAMES 3
> @@ -169,7 +169,7 @@ struct SndChannel {
>  SndChannelClient *connection; /* Only one client is supported */
>  SndChannel *next; /* For the global SndChannel list */
>  
> -gboolean active;
> +bool active;
>  SpiceVolumeState volume;
>  uint32_t frequency;
>  };
> @@ -278,7 +278,7 @@ static bool
> snd_record_handle_write(RecordChannelClient *record_client, size_t s
>  uint32_t now;
>  
>  if (!record_client) {
> -return FALSE;
> +return false;
>  }
>  
>  packet = (SpiceMsgcRecordPacket *)message;
> @@ -292,7 +292,7 @@ static bool
> snd_record_handle_write(RecordChannelClient *record_client, size_t s
>  decode_size = sizeof(record_client->decode_buf);
>  if (snd_codec_decode(record_client->codec, packet->data,
> packet->data_size,
>  record_client->decode_buf, &decode_size) !=
> SND_CODEC_OK)
> -return FALSE;
> +return false;
>  data = (uint32_t *) record_client->decode_buf;
>  size = decode_size >> 2;
>  }
> @@ -311,7 +311,7 @@ static bool
> snd_record_handle_write(RecordChannelClient *record_client, size_t s
>  if (record_client->write_pos - record_client->read_pos >
> RECORD_SAMPLES_SIZE) {
>  record_client->read_pos = record_client->write_pos -
> RECORD_SAMPLES_SIZE;
>  }
> -return TRUE;
> +return true;
>  }
>  
>  static
> @@ -349,12 +349,12 @@ record_channel_handle_message(RedChannelClient
> *rcc, uint16_t type, uint32_t siz
>  record_client->mode = mode->mode;
>  } else {
>  spice_printerr("create decoder failed");
> -return FALSE;
> +return false;
>  }
>  }
>  else {
>  spice_printerr("unsupported mode %d", record_client-
> >mode);
> -return FALSE;
> +return false;
>  }
>  }
>  else
> @@ -373,7 +373,7 @@ record_channel_handle_message(RedChannelClient
> *rcc, uint16_t type, uint32_t siz
>  default:
>  return red_channel_client_handle_message(rcc, type, size,
> message);
>  }
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_channel_send_migrate(SndChannelClient *client)
> @@ -387,7 +387,7 @@ static bool
> snd_channel_send_migrate(SndChannelClient *client)
>  spice_marshall_msg_migrate(m, &migrate);
>  
>  red_channel_client_begin_send_message(rcc);
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_playback_send_migrate(PlaybackChannelClient *client)
> @@ -405,7 +405,7 @@ static bool snd_send_volume(SndChannelClient
> *client, uint32_t cap, int msg)
>  SpiceVolumeState *st = &channel->volume;
>  
>  if (!red_channel_client_test_remote_cap(rcc, cap)) {
> -return FALSE;
> +return false;
>  }
>  
>  vol = alloca(sizeof (SpiceMsgAudioVolume) +
> @@ -418,7 +418,7 @@ static bool snd_send_volume(SndChannelClient
> *client, uint32_t cap, int msg)
>  spice_marshall_SpiceMsgAudioVolume(m, vol);
>  
>  red_channel_client_begin_send_message(rcc);
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_playback_send_volume(PlaybackChannelClient
> *playback_client)
> @@ -436,7 +436,7 @@ static bool snd_send_mute(SndChannelClient
> *client, uint32_t cap, int msg)
>  SpiceVolumeState *st = &channel->volume;
>  
>  if (!red_channel_client_test_remote_cap(rcc, cap)) {
> -return FALSE;
> +return false;
>  }
>  
>  red_channel_client_init_send_data(rcc, msg);
> @@ -444,7 +444,7 @@ static bool snd_send_mute(SndChannelClient
> *client, uint32_t cap, int msg)
>  spice_marshall_SpiceMsgAudioMute(m, &mute);
>  
>  red_channel_client_begin_send_message(rcc);
> -return TRUE;
> +return true;
>  }
>  
>  static bool snd_playback_send_mute(PlaybackChannelClient
> *playback_client)
> @@ -465,7 +465,7 @@ s

Re: [Spice-devel] Ultra Wide resolution

[David Jaša]

On Mon, 2017-05-22 at 11:34 +0300, Uri Lublin wrote:
> On 05/22/2017 10:59 AM, Pavel Grunt wrote:
> > Hi,
> > 
> > On Sat, 2017-05-20 at 20:18 -0300, guidu...@gmail.com wrote:
> > > Hi,
> > > 
> > > I have an ultra wide monitor that has max resolution of
> > > 2560x1080. I
> > > use KVM + Spice QXL on all VMs. Unfortunately, I cannot use this
> > > resolution on my virtual machines. Since I can reach this
> > > resolution
> > > if
> > > I use GPU passthrough, I believe the limitation is in spice.
> > > 
> > > If my suspicion is correct, how do I add this resolution?
> > 
> > you must install the latest spice vdagent and set qxl memory
> > parameters.
> > 
> > For more details see:
> > https://www.spice-space.org/multiple-monitors.html
> > 
> > Pavel
> 
> 
> Hi,
> 
> I just want to add that by default (64 MB ram (Bar0)
> and 16MB vgamem) this resolution should be supported
> and that if you change to fullscreen mode (and
> spice-vdagent is running on the guest) then Spice
> should automatically change the guest resolution to fit
> your monitor.
> 
> Uri.
> 

Exactly, spice in default settings is limited to 2560x1600 or 2048x2048
resolution. If 2560x1080 doesn't work, something is wrong.

David

> > 
> > > 
> > > Thank you,
> > > 
> > > Carlos
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Windows 10: Smartcard is not redirected

[David Jaša]

Hi Oscar,
spice client uses on Windows also NSS library to access smart cards, so
you need to tell NSS where to look for library that provides pkcs#11
interface (or "smart card middleware") for your smart card. Once you
know the .dll, you can create the nssdb and add the library there:
mkdir %PROGRAMFILES%\nssdb%PROGRAMFILES%\VirtViewer*\bin\certutil -d
%PROGRAMFILES%\nssdb -N%PROGRAMFILES%\VirtViewer*\bin\modutil -dbdir
%PROGRAMFILES%\nssdb -add "my smartcard middleware" -libfile
C:\...\my_middleware_pkcs11_library.dll
With these steps taken, remote-viewer should pick you smartcard and
expose it in the guest.
HTH,
David

On Mon, 2017-05-08 at 13:48 +0200, Oscar Segarra wrote:
> Hi, 
> In my environment I have a Windows 10 guest and a Windows 10 client.
> 
> I have configured smartcard as it is suggested in documentation:
> 
> https://www.spice-space.org/spice-user-manual.html
> 
> 
> 
>   
> 
> I can see on virt-manager the controller and the devices correctly
> added. Even in guest Windows 10 appears the ccid smartcard reader
> device.
> 
> I launch my remote-viewer.exe with the following parameters:
> 
> remote-viewer.exe -f --spice-smartcard
> 
> But when I connect my smartcard in the client, it is not redirected
> to the guest.
> 
> Is there any documentation about how to redirect my smartcard with
> authentication/sign certificate?
> 
> Thanks a lot.
>  
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Windows 10: Smartcard is not redirected

[David Jaša]

On Thu, 2017-07-20 at 15:42 +0200, David Jaša wrote:
> Hi Oscar,
> 
> spice client uses on Windows also NSS library to access smart cards,
> so you need to tell NSS where to look for library that provides
> pkcs#11 interface (or "smart card middleware") for your smart card.
> Once you know the .dll, you can create the nssdb and add the library
> there:
> 
> mkdir %PROGRAMFILES%\nssdb%PROGRAMFILES%\VirtViewer*\bin\certutil -d
> %PROGRAMFILES%\nssdb -N%PROGRAMFILES%\VirtViewer*\bin\modutil -dbdir
> %PROGRAMFILES%\nssdb -add "my smartcard middleware" -libfile
> C:\...\my_middleware_pkcs11_library.dll

The path for nssdb should be actually %PROGRAMDATA%\nssdb, so on most
systems C:\ProgramData\nssdb. Sorry for the mistake.
David
> With these steps taken, remote-viewer should pick you smartcard and
> expose it in the guest.
> 
> HTH,
> 
> David
> 
> 
> On Mon, 2017-05-08 at 13:48 +0200, Oscar Segarra wrote:
> > Hi, 
> > In my environment I have a Windows 10 guest and a Windows 10
> > client.
> > 
> > I have configured smartcard as it is suggested in documentation:
> > 
> > https://www.spice-space.org/spice-user-manual.html
> > 
> > 
> > 
> >   
> > 
> > I can see on virt-manager the controller and the devices correctly
> > added. Even in guest Windows 10 appears the ccid smartcard reader
> > device.
> > 
> > I launch my remote-viewer.exe with the following parameters:
> > 
> > remote-viewer.exe -f --spice-smartcard
> > 
> > But when I connect my smartcard in the client, it is not redirected
> > to the guest.
> > 
> > Is there any documentation about how to redirect my smartcard with
> > authentication/sign certificate?
> > 
> > Thanks a lot.
> >  
> > 
> > 
> > 
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk PATCH v2] Ability to release the cursor with a keyboard shortcut

[David Jaša]

On Čt, 2014-10-09 at 05:54 -0400, Marc-André Lureau wrote:
> Hi,
> 
> - Original Message -
> > The cursor is grabbed/ungrabbed automatically by spice-gtk,
> > this patch allows releasing the cursor in the client mouse mode
> > with a keyboard shortcut.
> 
> Could you describe the issue you have with the current behaviour, or the use 
> case?

Keyboard navigation. Work in guest -> release cursor -> alt-tab to a
different client window.

David

> 
> thanks
>  
> > ---
> > v2:
> >  - fix crash on vm shutdown
> > 
> >  gtk/spice-widget-priv.h |  1 +
> >  gtk/spice-widget.c  | 68
> >  +
> >  2 files changed, 42 insertions(+), 27 deletions(-)
> > 
> > diff --git a/gtk/spice-widget-priv.h b/gtk/spice-widget-priv.h
> > index 597ce10..c5960bd 100644
> > --- a/gtk/spice-widget-priv.h
> > +++ b/gtk/spice-widget-priv.h
> > @@ -92,6 +92,7 @@ struct _SpiceDisplayPrivate {
> >  enum SpiceMouseMode mouse_mode;
> >  int mouse_grab_active;
> >  boolmouse_have_pointer;
> > +gbooleancursor_released;
> >  GdkCursor   *mouse_cursor;
> >  GdkPixbuf   *mouse_pixbuf;
> >  GdkPointmouse_hotspot;
> > diff --git a/gtk/spice-widget.c b/gtk/spice-widget.c
> > index 1220030..5a14236 100644
> > --- a/gtk/spice-widget.c
> > +++ b/gtk/spice-widget.c
> > @@ -916,8 +916,11 @@ static void update_mouse_pointer(SpiceDisplay *display)
> >  
> >  switch (d->mouse_mode) {
> >  case SPICE_MOUSE_MODE_CLIENT:
> > -if (gdk_window_get_cursor(window) != d->mouse_cursor)
> > +if (d->cursor_released) {
> > +gdk_window_set_cursor(window, NULL);
> > +} else if (gdk_window_get_cursor(window) != d->mouse_cursor) {
> >  gdk_window_set_cursor(window, d->mouse_cursor);
> > +}
> >  break;
> >  case SPICE_MOUSE_MODE_SERVER:
> >  if (gdk_window_get_cursor(window) != NULL)
> > @@ -940,19 +943,21 @@ static void try_mouse_grab(SpiceDisplay *display)
> >  
> >  if (!d->mouse_have_pointer)
> >  return;
> > -if (!d->keyboard_have_focus)
> > -return;
> >  
> >  if (!d->mouse_grab_enable)
> >  return;
> > -if (d->mouse_mode != SPICE_MOUSE_MODE_SERVER)
> > -return;
> >  if (d->mouse_grab_active)
> >  return;
> >  
> > -if (do_pointer_grab(display) != GDK_GRAB_SUCCESS)
> > -return;
> > -
> > +if (d->mouse_mode == SPICE_MOUSE_MODE_SERVER) {
> > +if (do_pointer_grab(display) != GDK_GRAB_SUCCESS)
> > +return;
> > +} else {
> > +try_keyboard_grab(display);
> > +d->mouse_grab_active = true;
> > +g_signal_emit(display, signals[SPICE_DISPLAY_MOUSE_GRAB], 0, true);
> > +}
> > +d->cursor_released = false;
> >  d->mouse_last_x = -1;
> >  d->mouse_last_y = -1;
> >  }
> > @@ -996,13 +1001,14 @@ static void try_mouse_ungrab(SpiceDisplay *display)
> >  if (!d->mouse_grab_active)
> >  return;
> >  
> > -gdk_pointer_ungrab(GDK_CURRENT_TIME);
> >  gtk_grab_remove(GTK_WIDGET(display));
> > +if (d->mouse_mode == SPICE_MOUSE_MODE_SERVER &&
> > gdk_pointer_is_grabbed()) {
> > +gdk_pointer_ungrab(GDK_CURRENT_TIME);
> >  #ifdef G_OS_WIN32
> > -ClipCursor(NULL);
> > +ClipCursor(NULL);
> >  #endif
> > -set_mouse_accel(display, TRUE);
> > -
> > +set_mouse_accel(display, TRUE);
> > +}
> >  d->mouse_grab_active = false;
> >  
> >  g_signal_emit(display, signals[SPICE_DISPLAY_MOUSE_GRAB], 0, false);
> > @@ -1308,11 +1314,11 @@ static gboolean key_event(GtkWidget *widget,
> > GdkEventKey *key)
> >  if (check_for_grab_key(display, key->type, key->keyval)) {
> >  g_signal_emit(widget, signals[SPICE_DISPLAY_GRAB_KEY_PRESSED], 0);
> >  
> > -if (d->mouse_mode == SPICE_MOUSE_MODE_SERVER) {
> > -if (d->mouse_grab_active)
> > -try_mouse_ungrab(display);
> > -else
> > -try_mouse_grab(display);
> > +if (d->mouse_grab_active) {
> > +spice_display_mouse_ungrab(display);
> > +try_keyboard_ungrab(display);
> > +} else {
> > +try_mouse_grab(display);
> >  }
> >  }
> >  
> > @@ -1402,7 +1408,10 @@ static gboolean enter_event(GtkWidget *widget,
> > GdkEventCrossing *crossing G_GNUC
> >  SPICE_DEBUG("%s", __FUNCTION__);
> >  
> >  d->mouse_have_pointer = true;
> > +if (d->cursor_released)
> > +return true;
> >  try_keyboard_grab(display);
> > +try_mouse_grab(display);
> >  update_display(display);
> >  
> >  return true;
> > @@ -1415,11 +1424,9 @@ static gboolean leave_event(GtkWidget *widget,
> > GdkEventCrossing *crossing G_GNUC
> >  
> >  SPICE_DEBUG("%s", __FUNCTION__);
> >  
> > -if (d->mouse_grab_active)
> > -return true;
> > -
> >  d->mouse_have_point

Re: [Spice-devel] spice ssl live migration

[David Jaša]

Hi,

On St, 2014-10-22 at 12:03 +0800, yao xu wrote:
> Hi all!
> 
> 
> I am using spice and ovirt(a old version). 
> 
> 
> when  I use remote-viewer with correct ssl certifacate to connect the
> vm , and then live migrate the vm to another host ,

The certificates for both hosts have to be issued by the same CA.

> 
> 
> remote-viewer is dead .I must reconnect the vm .
> 
> 
> Can I use remote-viewer continuous when the vm is migrating?  How to
> configure the ssl certificate ?

Yes, you can. Configuration may be different based on the way you launch
the VMs: e.g. when you use oVirt/RHEV, it will take care of correct TLS
setup automatically. Libvirt can do most of the tasks for you but you
still have to set up certificates correctly yourself and when you use
plain qemu, you have to feed correct configuration even to qemu monitor.

So: how do you manage your VMs?

David

> 
> 
> Thank you .
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] snooping on usb passthrough

[David Jaša]

On Po, 2014-11-17 at 10:19 -0500, David Mansfield wrote:
> Hi All,
> 
> Can anyone point me in the right direction for snooping on USB messages 
> going to a windows VM either from host device passthrough or spice usb 
> passthrough?
> 
> I'd like to reverse engineer some USB speakerphone HID stuff.
> 

CCing Hans

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice ssl live migration

[David Jaša]

On St, 2014-11-26 at 15:02 +0800, yao xu wrote:
> Thanks David .
> 
> 
>I use ovirt to manage my vms , version is about 3.1, my workmates
> added some code .
> 

So the issue you see is most likely ovirt bug. The easiest way should be
to put host into maintenance, delete spice certificates and keys
from /etc/pki/vdsm/libvirt-spice (IIRC, the exact directory may be
different) and "reinstall host" again in ovirt webadmin. During
"reinstallation", the new valid certificates should be created.

BTW why are you staying on ovirt 3.1? That version is long obsolete, two
years and 4 releases passed since then...

> 
>In our environment , we can't migrate vm continuosly. Is libvirt or
> qemu should do some configuration ? 

ovirt should configure both for you. The migration should work with no
client disconnection no matter how many times you migrated before.

David

>
>my libvirt version is 1.2.8 , qemu's version is 1.7.1
> 
> 
> I do appreciate your help! guys.
>
> 
> 
> 
> 2014-10-22 21:05 GMT+08:00 David Jaša :
> Hi,
> 
> On St, 2014-10-22 at 12:03 +0800, yao xu wrote:
> > Hi all!
> >
> >
> > I am using spice and ovirt(a old version).
> >
> >
> > when  I use remote-viewer with correct ssl certifacate to
> connect the
> > vm , and then live migrate the vm to another host ,
> 
> The certificates for both hosts have to be issued by the same
> CA.
> 
> >
> >
> > remote-viewer is dead .I must reconnect the vm .
> >
> >
> > Can I use remote-viewer continuous when the vm is migrating?
> How to
> > configure the ssl certificate ?
> 
> Yes, you can. Configuration may be different based on the way
> you launch
> the VMs: e.g. when you use oVirt/RHEV, it will take care of
> correct TLS
> setup automatically. Libvirt can do most of the tasks for you
> but you
> still have to set up certificates correctly yourself and when
> you use
> plain qemu, you have to feed correct configuration even to
> qemu monitor.
> 
> So: how do you manage your VMs?
> 
> David
> 
> >
> >
> > Thank you .
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Floating windows?

[David Jaša]

On Ne, 2014-11-16 at 16:25 +0100, Fabiano Fidêncio wrote:
> Hey Todd,
> 
> On Sun, Nov 16, 2014 at 5:48 AM, ToddAndMargo  wrote:
> > Hi,
> >
> > Please excuse if this is dumb question.  I have seen the way
> > Parallels operates on Mac.  Instead of opening up a window
> > with the whole of Windows inside, Parallels will float just
> > the application in the host's desktop.  Makes for a lot
> > less clutter.
> >
> > Is there anything like this in our future?  (I know
> > you can do this with X11 and SSH on Linux VM's,
> > but it is slow and Windows doesn't support it.)
> >
> 
> It's something that I'd love to see implemented. Although, for now
> (talking about short-term future), I don't see myself work on this
> (but I cannot speak for the others working on Spice).
> 

IIRC what virtualbox uses to achieve this feature is to draw all windows
in the one big desktop and cut them out of it - quite a hack if indeed
true.

I think that solving this problem well would need cooperation with
window manager and composition manager and it would also allow host of
optimizations in normal mode with guest root windows: way less traffic
on WM animations, no redraws on window movement, no discard & re-send of
graphics on pop-up & dismiss, scaling down of windows server-side for
windows previes (gnome-shell's overview and windows aero alt-tab) and so
on...

David

> > Many thanks,
> > -T
> >
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> 
> Best Regards,


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [ovirt-users] I have a question about the spice client.

[David Jaša]

Hi,

What is hangul key? Do I understand correctly that linux client works OK
but windows client behaves incorrectly?

David

On Po, 2015-01-12 at 15:51 +0900, jaemin baek wrote:
> hi, 
> 
> i'm korean
> 
> 
> I have a question about the spice client.
> 
> 
> 
> My spice client connect to VDI > Windows 7 VDI
> 
> 
> input key ---> Korea keyboard(103/106 key) + hangul key   ---> windows
> 7 IME
> 
> 
> but...
> 
> 
> input key ---> Korea keyboard(103/106 key) + hangul key --> hangul key
> exchanged ---> Alt key
> 
> 
> Why??
> 
> 
> linux spice client Hangul key OK.
> 
> 
> but windows spice client Hangul key ---> Alt key...
> 
> 
> 
> 
> Hangul key scancode = 0x38
> Alt key scancode = 0x38
> 
> 
> WHY?? 
> 
> 
> Help me Thank you.
> 
> 
> 
> ___
> Users mailing list
> us...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [virt-tools] Feature Request - Secure clipboard

[David Jaša]

Wouldn't it be possible to achieve something very close with "lazy"
transfer of C&P data only after paste event? In that case, when you'd
copy something in source VM, it would be available in there and in
client but it would get copied to guest's clipboard only if you switch
to there and paste there using ctrl+V.

David

On Ne, 2015-04-26 at 17:52 +0200, gra...@ruggedinbox.com wrote:
> A secure clipboard is nice to have becuase there's no tradeoff between
> convenience and safety. A vm can read the global clipboard only when you
> want it. The Xen based Qubes has it and I don't see why KVM's spice and
> libvirt can't. Here is how they did it:
> 
> 
> slide 10 from
> 
> https://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_2014_Qubes_Tutorial.pdf
> 
> Challenge: copy clipboard from VM “Alice” to VM “Bob”, don’t let VM
> “Mallory” to learn
> its content in the meantime
> 
> Solved by introducing Qubes “global clipboard” to/from which copy/paste is
> explicitly
> controlled by the user (Ctrl-Shift-C, Ctrl-Shift-V)
> 
> Requires 4 stages:
> Ctrl-C (in the source VM)
> Ctrl-Shift-C (tells Qubes: copy this VM buffer into global clipboard)
> Ctrl-Shift-V (in the destination VM: tells Qubes: make global clipboard
> available to this VM)
> Ctrl-V (in the destination VM)
> Ctrl-Shift-C/V cannot be injected by VMs (unspoofable key combo).
> 
> In practice almost as fast as traditional 2-stage copy-paste (don’t freak
> out! ;)
> 
> 
> More technical explanation
> 
> https://www.qubes-os.org/doc/CopyPaste/
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] USB redirection

[David Jaša]

On Ne, 2015-05-03 at 21:33 +, Klaus Hochlehnert wrote:
> Hi,
> 
>  
> 
> is it actually possible to connect the spice USB redirection to an
> USB3.0 controller instead of the ICH9 USB2.0?

It is. I didn't see any problem with spice usage, I however noticed
smartcard not working with nec-xhci controller:
https://bugzilla.redhat.com/show_bug.cgi?id=1211970

> 
> Not sure, but I would assume less CPU usage?
> 

I didn't focus on CPU so I can't really tell.

David

>  
> 
> Thanks, Klaus
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] vdagent service is not running

[David Jaša]

Zdravím,

Please have a look at Device manager if virtio-serial driver is
installed and working. vdservice exits when it can't open the spice
virtio port.

David


On St, 2015-05-06 at 12:03 +0200, Michal Suchanek wrote:
> Hello,
> 
> I installed the spice guest tools on Windows 7 - the exe installer from
> spice-space.org.
> 
> The vdagent service is not running. When I start it it stops.
> 
> How do I debug this?
> 
> Thanks
> 
> Michal
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] about mouse on multi monitor for you help

[David Jaša]

On Po, 2015-05-11 at 15:51 +0300, Uri Lublin wrote:
> On 05/08/2015 09:05 AM, 张阳 wrote:
> > hi spice admin:
> > I am a spice user form china.
> > Now I have a problem ,when we set multi monitor for windows xp VM by
> > spice, the mouse on the VM's second monitor cann't be ctrl or moving or
> > click.all operation on the second monitor will be  take effect  on the
> > first moitor.
> > what should i do about this problem?
> > thank you for your help~
> 
> Hi,
> 
> Is spice vdagent installed on your guest ?
> 
> Uri.

I see this behaviour for quite some time already. Ctrl modifier isn't
passed on to the guest when the mouse cursor is outside of spice canvas.
You won't notice in single-monitor fullscreen guest but in 张阳's case
or just when using plain windowed guest, it's pretty noticeable...

David

> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Cac redirection through spice client

[David Jaša]

Thomas,

I don't understand your issue/question. I'll write a few notes about
smart card sharing architecture in spice so that we're at the same page
regarding terminology:

  * in Client system, remote-viewer accesses the smart card using
pkcs#11 module (library) that has to be registered in NSS
library database
  * the data is transferred over the network to spice-server which
transfers them to qemu which shares them via emulated smart card
reader. The emulated card reader needs the drivers (in the
Windows guest) and the card itself may require drivers as well
  * if your client OS and guest OS are of the same kind, the
configuration required in guest OS to make card accessible for
programs is the same as in your client OS

What I don't understand are your mentions of spice client complaining
about incorrect drivers - I'd expect such messages being produced by
Windows running in the guest. Would you mind sharing a screenshot, or
describing your setup in greater detail (or the steps you did so far)?

David

On Čt, 2015-05-14 at 05:42 -0400, Thomas Foster wrote:

> Can somebody help me understand where to put the driver for Cac
> redirection for the spice client?
> 
> The problem:  When placing cac in card reader, spice client recognizes
> the card but states the drivers were not installed correctly.  In
> windows there is the usbccid cac reader (which works with rdp) and the
> spice redirected cac reader (which shows up as a device without the
> drivers).  I have attempted to install the drivers on the windows 7 vm
> to no avail.  So, I was wondering does the driver have to be installed
> on the system I am running the spice client?
> 
> Thanks in advance!
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Cac redirection through spice client

[David Jaša]

On Út, 2015-05-19 at 15:59 +0200, David Jaša wrote:
> On Út, 2015-05-19 at 09:00 -0400, Thomas Foster wrote:
> > David,
> > 
> > While using the spice client have you put your cac into your local
> > reader?  If so, we're you able to use it?  I ask because if you look
> > at my screenshots from my last email I get the same usb device
> > (usbccid), but I also get an extra device that is a problem.
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> Hm, I think I start understanding your situation: you're using linux
> client (CentOS 7?), Windows 7 guest and the smart card doesn't work
> for you. When you write "drivers in spice client" you actually mean
> drivers for client OS. That's card-dependent. You need to have a
> "smart card middleware" installed in the system and registered in nss,
> e.g.:
> 
> $ modutil -dbdir /etc/pki/nssdb -list
> 
> Listing of PKCS #11 Modules
> ---
>   1. NSS Internal PKCS #11 Module
>slots: 2 slots attached
>   status: loaded
> 
>slot: NSS Internal Cryptographic Services
>   token: NSS Generic Crypto Services
> 
>slot: NSS User Private Key and Certificate Services
>   token: NSS Certificate DB
> 
>   2. CoolKey PKCS #11 Module
>   library name: libcoolkeypk11.so
>slots: 1 slot attached
>   status: loaded
> 
>slot: Gemalto PC Twin Reader 00 00
>   token: spice qe
> 
>   3. p11-kit
>   library name: /usr/lib64/pkcs11/p11-kit-trust.so
>slots: 2 slots attached
>   status: loaded
> 
>slot: /etc/pki/ca-trust/source
>   token: System Trust
> 
>slot: /usr/share/pki/ca-trust-source
>   token: Default Trust
> ---
> 
> Module 2. is the one that provides my smartcard, "slot: Gemalto PC
> Twin Reader 00 00" is my physical card reader, . Coolkey is not
> however officially sanctioned in windows (although unofficial builds
> exist) 

So official builds exist as well but you'd need a Red Hat Certificate
System subscription in order to access them:
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Managing_Smart_Cards_with_the_Enterprise_Security_Client/install-windows.html

David

> so if you intend to use the card in Windows, you'll need a different
> middleware for it and possibly, you'll need to register it to nss by
> hand:
> 
> # modutil -dbdir /etc/pki/nssdb -add "some name for your pkcs#11 module" 
> -libfile /usr/lib64/pkcs11/your_fancy_p11_library.so
> 
> once done, the "spice client" will pick up the card automatically and
> it will show up in the working card reader in Windows with no further
> configuration.
> Alternatively, if your card doesn't have linux drivers (or it needs to
> be formatted by some Windows tool to a format specific for that
> tool...), the option for you is to use USB redirection of the whole
> card reader:
> 
> Then the card won't be obviously available in the client OS but that's
> kind of irrelevant if it's format need to be incompatible with the
> client OS anyway.
> Please note also that I had to stop and mask pcscd in the client
> system in order to make the reader redirect. Note also that you'll
> need the driver for the physical reader in the guest OS in this
> scenario (the Gemalto driver for my card reader was also available
> through Windows update). The card was not recognized in my case
> beacause it's CoolKey/RHCS-formatted which would need the driver
> linked above in Windows:
> 
> 
> HTH,
> 
> David 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice opengl

[David Jaša]

On Čt, 2015-05-21 at 12:00 +0800, 395459...@qq.com wrote:
> hi
> My arm board cpu is HI3716v200,and acoording to the datesheet:
> 
>   Hi3716CV200/Hi3719CV100/Hi3718CV100/Hi3719MV100/Hi3718MV100/Hi3716MV400 集成高
> 性能 Mali GPU，完成 3D 图形和视频处理功能。
> Hi3716CV200/Hi3719CV100/Hi3718CV100 集成高性能 4 核 Mali GPU；
> Hi3719MV100/Hi3718MV100 只集成高性能双核 Mali GPU。
> Hi3716MV400 只集成高性能单核 Mali GPU。
> 1600Pixels/s 处理能力
> 支持 OpenGL ES 2.0/1.1/1.0
> 支持 OpenVG 1.1
> When i use spice, how to use opengl to impove the preformance,can or
> can not ,can you tell me?thank you!!!

Spice does not use OpenGL in any way.

David

> 
> __
> 395459...@qq.com
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] keypress-delay issue

[David Jaša]

On Čt, 2015-06-25 at 00:28 -0700, Jared Kwek wrote:
> On Tue, Jun 23, 2015 at 4:14 PM, Marc-André Lureau  wrote:
> >
> >
> > It's interesting that I can barely notice the lag, and possibly most
> > people, judging by the amount of people complaining.
> 
> While true that the lag is barely noticeable, the fact is that it is
> there and more noticeable to some people than others.
> 
> >
> >
> > This was introduced to solve a real problem though, to avoid spurious
> > software key repeat on guest side. This is particularly annoying with
> > remote guest with a lag of several 100's of ms, but could also happen
> > locally if the VM get stuck due to scheduling.
> >
> 
> I also understand the problem you were trying to solve, as it is a
> common issue in remote desktop situations.  But instead of a
> one-size-fits-all solution, I'm advocating for a configurable value
> since different values make sense in different situations.  If my
> desktop is on a VM on my local machine, it would be a better user
> experience for me to turn down compression, keypress delays, etc.
> rather than use the same settings as if my desktop were streaming
> across a slow network connection.
> 
> >
> > I am not sure more tweaking should be advertised, as this is fairly
> > obscure and could reopen the issue I was trying to solve. Instead I
> > wish we would have a better/more clever solution to this issue.
> > Unfortunately, I don't have good one, adjusting the latency
> > based on local vs remote "measurements" would still let spurious
> > key repeats on slow scheduling, is this a better tradeoff?
> 
> 
> I don't think adjusting the latency based on measurements would be a
> good alternative unless it could be done with confidence in those
> measurements.  I think an easier method would be to set the
> keypress-delay to a sane value by default and allow it as a
> configuration item in case a person wants to tweak it.  Similar to how
> compression works now with the SPICE protocol...

IIRC the compression is set on connection initialization based on b/w
measurement so this analogy supports Marc-André's approach more. (I can
see that latency measurement is trickier than b/w).

David

> most people don't
> change the defaults but those that want to have the option to do so.
> 
> With the risk of generalizing too much, I value the fact that most
> open source software packages are more configurable than their
> commercial counterparts.  Having more options to tweak if I desire
> allows me to tailor the software to my specific use case.
> 
> Thanks for considering my suggestions.
> 
> Regards,
> Jared Kwek
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Thoughts about improving streaming video

[David Jaša]

g on it). "jpeg-wan-compression" and
"zlib-glz-wan-compression" are enabled in case the client's bandwidth is
<10Mbps, otherwise It's disabled. When jpeg compression and zlib over
glz compression are enabled then photo-like bitmaps are compressed by
lossy jpeg compression and textual/artificial bitmaps are compressed by
lossy zlib on top of GLZ.'

SPICE would compare the bandwidth to the bandwidth requirements of the
video and, if the video bandwidth requirements are some percentage less
than the available bandwidth (to leave some of other traffic - I do not
know what that number should be - 80%?), it uses MJPEG for better
quality and lower CPU utilization.  If not, it uses VP8 or whatever we
choose.  This could be multiple choice depending on bitrate/bandwidth if
that makes sense and not just MJPEG vs VP8.

This would be the most interesting approach although we should sacrifice
our programming interest to the best solution for the end users.  It
does have the advantage of not needing to be tweaked by the admin and
adapting to whether the user is on the end of a 3G cell connection or a
100 Mbps WAN link.

As I think about it, we already have precedent for making it the best of
all worlds by using an auto or fixed setting like SPICE does for other
parameters - auto activates the automated routine above and a fixed
value (MJPEG or VP8) specifically locks it to always use the specified
codec.  This is probably a good idea in general but would be
particularly helpful in the early stages while we tweak what that magic
percentage is for allowing other traffic, i.e., does the higher
utilization codec kick in at 80%, 60%, 95%.

Would you mind if I posted this response to the list to see if others
have helpful input? Thanks - John

On Fri, 2011-06-24 at 11:18 +0200, Andrea Celestino wrote:

Hi,

first of all I am studying the source coude of spice, because I need
to understand how spice detects video streaming, how it sends stream
data to client with socket and how it compress data with mjpeg.
I have not any idea at the moment, I need to do some tests.
I am very interested.
Do you have an idea?


Thanks.


p.s. sorry for my english :)





2011/6/23 John A. Sullivan III
  Certo! Hope I remembered that correctly.  I would be extremely
  interested. What did you have in mind? Thanks - John

  On Thu, 2011-06-23 at 10:29 +0200, Andrea Celestino wrote:
  >   Hi,
  >   I have read your message on Spice mailing lists and I am
  interesting
  >   in streaming video performance with spice. I am an italian
  student in
  >   computer engineering, during this period I am working on
  reducing
  >   bandwidth usage with streaming video in Spice. I see that
  you are
  >   interested in the same problem. I think that we can
  cooperate. What do
  >   you think about it?







___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel





___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel



--


David Jaša



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] QXL driver for Ubuntu

[David Jaša]

Dne 27.6.2011 19:54, Andrea Celestino napsal(a):

Hi,
I have installed Ubuntu 10.10 32 bit on qemu image and I would like to
use -vga qxl option to start spice server from the command line. I think
I should check if qxl driver are installed in my ubuntu 10.10, how can I
check if they are already installed?



http://packages.ubuntu.com/search?suite=all&searchon=names&keywords=qxl

QXL driver is included in Ubuntu since Maverick, so everything you have 
to do is to make sure you have 'xserver-xorg-video-qxl' package 
installed and then you can just run qemu-kvm with '-vga qxl'. Ubuntu's X 
should then detect QXL device and choose QXL driver automatically, you 
can check it in /var/log/Xorg.0.log then.



Thanks and sorry for my rusty english :)

Regards.



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel



--


David Jaša



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Thoughts about improving streaming video

[David Jaša]

Dne 28.6.2011 00:39, John A. Sullivan III napsal(a):
> On Tue, 2011-06-28 at 00:14 +0200, David Jaša wrote:
>> Dne 27.6.2011 20:45, John A. Sullivan III napsal(a):
>>> On Mon, 2011-06-27 at 08:32 +0300, Yaniv Kaul wrote:
>>>> Licensing and patent concerns of x264 aside (see
>>>> http://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html),
>>>> the more I think about it, the more it makes sense to me to have H.264
>>>> offload feature in QXL:
>>>
>>> This sounds great (gaming on SPICE!) but that's a pretty big aside.  How
>>> would we handle the patent issues? - John
>>>
>>
>> Gaming needs 3D acceleration, video needs video acceleration. That's two
>> distinct features despite being implemented by the same transistors. :)
>>
>> Patent issues can be solved pretty easily in an ugly way - make it
>> possible to pass any video stream to client if the client claims it
>> supports the container + codec, but do not include any patented stuff in
>> client by default. Users could observe the U.S. patent law and buy
>> codecs from e.g. Fluendo, who will pay the royalties for them, or if
>> they don't mind crossing it, they can add support of patented codecs
>> themselves.
>>
> 
>   I was making a reference to the X264 dev in they hyperlink who
> exclaimed, "ideoconferencing?  Pah!  I’m playing Call of Duty 4 over a
> live video stream!".  Interesting idea though!
> 
> However, more seriously, that is ugly.  Is it really something we would
> expect our users to do? Would it completely torpedo most commercial
> installation in the contract legal review stage?
> 

It's exactly what Fedora does:

===

Patent licenses usually require the licensee to pay royalties based on the 
number of users. Since Fedora is free and open source software, the effective 
number of users is essentially unrestricted. Patent holders are generally 
unwilling to give a blanket patent license for unlimited use; moreover, the 
royalty payments would be too high for it to be practical for the Fedora 
Project, or its sponsors, to pay them. Proprietary operating systems like 
Microsoft Windows include the costs of third-party patent licenses paid by 
Microsoft in the pricing of the product as sold to end users. Fedora is not 
sold commercially, so there is no way to recoup these substantial expenses. 

...

Note that Fluendo offers a MP3 plugin for the Gstreamer multimedia framework 
(used by Totem, Rhythmbox and other multimedia applications) for free and other 
codecs and DVD player for a price that includes patent licenses. Fedora does 
not include or endorse these options but you can choose to use them with Fedora 
if you want to.

==

(from 
http://fedoraproject.org/wiki/Software_Patents#Can.27t_you_pay_the_patent_license_fees_for_patent_encumbered_codecs.3F
 )

>  From reading the referenced hyperlink about x264
> (http://x264dev.multimedia.cx/archives/249) it sounds like an excellent
> solution but only if we can practically surmount the patent issues.
> Thoughts?
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


-- 


David Jaša



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Does spice use H264/MPEG4 for video compression?

[David Jaša]

Dne 14.7.2011 11:43, 徐舫 napsal(a):

  Hi all.

The mjpeg_encoder in spice server is MPEG-2 or MPEG-4?


It's neither. MJPEG is stream of JPEGs where each frame is encoded 
independently.


David Jaša


___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel





___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Thoughts about improving streaming video

[David Jaša]

Dne 22.7.2011 11:38, Andrea Celestino napsal(a):

Talking about improving streaming video in spice, I am working on a
thesis project about Spice, in particular how it handles streaming
video, only in Linux.

In particular I would like to know if there are possibilities to improve
it by
- replacing mjpeg with another encoder?
- or changing how stream data are transmitted to the client? for example
using a separate socket for the video and give it higher priority?



The most efficient approach is video stream passthrough discussed in 
earlier emails, that would offload any real work with video to the client.


David Jaša


Do you think that is quite complex to implement this works ? The second
solution seems easier, but I don't know if can improve something.
I read the spice code and all streaming-related stuff, but I would like
to know in advance if this work is too complex before starting it.

Thanks.




2011/6/28 Yaniv Kaul mailto:yk...@redhat.com>>

On 06/28/2011 11:14 AM, John A. Sullivan III wrote:

On Tue, 2011-06-28 at 09:30 +0200, David Jaša wrote:

Dne 28.6.2011 00:39, John A. Sullivan III napsal(a):

On Tue, 2011-06-28 at 00:14 +0200, David Jaša wrote:

Dne 27.6.2011 20:45, John A. Sullivan III napsal(a):

On Mon, 2011-06-27 at 08:32 +0300, Yaniv Kaul wrote:

Licensing and patent concerns of x264 aside (see

http://mailman.videolan.org/__pipermail/x264-devel/2010-__July/007508.html

<http://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html>),
the more I think about it, the more it makes
sense to me to have H.264
offload feature in QXL:

This sounds great (gaming on SPICE!) but that's
a pretty big aside.  How
would we handle the patent issues? - John

Gaming needs 3D acceleration, video needs video
acceleration. That's two
distinct features despite being implemented by the
same transistors. :)

Patent issues can be solved pretty easily in an ugly
way - make it
possible to pass any video stream to client if the
client claims it
supports the container + codec, but do not include
any patented stuff in
client by default. Users could observe the U.S.
patent law and buy
codecs from e.g. Fluendo, who will pay the royalties
for them, or if
they don't mind crossing it, they can add support of
patented codecs
themselves.


   I was making a reference to the X264 dev in
they hyperlink who
exclaimed, "ideoconferencing?  Pah!  I’m playing Call of
Duty 4 over a
live video stream!".  Interesting idea though!

However, more seriously, that is ugly.  Is it really
something we would
expect our users to do? Would it completely torpedo most
commercial
installation in the contract legal review stage?

It's exactly what Fedora does:

===

Patent licenses usually require the licensee to pay
royalties based on the number of users. Since Fedora is free
and open source software, the effective number of users is
essentially unrestricted. Patent holders are generally
unwilling to give a blanket patent license for unlimited
use; moreover, the royalty payments would be too high for it
to be practical for the Fedora Project, or its sponsors, to
pay them. Proprietary operating systems like Microsoft
Windows include the costs of third-party patent licenses
paid by Microsoft in the pricing of the product as sold to
end users. Fedora is not sold commercially, so there is no
way to recoup these substantial expenses.

...

Note that Fluendo offers a MP3 plugin for the Gstreamer
multimedia framework (used by Totem, Rhythmbox and other
multimedia applications) for free and other codecs and DVD
player for a price that includes patent licenses. Fedora
does not include or endorse these options but you can choose
to use them with Fedora if you want to.

==

(from

http:

Re: [Spice-devel] changing the timing of spice client linking in migration (RHBZ #725009)

[David Jaša]

n
> this is only the initial connection (the one triggered by
> migrate_start), and the actual communication will start only when
> migration ends.
> 
> Besides, it will also save us time and other artifacts that are a result
> of executing a fresh connection. E.g., We can avoid the network
> bandwidth test. Though I guess the bandwidth can change from one host to
> anotherBut preforming the network test upon linking is more
> complicated since the client doesn't listen yet to the socket...Maybe we
> can neglect this for now and assume the same bandwidth for the new host?
>>> Spice client
>>> 
>>> (A) SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST
>>> client connects to the target, but still stays connected to the
>>> source host. It doesn't listen to the target sockets.
>>> The link message to the target contains the connection_id of the
>>> connection to the source (this allows the target server to identify
>>> itself as a migration target).
>>> For this part we can use most of the code in the class Migrate in
>>> red_client.cpp
>>> (B) SPICE_MSG_MIGRATE
>>> We can use the code in red_channel::handle_migrate to switch the
>>> channels and start listening to the target.
>>> The difference is that we should implement differently the virtual
>>> method RedChannel::on_migrate.
>>> (1) Each channel must reset all the dynamic data that depends on
>>> the server. For example: the display channel
>>> needs to destroy all the surfaces and reset the caches and
>>> dictionary; The playback and record channel need to stop
>>> the current session, if there is an active one, etc.
>>> (2) Each channel should send to the server the initalization
>>> information it normally sends in RedChannel::on_connect.
>>>
>>> (C) SPICE_MSG_MAIN_MIGRATE_CANCEL
>>> disconnects all the new channels. This code is already implemented
>>> in spice-client.
>>>
>>> spice-protocol(?)/Backward compatibility
>>> =
>>> should we bounce spice protocol version, or use capabilities? (if we
>>> change SPICE_MSG_MAIN_MIGRATE_BEGIN structue, there is no question).
>>
>>> New Spice-Server with old client will send only
>>> SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST, and only when migration completes
>>> (same as today).
>>> New client with old Spice-server will disconnect the source and will
>>> connect the target upon receiving SPICE_MSG_MAIN_MIGRATE_SWITCH_HOST
>>> (same as today).
>>>
>>
>> Preferably, I would introduce SPICE_MSG_MAIN_MIGRATE_BEGIN2 etc. and
>> deprecate the older messages. From what I understand, we are now
>> preferably using caps rather than bumping protocol version.
> o.k. But when do we actually change the protocol version?
>>
>> cheers
>>
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice in School Labs?

[David Jaša]

Danishka Navin píše v Út 11. 10. 2011 v 16:44 +0530:
> Can we use this technology to minimize the cost of school labs?

That depends on your setup.

> I would like to test if I could find a documentation to settup on
> Fedora 14 or Fedora 15.

You need Fedora 15, preferably with virt-preview repo enabled. For a
quick intro, use two machines, first x86_64 with virtualization-capable
CPU, second with no special requirements.

On the first machine, install libvirt, spice-server and virt-manager
packages. Using virt-manager, create a new Virtual Machine with QXL
Video Device and Spice display with listen address set to 0.0.0.0 and
allow access without password. Note IP of the physical machine and port
of virtual one (virt-manager shows it to you in VM details).

On the second machine, run
spicy -h  -p 

Play with it for a while and then you should get some idea about spice.

> What is the dirrerence or relationship of Spice and KVM?

Spice is a protocol that is used to access desktops of KVM-powered
virtual machines over network

David
> 
> Thanks
> -- 
> Danishka Navin
> http://danishkanavin.blogspot.com
> http://twitter.com/danishkanavin
> http://www.flickr.com/photos/danishkanavin/
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] inputs_channel.c undefined variable

[David Jaša]

Mizon Tsai píše v Ne 16. 10. 2011 v 15:59 -0700:
> Hi,
> 
> 
> Newbie here trying to setup spice on Fedora 15 (64bit) with Eclipse
> CDT (8.0.1 Indigo)
> 

Hi Mizon,

If you just want to play with spice, I recommend you to enable
virt-preview repo that should contain all relevant packages, up2date.

David
> 
> Using the following versions of spice and spice-protocol -
> spice-0.9.1
> spice-protocol-0.9.0
> 
> 
> 
> 
> For some reason I have 3rd parameter in SPICE_CONTAINEROF undefined -
> "base"
> 
> 
> server/inputs_channel.c
> void inputs_set_tablet_logical_size(int x_res, int y_res)
> {
> SpiceTabletInterface *sif;
> 
> 
> sif = SPICE_CONTAINEROF(tablet->base.sif, SpiceTabletInterface,
> base);
> sif->set_logical_size(tablet, x_res, y_res);
> }
> 
> 
> Was there some header file I missed? 
> 
> 
> thanks!
> Ming
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] inputs_channel.c undefined variable

[David Jaša]

Mizon Tsai píše v Po 17. 10. 2011 v 23:27 -0700:
> Hi David,
> 
> 
> Thanks for the quick reply.
> 
> 
> I am actually interested in setting up an environment where I can help
> write some test tool for measuring Spice performance.
> 
> 
> I was able to compile successfully, and start a virtual image instance
> with spice enabled through both virt-manager and qemu. 
> 
> 
> Do you know any recommendation on what I should do / what to look for
> in terms resolving my IDE undefined variable issue?
> 
> 
> Also would be great to know what is the default/easiest IDE/OS setup
> to use for getting a spice dev environment setup...
> 

Hi Mizon,

I'm not a developer so I think that you'll get more assistance from
other people on the list...

David
> 
> thanks!
> Mizon
> 
> 
> 
> __
> From: David Jaša 
> To: Mizon Tsai 
> Cc: "spice-devel@lists.freedesktop.org"
> 
> Sent: Monday, October 17, 2011 2:11 AM
> Subject: Re: [Spice-devel] inputs_channel.c undefined variable
> 
> Mizon Tsai píše v Ne 16. 10. 2011 v 15:59 -0700:
> > Hi,
> > 
> > 
> > Newbie here trying to setup spice on Fedora 15 (64bit) with Eclipse
> > CDT (8.0.1 Indigo)
> > 
> 
> Hi Mizon,
> 
> If you just want to play with spice, I recommend you to enable
> virt-preview repo that should contain all relevant packages, up2date.
> 
> David
> > 
> > Using the following versions of spice and spice-protocol -
> > spice-0.9.1
> > spice-protocol-0.9.0
> > 
> > 
> > 
> > 
> > For some reason I have 3rd parameter in SPICE_CONTAINEROF undefined
> -
> > "base"
> > 
> > 
> > server/inputs_channel.c
> > void inputs_set_tablet_logical_size(int x_res, int y_res)
> > {
> >SpiceTabletInterface *sif;
> > 
> > 
> >sif = SPICE_CONTAINEROF(tablet->base.sif, SpiceTabletInterface,
> > base);
> >sif->set_logical_size(tablet, x_res, y_res);
> > }
> > 
> > 
> > Was there some header file I missed? 
> > 
> > 
> > thanks!
> > Ming
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> -- 
> 
> David Jaša, RHCE
> 
> SPICE QE based in Brno
> GPG Key:22C33E24 
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> 
> 
> 
> 
> 
> 

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] steal me mouse

[David Jaša]

Todd And Margo Chester píše v Po 07. 11. 2011 v 19:08 -0800:
> Hi Guys,
> 
> Scientific Linux 6.2 x64
> host: kvm
> guests: fc15 x64, XP-Pro x32, W7 x32
> spice 0.8.x
> 
> To my consternation, I have found that if I mouse over my guest's SPICEc 
> window,
> I will loose my mouse until the guest machine boots to the point that 
> its mouse
> driver get enabled.  Then I get my mouse back.
> 
> Well now, my guest does not always boot up (what me screw things up?!?!?).
> The only way I can get my mouse back is  to open a command
> prompt, then "virch -l" to get my ID and "virsh destroy ID".  Then 
> 
> to get back to my GUI.  Total pain in the neck.
> 
> Is there some easier to get my mouse back when this happens?
> 
> Also, is this a know bug or just a screw up on my part?
> 

Sort of known. I noticed it too (upon migration) but each time I wanted
to report it, I wasn't able to reproduce it again.

David

> Many thanks,
> -T
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How do I install vioser in virt-manager?

[David Jaša]

Todd And Margo Chester píše v Čt 10. 11. 2011 v 10:58 -0800:
> On 11/09/2011 12:51 PM, Alon Levy wrote: 
> > On Wed, Nov 09, 2011 at 11:07:57AM -0800, Todd And Margo Chester wrote:
> > > Hi All,
> > > 
> > > Scientific Linux 6.2 x64
> > > host: kvm
> > > guest: XP-Pro x32
> > > spice 0.8.x
> > > 
> > > I give up.  I have Googl'ed my fingers off on this one.  How
> > > do I install the virtio serial device in my guest with virt-manager?
> > > 
> > > I see serial devices to add, but what type and what is the
> > > path to the device?  Am I even looking at the right serial devices?
> > The serial device should appear in other devices (along with the cpus)
> > in device manager. There is a link for a driver on the dowload page of
> > spice:
> > 
> >  http://spice-space.org/download.html
> > 
> >  under "Windows binaries:", current link is
> >  http://spice-space.org/download/binaries/virtio-serial_20110725.zip
> >  which looks relatively recent.
> > 
> >  I don't remember the upstream location for the drivers, I'll try to
> >  find it and update, but I think those should be good, let me know if
> >  they aren't.
> > 
> > Note that this is not the serial device you should also have in the vm,
> > i.e. COM1, but a different device.
> > 
> > Alon
> > 
> > > Very frustrated and confused,
> > > -T
> > > ___
> > > 
> My revisions:
> 
> $ rpm -qa \*spice\*
> spice-server-0.8.0-1.el6.x86_64
> spice-client-0.8.0-2.el6.x86_64
> spice-protocol-0.8.0-1.el6.noarch
> 
> # rpm -qa \*vdagent\*
> spice-vdagent-0.6.3-8.el6.x86_64
> 
> $ rpm -qa \*kvm\*
> qemu-kvm-0.12.1.2-2.160.el6_1.2.x86_64
> 
> $ cat /etc/redhat-release
> Scientific Linux release 6.1 (Carbon)
> 
> $ uname -r
> 2.6.32-131.17.1.el6.x86_64
> # ls /dev/virtio-ports/
> ls: cannot access /dev/virtio-ports/: No such file or
> directory
> 
> 
> Hi Alon,
> 
> I must be missing something.  For starters, I have
> no /dev/virtio-ports
> directory.
> 
> I also must be blind too, as I can not find an "other devices" in my
> virt-manager.
> Please forgive the picture, but this is what I see:
> 
> virt-manager
> 
> 
> This is so frustrating.  What am I doing wrong?
> 
It seems to me that your version of virt-manager doesn't know about
spice channel yet, so I suggest you to add it to libvirt configuration
via CLI - run 'virsh edit $YOUR_VM_NAME' and add spicevmc channel to
devices list as described here:
http://libvirt.org/formatdomain.html#elementCharChannel

Once you add it, you should see the channel in virt-manager, too.

HTH,

David

> Many thanks,
> -T
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How do I install vioser in virt-manager?

[David Jaša]

Todd And Margo Chester píše v Ne 13. 11. 2011 v 19:25 -0800:
> > On 11/11/2011 03:36 AM, David Jaša wrote:
> >> Todd And Margo Chester píše v Čt 10. 11. 2011 v 10:58 -0800:
> >>> On 11/09/2011 12:51 PM, Alon Levy wrote:
> >>>> On Wed, Nov 09, 2011 at 11:07:57AM -0800, Todd And Margo Chester wrote:
> >>>>> Hi All,
> >>>>>
> >>>>> Scientific Linux 6.2 x64
> >>>>> host: kvm
> >>>>> guest: XP-Pro x32
> >>>>> spice 0.8.x
> >>>>>
> >>>>> I give up.  I have Googl'ed my fingers off on this one.  How
> >>>>> do I install the virtio serial device in my guest with virt-manager?
> >>>>>
> >>>>> I see serial devices to add, but what type and what is the
> >>>>> path to the device?  Am I even looking at the right serial devices?
> >>>> The serial device should appear in other devices (along with the cpus)
> >>>> in device manager. There is a link for a driver on the dowload page of
> >>>> spice:
> >>>>
> >>>>   http://spice-space.org/download.html
> >>>>
> >>>>   under "Windows binaries:", current link is
> >>>>   http://spice-space.org/download/binaries/virtio-serial_20110725.zip
> >>>>   which looks relatively recent.
> >>>>
> >>>>   I don't remember the upstream location for the drivers, I'll try to
> >>>>   find it and update, but I think those should be good, let me know if
> >>>>   they aren't.
> >>>>
> >>>> Note that this is not the serial device you should also have in the vm,
> >>>> i.e. COM1, but a different device.
> >>>>
> >>>> Alon
> >>>>
> >>>>> Very frustrated and confused,
> >>>>> -T
> >>>>> ___
> >>>>>
> >>> My revisions:
> >>>
> >>>  $ rpm -qa \*spice\*
> >>>  spice-server-0.8.0-1.el6.x86_64
> >>>  spice-client-0.8.0-2.el6.x86_64
> >>>  spice-protocol-0.8.0-1.el6.noarch
> >>>
> >>>  # rpm -qa \*vdagent\*
> >>>  spice-vdagent-0.6.3-8.el6.x86_64
> >>>
> >>>  $ rpm -qa \*kvm\*
> >>>  qemu-kvm-0.12.1.2-2.160.el6_1.2.x86_64
> >>>
> >>>  $ cat /etc/redhat-release
> >>>  Scientific Linux release 6.1 (Carbon)
> >>>
> >>>  $ uname -r
> >>>  2.6.32-131.17.1.el6.x86_64
> >>>  # ls /dev/virtio-ports/
> >>>  ls: cannot access /dev/virtio-ports/: No such file or
> >>>  directory
> >>>
> >>>
> >>> Hi Alon,
> >>>
> >>> I must be missing something.  For starters, I have
> >>> no /dev/virtio-ports
> >>> directory.
> >>>
> >>> I also must be blind too, as I can not find an "other devices" in my
> >>> virt-manager.
> >>> Please forgive the picture, but this is what I see:
> >>>
> >>> virt-manager
> >>>
> >>>
> >>> This is so frustrating.  What am I doing wrong?
> >>>
> >> It seems to me that your version of virt-manager doesn't know about
> >> spice channel yet, so I suggest you to add it to libvirt configuration
> >> via CLI - run 'virsh edit $YOUR_VM_NAME' and add spicevmc channel to
> >> devices list as described here:
> >> http://libvirt.org/formatdomain.html#elementCharChannel
> >>
> >> Once you add it, you should see the channel in virt-manager, too.
> >
> > Hi David,
> >
> >I am confused.  Any change you can show me an example?  Are you
> > running Virtio-serial on your machine?  Can you show me what yours
> > looks like?
> >
> > Many thanks,
> > -T
> 
> Hi David,
> 
> Maybe it would if I got a bit more specific as to why I am confused.
> Now, I am good at editing, and have used "vi" for years, and am no
> stranger to copying and pasting.  I just don't understand the why
> behind what I am pasting.
> 
> Specifically, this line from 
> http://libvirt.org/formatdomain.html#elementCharChannel:
> 
>  
> 
>  
> 
> "arbitrary.virtio.serial.port.name" is what is confusing me.  I highly
> doubt this is the "any key".  "arbitrary" always has to be matched with
> "arbitrary" somewhere else.  What somewhere else?  This is confusing me.
> And, why an example of your (or anyone else's) would be of great help.
> 

Hi Todd,

there are three channels defined in the documentation. You only need the
last one, whose type is spicevmc:

  




  

  

David

> Sorry for being so thick here.
> 
> Many thanks,
> -T
> 
> 
> >
> >>
> >> HTH,
> >>
> >> David
> >>
> >>> Many thanks,
> >>> -T
> >>>
> >>>
> >>>
> >>> ___
> >>> Spice-devel mailing list
> >>> Spice-devel@lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >>
> >
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice + Thinclients + Hardware acceleration

[David Jaša]

thom...@cs.tu-berlin.de píše v So 12. 11. 2011 v 22:56 +0100:
> Hi,
> I planning to use Spice in a Infrastructure-Project.
> The idea is to use Thinclients with the spice-client-gtk/libspice-gtk.
> Now I have find a Thinclient thats have sufficient Performance for all
> Spice-Features.
> 
> I tried find out if the current spice-client uses the GPU in any way (e.g
> via OpenGL). I guess Cairo is currently the only one used Lib that utilize
> Hardware-Acceleration-Features ?
> Please correct me if I'm wrong.
> 
> My current Test-Thinclient-Hardware (1Ghz CPU,1 GB Ram, OpenGL 2.0 GPU)
> have massive Problems with Video-Playback (CPU-Load 100%).
> 
> Do you plan on mid or long term to use any "Acceleration-Features" (e.g
> VAAPI,XvBA,GPGPU) to improve the improve Video-Playback or should I try to
> get a Thinclient with better CPU ?
> 
> Has anyone experiences with Minimum System/Hardware Requirements for
> fluently Playback of an 720p Video via Spice ?
> 

Spice currently transmits video streams series of JPEGs in resolution
that is displayed in client, so for worst-case scenario, the hardware
should be able to decode MJPEG @ maximum screen resolution (for full
screen video in full screen spice client)

HTH,

David

> Greetings
> Thomas Tyminski
> Berlin , Germany
> 
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] About spice-xpi firefox version Compatiblity

[David Jaša]

Antonio Perez-Aranda píše v Po 14. 11. 2011 v 11:42 +0100:
> Well, After some test, I get the plugin running by adding libnsISpicec
>  libraries on /usr/lib/mozilla/plugins/
> But I can get it running with librarys on user profile.
> 
> Another Question is ¿Can I embed like a flash on a classic page with a
> specific size?
> 
> With something like this:
> 
> 
> 
> I always get a new window with a Spice handler.
> 

You can not, spice-xpi is not a client. It is just a kind of helper that
allows a web page to start actual client that will run then in its own
window.

I think there were some implementations of spice client in Java on this
list so if you want a client embedded to web page, that could possibly
work for you.

David

> 2011/11/9 Antonio Perez-Aranda :
> > Hi all,
> >
> > I'm tring to running spice-xpi on Firefox 7.0 but it say me that
> > plugin is incompatible.
> >
> > I modify the install.rdf to allow install until firefox 10.0 and I'm
> > disable the compatibility check on install. But when I try to load
> > "test.html" from git it say me that the plugins are required.
> >
> > Do you plan support recent Firefox versions?
> >
> > Thanks
> >
> > --
> > Antonio Pérez-Aranda Alcaide
> > aperezara...@yaco.es
> >
> > Yaco Sistemas S.L.
> > http://www.yaco.es/
> > C/ Rioja 5, 41001 Sevilla
> > Teléfono +34 954 50 00 57
> > Fax  +34 954 50 09 29
> >
> 
> 
> 

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH vdagent-win 3/3] vdlog: change log times to human readable date & time rhbz#672828

[David Jaša]

Arnon Gilboa píše v St 16. 11. 2011 v 14:20 +0200:
> Alon Levy wrote:
> > On Wed, Nov 16, 2011 at 12:16:37PM +0200, Arnon Gilboa wrote:
> >   
> >> ifndef USE_DATE_TIME, use system time instead of secs from system startup
> >> 
> >
> > Why do we want to keep the old behavior?
> >   
> For users & qa, human readable date & time (hh:mm:ss) is nicer.
> For debugging, having finer resolution (millisec) sometime helps.
> Sounds reasonable?

FTR, RHEV logs use format like this:
2011-11-16 13:43:40,205::

IMO, such time format is suitable for both needs (and given the
verbosity of logs with DEBUG levels, they would be unreadable without ms
precision).

David

> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Virt-manager and spice

[David Jaša]

Scott Dowdle píše v St 16. 11. 2011 v 12:03 -0500:
> Greetings,
> 
> - Original Message -
> > I think you need to see this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=694694
> > And in particular this link inside the bugzilla (not tested myself
> > yet...):
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=3096144
> 
> I just tested virt-manager on one of my RHEL 6.1 boxes and it includes QXL 
> and SPICE but the system does not have the spice-gtk package installed... 
> since there isn't one.  Some other package is providing the functionality.
> 

Hi Scott,

for spice-gtk package that provides spice console for virt-manger,
you'll have to wait for RHEL 6.2 release

David

> The only spice related packages that I see installed on the system are:
> 
> spice-vdagent-0.6.3-8.el6.x86_64
> spice-server-0.8.0-1.el6.x86_64
> 
> TYL,

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice-vdagentd won't start -- missing /dev/virtio-ports/com.redhat.spice.0

[David Jaša]

Todd And Margo Chester píše v Pá 18. 11. 2011 v 21:31 -0800:
> Ooops.  Retransmitted without the HTML.
> 
> 
> Hi Guys,
> 
> I can not get /etc/rc.d/init.d/spice-vdagentd to start because of the line
> 
>   [ -c $port ] || exit 0# where "$port" = 
> "/dev/virtio-ports/com.redhat.spice.0"
> 
> in the "start" function.
> 
> Problem: I have no "/dev/virtio-ports" directory.  "spice-vdagentd" exits as
> it is suppose to.
> 
> How do I get "/dev/virtio-ports/com.redhat.spice.0" to show up?  What did I
> not install?  What am I doing wrong?
> 

It has to be on qemu-kvm command line or in libvirt's domain xml. We
told you all the instructions in previous thread, if you don't
understand something, please ask there more concretely.

David

> Many thanks,
> -T
> 
> # rpm -qa \*spice\*
> spice-server-0.8.0-1.el6.x86_64
> spice-client-0.8.0-2.el6.x86_64
> spice-vdagent-0.6.3-8.el6.x86_64
> spice-protocol-0.8.0-1.el6.noarch
> 
> # rpm -qa \*vdage\*
> spice-vdagent-0.6.3-8.el6.x86_64
> 
> 
> 
> 
> 
> _______
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] deadlock / monitor qemu / spice

[David Jaša]

 >while(true); do echo "" | socat - TCP4:[25][16]127.0.0.1:10101
> >> >  ; sleep 1 ;
> >> >
> >> >>done
> >> >>DEV-10.98.98.1:~# /usr/local/bin/qemu -name PC001 -spice
> >> >>port=11931,disable-ticketing -soundhw hda -vga qxl -device
> >> >>virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent
> >> >-device
> >> >>virtserialport,chardev=vdagent,name=com.redhat.spice.0 -cpu kvm64
> >> >
> >> >  >-localtime -usbdevice tablet -vnc [26][17]10.98.98.1:101
> >> >  -monitor
> >> >  >tcp:[27][18]127.0.0.1:10101,server,nowait,nodelay -m 512
> >> >  -pidfile
> >> >
> >> >>/var/run/qemu/PC001.pid -net
> >> >>
> >> >
> >> > tap,vlan=5,name=externe,script=/etc/qemu-ifEup,downscript=/etc/qemu-ifE
> >> >>down,ifname=vmEtap1 -net
> >> >>nic,vlan=5,macaddr=ac:de:49:20:b1:b3,model=rtl8139 -drive
> >> >>file=/swapfile-guest/swap1,if=ide,index=1,media=disk,snapshot=on
> >> >-rtc
> >> >>base=localtime -drive
> >> >>
> >> >
> >> > file=/mnt/vdisk/images/VM-PC001.1321542255.5541701,index=0,media=disk,s
> >> >
> >> >>napshot=on,cache=unsafe -fda fat:floppy:/mnt/vdisk/diskconf/PC001
> >> >-k fr
> >> >>--enable-kvm -readconfig /tmpsafe/ehci -chardev
> >> >>spicevmc,name=usbredir,id=usbredirchardev1 -device
> >> >>usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3
> >> >>do_spice_init: starting 0.10.0
> >> >>spice_server_add_interface: SPICE_INTERFACE_MIGRATION
> >> >>spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
> >> >>spice_server_add_interface: SPICE_INTERFACE_MOUSE
> >> >>spice_server_add_interface: SPICE_INTERFACE_QXL
> >> >>red_worker_main: begin
> >> >>ensure_display_channel_created: create display channel
> >> >>ensure_cursor_channel_created: create cursor channel
> >> >>spice_server_add_interface: SPICE_INTERFACE_PLAYBACK
> >> >>spice_server_add_interface: SPICE_INTERFACE_RECORD
> >> >>*** EHCI support is under development ***
> >> >>spice_server_char_device_add_interface: CHAR_DEVICE usbredir
> >> >>
> >> >>Result, vm freeze during first boot or second.
> >> >>
> >> >>Regards
> >> >>
> >> >>Nicolas Prochazka.
> >> >>
> >> >
> >> >  >2011/11/17 Alon Levy <[28][19]al...@redhat.com>
> >> >
> >> >>
> >> >>On Thu, Nov 17, 2011 at 04:43:12PM +0100, nicolas prochazka 
> >> > wrote:
> >> >>> Hello again,
> >> >>>
> >> >>> qemu 1.0 rc2
> >> >>>
> >> >>> spice 0.10
> >> >>>
> >> >>> It's a known problem, but I thought it was corrected:
> >> >>> when i run a vm with spice qxl, if i do lot of qemu monitor via
> >> >tcp ,
> >> >>> spice vm freeze.
> >> >>
> >> >>  First time I've heard of it - where is it reported?
> >> >>  >
> >> >>  > Regards,
> >> >>  >
> >> >>  > Nicolas Prochazka.
> >> >>  > ___
> >> >>  > Spice-devel mailing list
> >> >
> >> >  >  > [29][20]Spice-devel@lists.freedesktop.org
> >> >  >  >
> >> >  [30][21]http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >> >  >
> >> >  > References
> >> >  >
> >> >  >1.
> >> >  [22]http://www.spice-space.org/download/binaries/qxl-0.10-20112808.z
> >> >  ip
> >> >  >2. [23]http://10.98.98.1:101/
> >> >  >3. [24]http://127.0.0.1:10101/
> >> >  >4. [25]http://10.98.98.1:102/
> >> >  >5. [26]http://127.0.0.1:10102/
> >> >  >6. [27]http://10.98.98.1:103/
> >> >  >7. [28]http://127.0.0.1:10103/
> >> >  >8. [29]http://10.98.98.1:104/
> >> >  >9. [30]http://127.0.0.1:10104/
> >> >  >   10. [31]http://10.98.98.1:105/
> >> >  >   11. [32]http://127.0.0.1:10105/
> >> >  >   12. [33]http://10.98.98.1:106/
> >> >  >   13. [34]http://127.0.0.1:10106/
> >> >  >   14. [35]http://10.98.98.1:107/
> >> >  >   15. [36]http://127.0.0.1:10107/
> >> >  >   16. [37]http://10.98.98.1:108/
> >> >  >   17. [38]http://127.0.0.1:10108/
> >> >  >   18. [39]http://10.98.98.1:109/
> >> >  >   19. [40]http://127.0.0.1:10109/
> >> >  >   20. [41]http://10.98.98.1:110/
> >> >  >   21. [42]http://127.0.0.1:10110/
> >> >  >   22. mailto:[43]prochazka.nico...@gmail.com
> >> >  >   23. [44]http://10.98.98.1:101/
> >> >  >   24. [45]http://127.0.0.1:10101/
> >> >  >   25. [46]http://127.0.0.1:10101/
> >> >  >   26. [47]http://10.98.98.1:101/
> >> >  >   27. [48]http://127.0.0.1:10101/
> >> >  >   28. mailto:[49]al...@redhat.com
> >> >  >   29. mailto:[50]Spice-devel@lists.freedesktop.org
> >> >  >   30.
> >> >  [51]http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >> >
> >> > References
> >> >
> >> >1. mailto:al...@redhat.com
> >> >2. http://spice-space.org/download/unstable/qxl-win-0.1-12.zip
> >> >3. http://10.98.98.1:101/
> >> >4. http://10.98.98.1:102/
> >> >5. http://10.98.98.1:103/
> >> >6. http://10.98.98.1:104/
> >> >7. http://10.98.98.1:105/
> >> >8. http://10.98.98.1:106/
> >> >9. http://10.98.98.1:107/
> >> >   10. http://10.98.98.1:108/
> >> >   11. http://10.98.98.1:109/
> >> >   12. http://10.98.98.1:110/
> >> >   13. mailto:prochazka.nico...@gmail.com
> >> >   14. http://10.98.98.1:101/
> >> >   15. http://127.0.0.1:10101/
> >> >   16. http://127.0.0.1:10101/
> >> >   17. http://10.98.98.1:101/
> >> >   18. http://127.0.0.1:10101/
> >> >   19. mailto:al...@redhat.com
> >> >   20. mailto:Spice-devel@lists.freedesktop.org
> >> >   21. http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >> >   22. http://www.spice-space.org/download/binaries/qxl-0.10-20112808.zip
> >> >   23. http://10.98.98.1:101/
> >> >   24. http://127.0.0.1:10101/
> >> >   25. http://10.98.98.1:102/
> >> >   26. http://127.0.0.1:10102/
> >> >   27. http://10.98.98.1:103/
> >> >   28. http://127.0.0.1:10103/
> >> >   29. http://10.98.98.1:104/
> >> >   30. http://127.0.0.1:10104/
> >> >   31. http://10.98.98.1:105/
> >> >   32. http://127.0.0.1:10105/
> >> >   33. http://10.98.98.1:106/
> >> >   34. http://127.0.0.1:10106/
> >> >   35. http://10.98.98.1:107/
> >> >   36. http://127.0.0.1:10107/
> >> >   37. http://10.98.98.1:108/
> >> >   38. http://127.0.0.1:10108/
> >> >   39. http://10.98.98.1:109/
> >> >   40. http://127.0.0.1:10109/
> >> >   41. http://10.98.98.1:110/
> >> >   42. http://127.0.0.1:10110/
> >> >   43. mailto:prochazka.nico...@gmail.com
> >> >   44. http://10.98.98.1:101/
> >> >   45. http://127.0.0.1:10101/
> >> >   46. http://127.0.0.1:10101/
> >> >   47. http://10.98.98.1:101/
> >> >   48. http://127.0.0.1:10101/
> >> >   49. mailto:al...@redhat.com
> >> >   50. mailto:Spice-devel@lists.freedesktop.org
> >> >   51. http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Send event to virtual desktop on "disconnect" screen

[David Jaša]

Antonio Perez-Aranda píše v Čt 24. 11. 2011 v 11:45 +0100:
> Hi guys,
> 
> I need to active XscreenSaver or similar (P.E send Ctrl-L keys on
> gnome or call to gnome-screensaver --lock) on running virtual machine
> after the client and machine break the Spice connection. Is this
> possible? maybe with spicevmc or similar?
> 

Hi Antonio,

ovirt-guest-agent does that, you can look how it is done here:
git://gerrit.ovirt.org/ovirt-guest-agent
(link is from here: http://www.ovirt.org/project/subprojects/ )

David

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Spice required ports

[David Jaša]

Richard Mann píše v Čt 01. 12. 2011 v 11:01 -0500:
> Just joined.  Not sure where to ask this question.  It relates to
> security and opening ports on a firewall through which the Spice
> clients and server would communicate.  I would like to know how many
> ports will need to be opened on a firewall to support the 6
> communications channels between the Spice clients and server.
> 
> Excerpt from Spice for Newbies PDF.
> 
> 
> 2.3.2.1 Channels
> The client and server communicate via channels. Each channel type is
> dedicated to a specific type
> of data. Each channel uses a dedicated TCP socket..
> 
> The available channels are:
> o Main - implemented by RedClient (see above).
> o DisplayChannel - handles graphic commands, images and video streams.
> o InputsChannel - keyboard and mouse inputs.
> o CursorChannel - pointer device position, visibility and cursor
> shape.
> o PlaybackChannel - audio received from the server to be played by the
> client .
> o RecordChannel - audio captured on the client side.
> 
> 
> 
> After looking at the Spice PDFs it appears to me that 6 ports would
> need to be opened although the default Spice server port appears to be
> 5930 (just one port and not six).
> 
> 
> I would like to know how many ports are required (listening) on the
> Spice server to handle all 6 channels (TCP sockets)?  I am assuming
> each channel (TCP socket) requires its own port on the Spice server.
> 
Hello Rich,

you only need one to two TCP port per VM opened on your firewall. The
source ports need to be unique for each channel, the destination port is
only one per VM (if all channels are open or encrypted), or two per VM
(with some channel encrypted, some not).

IOW, you need to enable port range on your firewall based on above facts
and your configuration (which ports you'll designate for spice traffic).

David

> 
> Thanks,
> Rich
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] keyboard and Mouse Fails....

[David Jaša]

Naga Mohan Pothula píše v Po 19. 12. 2011 v 10:13 -0800:
> We can move mouse over the guest but the guest doesn't respond for
> user actions like mouse click.

I've seen something similar that was caused by agent. Keyboard worked
fine so I used it to restart agent service and everything started
working normally. I was not able to make clear reproducer for this
however, so if you have a reliable step-by-step one, it would be great

David
> 
> In the same way for keyboard actions. Client machine needs to get
> restarted or close Xwindows to reconnect guest.
> This issue happens only when we connect windows guest in fullscreen
> mode with auto-conf from linux client(but not from windows client). 
> It doesn't happen if we connect guest in windowed mode.
> 
> 
> 
> 
> Thanks/Mohan.
> 
> 
> 
> __
> From: Christophe Fergeau 
> To: Naga Mohan Pothula  
> Cc: "spice-devel@lists.freedesktop.org"
>  
> Sent: Monday, December 19, 2011 3:20 AM
> Subject: Re: [Spice-devel] keyboard and Mouse Fails
> 
> On Mon, Dec 19, 2011 at 12:32:47AM -0800, Naga Mohan Pothula wrote:
> > Hi,
> > 
> > Keyboard and Mouse failure happens when windows guests are connected
> from linux client. 
> 
> What do you mean exactly by keyboard and mouse failures? You can't
> type
> anything nor move the mouse? Or do you observe a different kind of
> failure?
> 
> Christophe
> 
> 
> 
> _______
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Performance over VPN

[David Jaša]

Hello Ian,

Ian Barron píše v Út 20. 12. 2011 v 11:23 +0100:
> Hi ,
> 
>  
> 
> We are trying Spice as a potential solution for remote access to a VM.
> (to replace VNC and NX).
> 
>  
> 
> The current installation is :-
> 
> Host:  Fedora 16
> 
> Guest (VM): CentOS 5.7
> 
>  
> 
> Qemu-kvm :  0.15.1
> 
> Spice : 0.10.0
> 
>  
> 
> Clients:
> 
> Windows 7 64 :  
> 
> spice-client-win32-0.6.3.zip
> 
> spice_libs_win32_063_and_earlier.zip
> 
>  
> 
> Linux:
> 
> spice-0.10.0.tar.bz2
> 
> spice-protocol-0.10.0.tar.bz2
> 
>  
> 
>  
> 
> Performance over the LAN is everything we had hoped for. Our problem
> comes with performance (or lack of it) over VPN.  With traffic over
> VPN (even with latency under 20ms) the client is so slow and with such
> a delay that it is almost impossible to control the mouse. 

This sounds like you have mouse in server mode. Install spice-vdagent in
the guest, make sure it is running and pleaser report back if it solved
things for you

David
> 
> I’ve tried digging in the archives and only found a very old reference
> to loading the qxl drivers on the client. …  
> 
>  
> 
> Can anyone suggest what I am missing ? or is this a known current
> problem with Spice?
> 
>  
> 
> Thanks,
> 
>  
> 
>  
> 
> Ian Barron
> 
>  
> 
> General Manager
> 
> RoQC DataManagement AS
> 
> Ryfylkeveien 1741
> 
> 4120 Tau
> 
> Norway
> 
>  
> 
> Tlf: +47 90615416
> 
> email:  i...@roqc.no
> 
> URL:www.roqc.com
> 
>  
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] VideoStream - MJpeg Encode/Decode.

[David Jaša]

Hello Mohan,

Naga Mohan Pothula píše v Pá 23. 12. 2011 v 09:17 -0800:
> Hi,
> 
> 
> I have doubt on MJpeg encode/decode module. I've seen Frame rect with
> ODD format is not accepting by MJpegDecoder at "convert_scanline"
> function.
> 
> 
> ASSERT(_width % 2 == 0);
> ASSERT(_height % 2 == 0);
> Spice session crash happens due to this assertion.

Could you file it as a bug, please, preferably with some example video
that triggers it?

Thank you

David
> 
> 
> Why the decoder accepts only EVEN format frames? If this is the case
> why we are not going to restrict at MJpeg Encoder rather than keeping
> an assertion at MJpeg Decoder. 
> How we are dealing with ODD format Frame rects for MJpeg? 
> 
> 
> 
> 
> Appreciated your help.
> 
> 
> 
> 
> Thanks,
> Mohan.
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] 答复: Re: 答复: Re: hi,everyone. anyone do spice client on mac os x?

[David Jaša]

Alon Levy píše v Po 09. 01. 2012 v 14:11 +0200:
> On Mon, Jan 09, 2012 at 12:21:43PM +0100, Christophe Fergeau wrote:
> > On Mon, Jan 09, 2012 at 07:07:14PM +0800, wang.ch...@zte.com.cn wrote:
> > > 1. about spice client for mac os x, I refer to this modification：
> > > http://lists.freedesktop.org/archives/spice-devel/2010-September/001237.html
> > >  
> > 
> > Ah ok thanks. Seems this patch got lost :-/
> > 
> 
> +1 to picking it up (even if it is for spicec and not spice-gtk)
> 

Seeing this and the patch traffic here, I'm wondering if spice team
wouldn't benefit from using gerrit, like RHEV/oVirt do. The nice thing
about it is that it leverages git so the actual workflow doesn't have to
change much when it is used.

David

> > > 2. about spice on ios(ipad），are you have feasible scheme? can you 
> > > provide me with some info? how i can do it ?
> > 
> > I've already told you most of what I could say about it :) I'm not familiar
> > at all with iOS porting, so can't tell you more...
> > 
> > Christophe
> > 
> 
> 
> 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] 答复: Re: 答复: Re: hi,everyone. anyone do spice client on mac os x?

[David Jaša]

Alon Levy píše v Po 09. 01. 2012 v 17:22 +0200:
> On Mon, Jan 09, 2012 at 03:21:46PM +0100, David Jaša wrote:
> > Alon Levy píše v Po 09. 01. 2012 v 14:11 +0200:
> > > On Mon, Jan 09, 2012 at 12:21:43PM +0100, Christophe Fergeau wrote:
> > > > On Mon, Jan 09, 2012 at 07:07:14PM +0800, wang.ch...@zte.com.cn wrote:
> > > > > 1. about spice client for mac os x, I refer to this modification：
> > > > > http://lists.freedesktop.org/archives/spice-devel/2010-September/001237.html
> > > > >  
> > > > 
> > > > Ah ok thanks. Seems this patch got lost :-/
> > > > 
> > > 
> > > +1 to picking it up (even if it is for spicec and not spice-gtk)
> > > 
> > 
> > Seeing this and the patch traffic here, I'm wondering if spice team
> > wouldn't benefit from using gerrit, like RHEV/oVirt do. The nice thing
> > about it is that it leverages git so the actual workflow doesn't have to
> > change much when it is used.
> 
> I think Marc-Andre wanted / already uses git-bz (Owen Taylor's extension
> iirc) but maybe it's not contradictory. Can it be setup so bug email
> still goes to the mailing list? 

Sure. You can make a picture of traffic generated by gerrit on
engine-patches mailing list:
http://lists.ovirt.org/pipermail/engine-patches/

> can someone using mailing list to review
> a patch and reply with inline comments, like we do so far, interact with
> someone using gerrit?

I don't know this. I don't use it myself, I only attended a presentation
about it here in Brno.

David

> 
> > 
> > David
> > 
> > > > > 2. about spice on ios(ipad），are you have feasible scheme? can you 
> > > > > provide me with some info? how i can do it ?
> > > > 
> > > > I've already told you most of what I could say about it :) I'm not 
> > > > familiar
> > > > at all with iOS porting, so can't tell you more...
> > > > 
> > > > Christophe
> > > > 
> > > 
> > > 
> > > 
> > > > ___
> > > > Spice-devel mailing list
> > > > Spice-devel@lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > 
> > > ___
> > > Spice-devel mailing list
> > > Spice-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > 
> > -- 
> > 
> > David Jaša, RHCE
> > 
> > SPICE QE based in Brno
> > GPG Key: 22C33E24 
> > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> > 
> > 
> > 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Delay in Gimp when using qxl driver

[David Jaša]

Alon Levy píše v St 18. 01. 2012 v 12:18 +0200:
> On Wed, Jan 18, 2012 at 09:54:49AM +0100, Dominique Rodrigues wrote:
> > 
> > Le 18/01/2012 09:44, Alon Levy a écrit :
> > >On Wed, Jan 18, 2012 at 08:06:40AM +0100, Dominique Rodrigues wrote:
> > >>Hi,
> > >>
> > >>Since I use qxl driver in virtual desktop powered by qemu-kvm, I
> > >>found a strange problem with Gimp.
> > >>
> > >>After launching Gimp, open a new windows, and then try to draw
> > >>something. It appears that the drawing is very slow and does not
> > >>follow the mouse at all.
> > >>
> > >>It is the same if I use spicy, spicec or vnc to connect to my
> > >>virtual desktop.
> > >>
> > >>This problem does not appear with cirrus or vmware graphic drivers.
> > >>
> > >>I found that on any Linux distribution (CentOS, RHEL, Scientific
> > >>Linux, Debian, Ubuntu).
> > >>
> > >>I currently use :
> > >>- qemu-kvm 1.0 compiled with spice support
> > >>- spice-protocol 0.10.1
> > >>- spice 0.10
> > >>- spice-gtk 0.7
> > >>- xorg-qxl driver 0.16
> > >>
> > >>Is there any explanation for that ?
> > >I would assume it is qxl driver cpu bound on something, probably busy
> > >waiting on the command ring. Can you run perf top on the guest?
> > >
> > 
> > Indeed, during the drawing in Gimp, Xorg takes between 55% and 66% of CPU.
> > 
> > After, Xorg goes down to 0.3%.
> > 
> > (Test done on CentOS 6.2 guest, with 1280 Mb vRAM)
> 
> ok, can you drill down - you should be able to install the debug symbols
> for the qxl driver (xorg-x11-drv-qxl package) and see the specific
> functions that are taking the most time.
> 

Alon, is there similar procedure for Windows guests? I guess something
like this would help tracking down Autocad performance issues.

David

> > 
> > >>Regards,
> > >>
> > >>-- 
> > >>
> > >>
> > >>Dominique Rodrigues
> > >>
> > >>nanoClouD<http://www.nanocloud.com>
> > >>8, rue Lemercier
> > >>75017 Paris
> > >>France
> > >>standard : +33 1 77 69 64 38
> > >>529 002 743 R.C.S. Paris
> > >>begin:vcard
> > >>fn:Dominique Rodrigues
> > >>n:Rodrigues;Dominique
> > >>org:nanoClouD
> > >>adr:;;8, rue Lemercier;Paris;;75017;France
> > >>email;internet:dominique.rodrig...@nanocloud.com
> > >>title:Directeur Technique
> > >>tel;work:+33 (0) 1 77 69 64 38
> > >>tel;cell:+33 (0) 6 28 52 37 70
> > >>url:www.nanocloud.com
> > >>version:2.1
> > >>end:vcard
> > >>
> > >
> > >
> > >
> > >>___
> > >>Spice-devel mailing list
> > >>Spice-devel@lists.freedesktop.org
> > >>http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> > begin:vcard
> > fn:Dominique Rodrigues
> > n:Rodrigues;Dominique
> > org:nanoClouD
> > adr:;;8, rue Lemercier;Paris;;75017;France
> > email;internet:dominique.rodrig...@nanocloud.com
> > title:Directeur Technique
> > tel;work:+33 (0) 1 77 69 64 38
> > tel;cell:+33 (0) 6 28 52 37 70
> > url:www.nanocloud.com
> > version:2.1
> > end:vcard
> > 
> 
> 
> 
> 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Question about qemu spice memory use

[David Jaša]

Josh Bressers píše v Po 23. 01. 2012 v 12:24 -0500:
> Hello,
> 
> I'm not on the list, so if you could CC me on replies it would be most
> appreciated.
> 
> I tried to dig around for this bug but came up dry, I'm hoping someone
> here can point me in the right direction.
> 
> I was playing Netflix video under windows XP (the host OS is Fedora
> 16), my qemu memory use keeps climbing. If I switch the display to VNC
> or spice with the generic VGA adapter (my bug is seen when using the
> qlx adapter and drivers) the memory doesn't climb past what I would
> expect.
> 

Hi Josh,

How long do you play the video, what is on-screen resolution of video,
and what is the size of qemu memory overhead when it finishes?

David

> I have no idea how to even start looking into this so I can file a
> proper bug report. Do you folks have any tips?
> 
> Thanks.
> 

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Qemu-devel] Vioserial of Windows guest OS on Qemu 0.15

[David Jaša]

From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Thursday, January 19, 2012 5:39 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan Hajnoczi; spice-devel@lists.freedesktop.org; Alex 
> Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
> Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
> 0.15
> 
> On Thu, 2012-01-19 at 16:33 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Vadim,
> > 
> > It is SMP system.
> What about vioserial driver itself? 
> did you build it from sources or is
> it one, available through RHEL channels?
> 
> > 
> > -Original Message-
> > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > Sent: Thursday, January 19, 2012 3:58 PM
> > To: Charles.Tsai-蔡清海-研究發展部
> > Cc: Michael Roth; Stefan Hajnoczi; spice-devel@lists.freedesktop.org;
> > Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
> > Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS 
> > on Qemu 0.15
> > 
> > On Thu, 2012-01-19 at 09:41 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > Vadim,
> > > 
> > > I tested on Qemu 1.0.50. and found the VioSerial driver had problem to 
> > > install on 64-bit Win7 guest.
> > > During the driver installation, the system hung after the driver 
> > > being installed. After I rebooted the guest OS, the Vioserial driver 
> > > work. The hang system seemed to be found only during the driver 
> > > installation.
> > > 
> > On UP or SMP system?
> > > 
> > > -Original Message-
> > > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > > Sent: Wednesday, January 18, 2012 4:57 AM
> > > To: Michael Roth
> > > Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi; 
> > > spice-devel@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; 
> > > qemu-devel
> > > Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest 
> > > OS on Qemu 0.15
> > > 
> > > On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote:
> > > > On 01/15/2012 08:02 PM, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > > Vadim,
> > > > >
> > > > > Thank you for your prompt reply. Here are the information for our 
> > > > > test case.
> > > > >
> > > > >
> > > > > 1) we use the following command line to launch the guest OS
> > > > >
> > > > >
> > > > > /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
> > > > > 1,sockets=1,cores=1,threads=1 -name win_xp -uuid
> > > > > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults 
> > > > > -chardev 
> > > > > socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
> > > > > se rv er,nowait -mon
> > > > > chardev=charmonitor,id=monitor,mode=readline
> > > > > -rtc base=localtime
> > > > > -device
> > > > > virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
> > > > > dd
> > > > > r=
> > > > > 0x5.0x0 -drive
> > > > > file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
> > > > > at
> > > > > =r
> > > > > aw -device
> > > > > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
> > > > > in
> > > > > de
> > > > > x=1
> > > > > -netdev tap,fd=17,id=hostnet0
> > > > > -device
> > > > > rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
> > > > > mu
> > > > > lt
> > > > > ifunction=on,addr=0x3.0x0
> > > > > -chardev pty,id=charserial0
> > > > > -device isa-serial,chardev=charserial0,id=serial0
> > > > > -chardev spicevmc,id=charchannel0,name=vdagent
> > > > > -device
> > > > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
> > > > > =c
> > > > > ha
> > > > > nnel0,name=com.redhat.spice.0
> > > > > -usb -device usb-tablet,id=input0 -spice 
> > > > > port=5900,addr=0.0.0.0,disable-ticketing
> > > > > -vga qxl -global qxl-vga.vram_size=67108864 -device
> > > > > virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
> > > > > x4
> > > > > .0
> > > > > x0
> > > > >
> > > > >
> > > > >
> > > > > 2). In Guest Windows XP OS
> > > > >

Re: [Spice-devel] [Engine-devel] SPICE related features

[David Jaša]

Itamar Heim píše v Čt 09. 02. 2012 v 11:07 +0200:
> On 02/09/2012 11:05 AM, Hans de Goede wrote:
> > Hi,
> >
> > On 02/09/2012 09:33 AM, Itamar Heim wrote:
> >> On 02/09/2012 10:31 AM, Hans de Goede wrote:
> >
> > 
> >
> >>>> so this means we need to ask the user for linux guests if they want
> >>>> single head or multiple heads when they choose multi monitor?
> >>>
> >>> We could ask the user, but I don't think that that is a good idea.
> >>>
> >>>> this will cause their (single) head to spin...
> >>>
> >>> With which you seem to agree :)
> >>>
> >>>> any better UX we can suggest users?
> >>>
> >>> Yes, no UI at all, the current solution using multiple single monitor
> >>> pci cards means using Xinerama, which disables Xrandr, and thus allows
> >>> no dynamic adjustment of the monitor settings of the guest, instead
> >>> an xorg.conf file must be written (the linux agent can generate one
> >>> based on the current client monitor info) and Xorg needs to be
> >>> restarted.
> >>>
> >>> This is the result of the multiple pci cards which each 1 monitor model
> >>> we've been using for windows guests being a poor match for Linux guests.
> >>>
> >>> So we are working on adding support to drive multiple monitors from a
> >>> single qxl pci device. This requires changes on both the host and
> >>> guest side, but if both sides support it this configuration is much
> >>> better, so IMHO ovirt should just automatically enable it
> >>> if both the host (the cluster) and the guest support it.
> >>>
> >>> On the guest side, this is the current status:
> >>>
> >>> RHEL <= 6.1 no multi monitor support
> >>> RHEL 6.2(*) - 6.? multi monitor support using Xinerama (so 1
> >>> monitor/card, multiple cards)
> >>> RHEL >= 6.? multi monitor support using a single card with multiple
> >>> outputs
> >>>
> >>> Just like when exactly the new multi mon support will be available
> >>> for guests, it is a similar question mark for when it will be
> >>> available for
> >>> the host.
> >>
> >> this is the ovirt mailing list, so upstream versions are more relevant
> >> here.
> >> in any case, I have the same issue with backward compatibilty.
> >> say you fix this in fedora 17.
> >> user started a guest VM when host was fedora 16.
> >> admin upgraded host and changed cluster level to utilize new features.
> >> suddenly on next boot guest will move from 4 heads to single head? I'm
> >> guessing it will break user configuration.
> >> i.e., user should be able to choose to move to utilize the new mode?
> >
> > I see this as something which gets decided at vm creation time, and then
> > stored in the vm config. So if the vm gets created with a guest OS which
> > does not support multiple monitors per qxl device, or when the cluster does
> > not support it, it uses the old setup with 1 card / monitor. Even if the
> > guest OS or the cluster gets upgraded later.
> 
> so instead of letting user change this, we'd force this at vm creation 
> time? I'm not sure this is "friendlier".

I think that some history-watching logic & one UI bit could be the way
to go. The UI bit would be yet another select button that would let user
choose what graphic layout ("all monitors on single graphic card", "one
graphic card per monitor (legacy)"). The logic would be like this:
  * pre-existing guest that now supports new layout in 3.1 cluster
  * The guest uses 1 monitor, is swithed to 2+ --> new
  * The guest uses 2+ monitor layout --> old, big fat
warning when changing to the new that user should wipe
xinerama configuration in the guest
  * pre-existing guest in old or mixed cluster:
  * guest uses 2+ monitors --> old
  * guest is newly configured for 2+ monitors --> show
warning that user either has co configure xinerama or
use newer cluster --> old
  * new guest in new cluster:
  * --> new
  * if user switches to old, show warning
  * old guest in any type of cluster
  * --> old

This kind of behavior should provide sensible defaults, all valid
choices in all possible scenarios and it should not interfere too much
when admin chooses to do anything.

David

> __
> _
> Engine-devel mailing list
> engine-de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice configuration - problem with connection

[David Jaša]

   spice_server_add_interface: SPICE_INTERFACE_QXL
> red_worker_main: begin
> display_channel_create: create display channel
> 
> cursor_channel_create: create cursor channel/
> 
> 
> vm doesn't start, and I still can't connect from
> spicec to server
> 
> 
> Hi,
> 
> You can try running qemu-kvm instead of qemu. Please also send
> the client's log file ($home/.spicec/spicec.log)
> 
> 
> 
># On client's machine I install spice client
>yum -y install spice-client spice-protocol
>spicec -h 192.168.163.128 -p 5930
> 
>And I receive warning:
>failed to connect: no route to host (113)
> 
>I can ping server and host. Tcpdump shows that
> when I want to
>connect
>via spicec packages are sent, and host receive
> it.
> 
>What is wrong? And how can I resolve this
> problem?
> 
>Greetings,
>Daniel
> 
> 
> 
> 
>  _
>Spice-devel mailing list
>Spice-devel@lists.freedesktop.__org
>    <mailto:Spice-devel@lists.freedesktop.org>
> 
>  http://lists.freedesktop.org/__mailman/listinfo/spice-devel
> 
>  <http://lists.freedesktop.org/mailman/listinfo/spice-devel>
> 
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Windows binary download?

[David Jaša]

George Pyle píše v Čt 09. 02. 2012 v 11:49 -0800:
> Is there a binary download of spice-gtk for Windows. I don't have a
> Windows development system but was asked for a Windows client. I only
> saw an older, non-gtk windows download. Or at least that is what I
> thought I saw.
> 

Hi George,

the newly built binary can be found here:
http://elmarco.fedorapeople.org/virt-viewer-0.4.2.exe

HTH,

David

> 
> Thanks,
> 
> 
> George
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] spice configuration - problem with connection

[David Jaša]

Daniel Parnak píše v Po 13. 02. 2012 v 16:57 +0100:
> nmap 192.168.163.179
> 
> Starting Nmap 5.51 ( http://nmap.org ) at 2012-02-13 09:50 EST
> Nmap scan report for 192.168.163.179
> Host is up (0.00024s latency).
> All 1000 scanned ports on 192.168.163.179 are filtered
> MAC Address: 00:0C:29:E7:6B:6F (VMware)
> 
> 
> 
> 
> Nmap done: 1 IP address (1 host up) scanned in 5.20 seconds
> 
> 

This is your reply. Verify that iptables is not blocking incoming
connection to your port. If you're not sure how, please paste here
"iptables -n -v -L" output (from terminal at least 110 chars wide,
please, for sake of readability ;-))

> 
> image.png
> or maybe I should conect to 192.168.2.15 ?

no. spice server listens on host address:

   +--+
   | guest VM |
   +--+

+--+   +---+
| client   | <--- network ---> | server|
| .163.129 |   | .163.179:5930 |
+--+   +---+


David

PS: please, could you send your emails in plain text? It would make CLI
pastes more readable.
> 
> 
> 2012/2/13 David Jaša 
> Daniel Parnak píše v Po 13. 02. 2012 v 12:25 +0100:
> > # /home/liveuser/.spicec/spicec.log
> >
> > 1329134774 INFO [2196:2196] Application::main: starting
> 0.10.1
> > 1329134774 INFO [2196:2196] Application::main: command line:
> spicec -h
> > 192.168.163.179 -p 5930
> > 1329134774 INFO [2196:2196] init_key_map: using evdev
> mapping
> > 1329134774 INFO [2196:2196] MultyMonScreen::MultyMonScreen:
> > platform_win: 52428801
> > 1329134774 INFO [2196:2196] GUI::GUI:
> > 1329134775 INFO [2196:2196] ForeignMenu::ForeignMenu:
> Creating a
> > foreign menu connection /tmp/SpiceForeignMenu-2196.uds
> > 1329134775 INFO [2196:2197] RedPeer::connect_to_peer:
> Connect failed:
> > No route to host (113)
> > 1329134775 WARN [2196:2197] RedChannel::run: failed to
> connect: No
> > route to host (113)
> > 1329134775 INFO [2196:2196] main: Spice client terminated
> (exitcode =
> > 3)
> > 1329134778 INFO [2199:2199] Application::main: starting
> 0.10.1
> > 1329134778 INFO [2199:2199] Application::main: command line:
> spicec -h
> > 192.168.163.179 -p 5930
> > 1329134778 INFO [2199:2199] init_key_map: using evdev
> mapping
> > 1329134778 INFO [2199:2199] MultyMonScreen::MultyMonScreen:
> > platform_win: 52428801
> > 1329134778 INFO [2199:2199] GUI::GUI:
> > 1329134778 INFO [2199:2199] ForeignMenu::ForeignMenu:
> Creating a
> > foreign menu connection /tmp/SpiceForeignMenu-2199.uds
> > 1329134778 INFO [2199:2200] RedPeer::connect_to_peer:
> Connect failed:
> > No route to host (113)
> > 1329134778 WARN [2199:2200] RedChannel::run: failed to
> connect: No
> > route to host (113)
> > 1329134778 INFO [2199:2199] main: Spice client terminated
> (exitcode =
> > 3)
> >
> > # I've installed qemu-kvm but when I try to run qemu-kvm
> shows this:
> >
> > Could not access KVM kernel module: No such file or
> directory
> > failed to initialize KVM: No such file or directory
> > No accelerator found!
> >
> 
> This is expected, as you run qemu in VM (IIUC your first
> mail). Can you
> verify with nmap that the host is really reachable?
> 
> > # How is qemu connected to hosts network?
> >
> 
> 
> qemu listens on defined address (-spice
> addr=,port=,...).
> When not specified, default address is 0.0.0.0 (all ivp4
> addresses).
> 
> The different story is networking of VM, there are more
> possible
> approaches - consult qemu's manual page for them.
> 
> David
> >
> >
> > 2012/2/13 Yonit Halperin 
> > On 02/12/2012 11:39 AM, Daniel Parnak wrote:
> > 2012/2/12 Yonit Halperin
>  > <mailto:yhalp...@redhat.com>>
> >
> >
> >O

Re: [Spice-devel] spice configuration - problem with connection

[David Jaša]

Daniel, 

let us also know if you fix it yourself. I'm pretty curious how
qemu-kvm/spice will run on top of another hypervisor! :)

David


David Jaša píše v Po 13. 02. 2012 v 17:25 +0100:
> Daniel Parnak píše v Po 13. 02. 2012 v 16:57 +0100:
> > nmap 192.168.163.179
> > 
> > Starting Nmap 5.51 ( http://nmap.org ) at 2012-02-13 09:50 EST
> > Nmap scan report for 192.168.163.179
> > Host is up (0.00024s latency).
> > All 1000 scanned ports on 192.168.163.179 are filtered
> > MAC Address: 00:0C:29:E7:6B:6F (VMware)
> > 
> > 
> > 
> > 
> > Nmap done: 1 IP address (1 host up) scanned in 5.20 seconds
> > 
> > 
> 
> This is your reply. Verify that iptables is not blocking incoming
> connection to your port. If you're not sure how, please paste here
> "iptables -n -v -L" output (from terminal at least 110 chars wide,
> please, for sake of readability ;-))
> 
> > 
> > image.png
> > or maybe I should conect to 192.168.2.15 ?
> 
> no. spice server listens on host address:
> 
>+--+
>| guest VM |
>+--+
> 
> +--+   +---+
> | client   | <--- network ---> | server|
> | .163.129 |   | .163.179:5930 |
> +--+   +---+
> 
> 
> David
> 
> PS: please, could you send your emails in plain text? It would make CLI
> pastes more readable.
> > 
> > 
> > 2012/2/13 David Jaša 
> > Daniel Parnak píše v Po 13. 02. 2012 v 12:25 +0100:
> > > # /home/liveuser/.spicec/spicec.log
> > >
> > > 1329134774 INFO [2196:2196] Application::main: starting
> > 0.10.1
> > > 1329134774 INFO [2196:2196] Application::main: command line:
> > spicec -h
> > > 192.168.163.179 -p 5930
> > > 1329134774 INFO [2196:2196] init_key_map: using evdev
> > mapping
> > > 1329134774 INFO [2196:2196] MultyMonScreen::MultyMonScreen:
> > > platform_win: 52428801
> > > 1329134774 INFO [2196:2196] GUI::GUI:
> > > 1329134775 INFO [2196:2196] ForeignMenu::ForeignMenu:
> > Creating a
> > > foreign menu connection /tmp/SpiceForeignMenu-2196.uds
> > > 1329134775 INFO [2196:2197] RedPeer::connect_to_peer:
> > Connect failed:
> > > No route to host (113)
> > > 1329134775 WARN [2196:2197] RedChannel::run: failed to
> > connect: No
> > > route to host (113)
> > > 1329134775 INFO [2196:2196] main: Spice client terminated
> > (exitcode =
> > > 3)
> > > 1329134778 INFO [2199:2199] Application::main: starting
> > 0.10.1
> > > 1329134778 INFO [2199:2199] Application::main: command line:
> > spicec -h
> > > 192.168.163.179 -p 5930
> > > 1329134778 INFO [2199:2199] init_key_map: using evdev
> > mapping
> > > 1329134778 INFO [2199:2199] MultyMonScreen::MultyMonScreen:
> > > platform_win: 52428801
> > > 1329134778 INFO [2199:2199] GUI::GUI:
> > > 1329134778 INFO [2199:2199] ForeignMenu::ForeignMenu:
> > Creating a
> > > foreign menu connection /tmp/SpiceForeignMenu-2199.uds
> > > 1329134778 INFO [2199:2200] RedPeer::connect_to_peer:
> > Connect failed:
> > > No route to host (113)
> > > 1329134778 WARN [2199:2200] RedChannel::run: failed to
> > connect: No
> > > route to host (113)
> > > 1329134778 INFO [2199:2199] main: Spice client terminated
> > (exitcode =
> > > 3)
> > >
> > > # I've installed qemu-kvm but when I try to run qemu-kvm
> > shows this:
> > >
> > > Could not access KVM kernel module: No such file or
> > directory
> > > failed to initialize KVM: No such file or directory
> > > No accelerator found!
> > >
> > 
> > This is expected, as you run qemu in VM (IIUC your first
> > mail). Can you
> > verify with nmap that the host is really reachable?
> > 
> > > # How is qemu connected to hosts network?
> > >
> > 
> > 
> >  

Re: [Spice-devel] spice configuration - problem with connection

[David Jaša]

Hi Daniel,

Daniel Parnak píše v Po 13. 02. 2012 v 13:29 -0500:
> sorry, is it better now? ;)
> 
> iptables -n -v -L
> 
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0udp dpt:53
> 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0tcp dpt:53
> 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0udp dpt:67
> 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0tcp dpt:67
> 65157   90M ACCEPT all  --  *  *   0.0.0.0/0
> 0.0.0.0/0state RELATED,ESTABLISHED
> 148 ACCEPT icmp --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 5   220 ACCEPT all  --  lo *   0.0.0.0/0
> 0.0.0.0/0

^^^ no rule specifically allowing tcp port 5930 

>44 10352 REJECT all  --  *  *   0.0.0.0/0
> 0.0.0.0/0reject-with icmp-host-prohibited

^^^ rejecting anything else

Daniel, either disable iptables completely if you don't care about
firewalling:
service iptables stop
chkconfig iptables off

or add rule to /etc/sysconfig/iptables allowing connections to the port
or port range into INPUT chain somewhere between ESTABLISHED,RELATED
rule and last REJECT rule:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# other rules
# this in case of single port to be opened:
-A INPUT -p tcp --dport 5930 -j ACCEPT
# this in case of port range:
-A INPUT -p tcp -m multiport --dports 5900:6000 -j ACCEPT
# this must be the last rule in INPUT chain:
-A INPUT -j REJECT --reject-with icmp-host-prohibited

David

PS: it is definitely better ;)

> 
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all  --  *  virbr0  0.0.0.0/0
> 192.168.122.0/24 state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  virbr0 *   192.168.122.0/24
> 0.0.0.0/0
> 0 0 ACCEPT all  --  virbr0 virbr0  0.0.0.0/0
> 0.0.0.0/0
> 0 0 REJECT all  --  *  virbr0  0.0.0.0/0
> 0.0.0.0/0reject-with icmp-port-unreachable
> 0 0 REJECT all  --  virbr0 *   0.0.0.0/0
> 0.0.0.0/0reject-with icmp-port-unreachable
> 0 0 REJECT all  --  *  *   0.0.0.0/0
> 0.0.0.0/0reject-with icmp-host-prohibited
> 
> Chain OUTPUT (policy ACCEPT 2850 packets, 401K bytes)
>  pkts bytes target prot opt in out source   
> destination
> 
> 
> 
> 2012/2/13 David Jaša 
> >
> > Daniel,
> >
> > let us also know if you fix it yourself. I'm pretty curious how
> > qemu-kvm/spice will run on top of another hypervisor! :)
> >
> > David
> >
> >
> > David Jaša píše v Po 13. 02. 2012 v 17:25 +0100:
> > > Daniel Parnak píše v Po 13. 02. 2012 v 16:57 +0100:
> > > > nmap 192.168.163.179
> > > >
> > > > Starting Nmap 5.51 ( http://nmap.org ) at 2012-02-13 09:50 EST
> > > > Nmap scan report for 192.168.163.179
> > > > Host is up (0.00024s latency).
> > > > All 1000 scanned ports on 192.168.163.179 are filtered
> > > > MAC Address: 00:0C:29:E7:6B:6F (VMware)
> > > >
> > > >
> > > >
> > > >
> > > > Nmap done: 1 IP address (1 host up) scanned in 5.20 seconds
> > > >
> > > >
> > >
> > > This is your reply. Verify that iptables is not blocking incoming
> > > connection to your port. If you're not sure how, please paste here
> > > "iptables -n -v -L" output (from terminal at least 110 chars wide,
> > > please, for sake of readability ;-))
> > >
> > > >
> > > > image.png
> > > > or maybe I should conect to 192.168.2.15 ?
> > >
> > > no. spice server listens on host address:
> > >
> > >    +--+
> > >| guest VM |
> > >+--+
> > >
> > > +--+   +---+
> > > | client   | <--- network ---> | server|
> > > | .163.129 |   | .163.179:5930 |
> > > +--+   +---+
> > >
> > >
> > > David
> > >
> > > PS: please, could you send your emails in plain text? It would make CLI
> > > pastes more readable.
> > > >
> > > >
> > > > 2012/2/13 David Jaša 

Re: [Spice-devel] [PATCH] Use non-zero data for initial ping

[David Jaša]

Yaniv Kaul píše v Po 13. 02. 2012 v 23:11 +0200:
> While the best thing would have been to pass the first image already to 
> the client using those 256K (and calculate the bandwidth based on the 
> first data passed to the client and continue to do so, as the protocol 
> continues),

upstream & downstream bugs requesting it:
http://bugs.freedesktop.org/show_bug.cgi?id=43756
https://bugzilla.redhat.com/show_bug.cgi?id=787197

David

>  the next best thing would probably be pass *some* image to 
> the client - some JPEG compressed logo or something.
> This is:
> (1) already quite compressed.
> (2) useful in some way.
> (3) probably 'cheaper' than creating some random data.
> 
> I think QEMU has this feature (off by default) to load a bootsplash 
> image as part of the BIOS. I wonder if it can be somehow re-used.
> 
> Y.
> 
> 
> On 02/13/2012 09:48 PM, Dan McGee wrote:
> > This prevents compression over things such as VPN links misleading us on
> > available bandwidth. The page used before was 4K worth of zeroes, which
> > isn't a very realistic test at all.
> >
> > We now use a generated sequence of bytes that vary in value and offset
> > between consecutive values, causing compression programs to have a much
> > harder time reducing our ping packets to nothing.
> >
> > Here are some comparisons of before/after using a small standalone
> > program that generates bytes in the same fashion:
> >
> > Before:
> >  4096 zerodata
> >  43   zerodata.bz2
> >  38   zerodata.gz
> >  92   zerodata.xz
> >
> > After:
> >  4096 seqdata
> >  1213 seqdata.bz2
> >  4119 seqdata.gz
> >  3208 seqdata.xz
> >
> > Signed-off-by: Dan McGee
> > ---
> >
> > This was a TODO item on the following page:
> > http://spice-space.org/page/Features/Bandwidth_monitoring
> >
> > The standalone test program is below if anyone wants to try it out; simply 
> > pass
> > '4096' or similar as the first argument and you will get 4096 "random" 
> > bytes on
> > stdout that you can play with.
> >
> > #include
> > #include
> >
> > int main(int argc, char *argv[])
> > {
> > int i, total;
> >
> > total = atoi(argv[1]);
> >
> > for(i = 0; i<  total; i++) {
> > div_t result = div(i, 256);
> > if(result.quot % 2 == 0) {
> > fputc((result.quot + 1) * result.rem, stdout);
> > } else {
> > fputc(512 - (result.quot * result.rem), stdout);
> > }
> > }
> > return 0;
> > }
> >
> >
> >   server/main_channel.c |   24 
> >   1 files changed, 16 insertions(+), 8 deletions(-)
> >
> > diff --git a/server/main_channel.c b/server/main_channel.c
> > index f7e1ab0..2ce20c0 100644
> > --- a/server/main_channel.c
> > +++ b/server/main_channel.c
> > @@ -22,6 +22,7 @@
> >   #include
> >   #include
> >   #include
> > +#include
> >   #include
> >   #include
> >   #include
> > @@ -45,8 +46,6 @@
> >   #include "red_channel.h"
> >   #include "generated_marshallers.h"
> >
> > -#define ZERO_BUF_SIZE 4096
> > -
> >   #define REDS_MAX_SEND_IOVEC 100
> >
> >   #define NET_TEST_WARMUP_BYTES 0
> > @@ -54,8 +53,6 @@
> >
> >   #define PING_INTERVAL (1000 * 10)
> >
> > -static uint8_t zero_page[ZERO_BUF_SIZE] = {0};
> > -
> >   typedef struct RedsOutItem RedsOutItem;
> >   struct RedsOutItem {
> >   PipeItem base;
> > @@ -335,17 +332,28 @@ static void 
> > main_channel_marshall_ping(SpiceMarshaller *m, int size, int ping_id
> >   {
> >   struct timespec time_space;
> >   SpiceMsgPing ping;
> > +uint8_t *ping_data;
> > +int i;
> >
> >   ping.id = ping_id;
> >   clock_gettime(CLOCK_MONOTONIC,&time_space);
> >   ping.timestamp = time_space.tv_sec * 100LL + time_space.tv_nsec / 
> > 1000LL;
> >   spice_marshall_msg_ping(m,&ping);
> >
> > -while (size>  0) {
> > -int now = MIN(ZERO_BUF_SIZE, size);
> > -size -= now;
> > -spice_marshaller_add_ref(m, zero_page, now);
> > +ping_data = spice_malloc(size);
> > +/* this produces ascending and descending byte runs which vary in 
> > offset
> > + * every 512 bytes, preventing prevents compression from being able to
> > + * 

Re: [Spice-devel] spice configuration - problem with connection

[David Jaša]

David Jaša píše v Út 14. 02. 2012 v 12:12 +0100:
> Hi Daniel,
> 
> Daniel Parnak píše v Po 13. 02. 2012 v 13:29 -0500:
> > sorry, is it better now? ;)
> > 
> > iptables -n -v -L
> > 
> > Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target prot opt in out source
> > destination
> > 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
> > 0.0.0.0/0udp dpt:53
> > 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
> > 0.0.0.0/0tcp dpt:53
> > 0 0 ACCEPT udp  --  virbr0 *   0.0.0.0/0
> > 0.0.0.0/0udp dpt:67
> > 0 0 ACCEPT tcp  --  virbr0 *   0.0.0.0/0
> > 0.0.0.0/0tcp dpt:67
> > 65157   90M ACCEPT all  --  *  *   0.0.0.0/0
> > 0.0.0.0/0state RELATED,ESTABLISHED
> > 148 ACCEPT icmp --  *  *   0.0.0.0/0
> > 0.0.0.0/0
> > 5   220 ACCEPT all  --  lo *   0.0.0.0/0
> > 0.0.0.0/0
> 
> ^^^ no rule specifically allowing tcp port 5930 
> 
> >44 10352 REJECT all  --  *  *   0.0.0.0/0
> > 0.0.0.0/0reject-with icmp-host-prohibited
> 
> ^^^ rejecting anything else
> 
> Daniel, either disable iptables completely if you don't care about
> firewalling:
> service iptables stop
> chkconfig iptables off
> 
> or add rule to /etc/sysconfig/iptables allowing connections to the port
> or port range into INPUT chain somewhere between ESTABLISHED,RELATED
> rule and last REJECT rule:
> 
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> # other rules
> # this in case of single port to be opened:
> -A INPUT -p tcp --dport 5930 -j ACCEPT
> # this in case of port range:
> -A INPUT -p tcp -m multiport --dports 5900:6000 -j ACCEPT
> # this must be the last rule in INPUT chain:
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> 

forgot to add - after you edit the file, you have to apply the changes:
service iptables restart

David

> David
> 
> PS: it is definitely better ;)
> 
> > 
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target prot opt in out source
> > destination
> > 0 0 ACCEPT all  --  *  virbr0  0.0.0.0/0
> > 192.168.122.0/24 state RELATED,ESTABLISHED
> > 0 0 ACCEPT all  --  virbr0 *   192.168.122.0/24
> > 0.0.0.0/0
> > 0 0 ACCEPT all  --  virbr0 virbr0  0.0.0.0/0
> > 0.0.0.0/0
> > 0 0 REJECT all  --  *  virbr0  0.0.0.0/0
> > 0.0.0.0/0reject-with icmp-port-unreachable
> > 0 0 REJECT all  --  virbr0 *   0.0.0.0/0
> > 0.0.0.0/0reject-with icmp-port-unreachable
> > 0 0 REJECT all  --  *  *   0.0.0.0/0
> > 0.0.0.0/0reject-with icmp-host-prohibited
> > 
> > Chain OUTPUT (policy ACCEPT 2850 packets, 401K bytes)
> >  pkts bytes target prot opt in out source   
> > destination
> > 
> > 
> > 
> > 2012/2/13 David Jaša 
> > >
> > > Daniel,
> > >
> > > let us also know if you fix it yourself. I'm pretty curious how
> > > qemu-kvm/spice will run on top of another hypervisor! :)
> > >
> > > David
> > >
> > >
> > > David Jaša píše v Po 13. 02. 2012 v 17:25 +0100:
> > > > Daniel Parnak píše v Po 13. 02. 2012 v 16:57 +0100:
> > > > > nmap 192.168.163.179
> > > > >
> > > > > Starting Nmap 5.51 ( http://nmap.org ) at 2012-02-13 09:50 EST
> > > > > Nmap scan report for 192.168.163.179
> > > > > Host is up (0.00024s latency).
> > > > > All 1000 scanned ports on 192.168.163.179 are filtered
> > > > > MAC Address: 00:0C:29:E7:6B:6F (VMware)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Nmap done: 1 IP address (1 host up) scanned in 5.20 seconds
> > > > >
> > > > >
> > > >
> > > > This is your reply. Verify that iptables is not blocking incoming
> > > > connection to your port. If you're not sure how, please paste here
> > > > "iptables -n -v -L" output (from terminal at least 110 chars wide,
> > > > please, for sake of readability ;-))
> > > >
> > > > >
> > > > > image.png
> > > > > or maybe I should conect to 192.168.2.15 ?
> > > >
> > > > no. spice server listens on host ad

Re: [Spice-devel] spice configuration - problem with connection

[David Jaša]

Gianluca Cecchi píše v Út 14. 02. 2012 v 16:03 +0100:
> On Tue, Feb 14, 2012 at 12:23 PM, David Jaša  wrote:
> > David Jaša píše v Út 14. 02. 2012 v 12:12 +0100:
> [snip]
> >
> > forgot to add - after you edit the file, you have to apply the changes:
> > service iptables restart
> 
> And after that, in this case
> service libvirtd reload
> to have libvirtd iptables rules applied again...

Not necessary here, as there is no libvirt networking involved (VM uses
-net user which is not affected by FORWARD rules).

David

> _
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Engine-devel] SPICE related features

[David Jaša]

Oved Ourfalli píše v St 15. 02. 2012 v 06:25 -0500:
> 
> - Original Message -
> > From: "Dor Laor" 
> > To: spice-devel@lists.freedesktop.org, engine-de...@ovirt.org
> > Cc: "David Jaša" , "Oved Ourfalli" , 
> > "Hans de Goede" 
> > Sent: Wednesday, February 15, 2012 12:52:46 PM
> > Subject: Re: [Engine-devel] [Spice-devel]  SPICE related features
> > 
> > On 02/09/2012 02:50 PM, David Jaša wrote:
> > > Itamar Heim píše v Čt 09. 02. 2012 v 11:07 +0200:
> > >> On 02/09/2012 11:05 AM, Hans de Goede wrote:
> > >>> Hi,
> > >>>
> > >>> On 02/09/2012 09:33 AM, Itamar Heim wrote:
> > >>>> On 02/09/2012 10:31 AM, Hans de Goede wrote:
> > >>>
> > >>> 
> > >>>
> > >>>>>> so this means we need to ask the user for linux guests if they
> > >>>>>> want
> > >>>>>> single head or multiple heads when they choose multi monitor?
> > >>>>>
> > >>>>> We could ask the user, but I don't think that that is a good
> > >>>>> idea.
> > >>>>>
> > >>>>>> this will cause their (single) head to spin...
> > >>>>>
> > >>>>> With which you seem to agree :)
> > >>>>>
> > >>>>>> any better UX we can suggest users?
> > >>>>>
> > >>>>> Yes, no UI at all, the current solution using multiple single
> > >>>>> monitor
> > >>>>> pci cards means using Xinerama, which disables Xrandr, and thus
> > >>>>> allows
> > >>>>> no dynamic adjustment of the monitor settings of the guest,
> > >>>>> instead
> > >>>>> an xorg.conf file must be written (the linux agent can generate
> > >>>>> one
> > >>>>> based on the current client monitor info) and Xorg needs to be
> > >>>>> restarted.
> > >>>>>
> > >>>>> This is the result of the multiple pci cards which each 1
> > >>>>> monitor model
> > >>>>> we've been using for windows guests being a poor match for
> > >>>>> Linux guests.
> > >>>>>
> > >>>>> So we are working on adding support to drive multiple monitors
> > >>>>> from a
> > >>>>> single qxl pci device. This requires changes on both the host
> > >>>>> and
> > >>>>> guest side, but if both sides support it this configuration is
> > >>>>> much
> > >>>>> better, so IMHO ovirt should just automatically enable it
> > >>>>> if both the host (the cluster) and the guest support it.
> > >>>>>
> > >>>>> On the guest side, this is the current status:
> > >>>>>
> > >>>>> RHEL<= 6.1 no multi monitor support
> > >>>>> RHEL 6.2(*) - 6.? multi monitor support using Xinerama (so 1
> > >>>>> monitor/card, multiple cards)
> > >>>>> RHEL>= 6.? multi monitor support using a single card with
> > >>>>> multiple
> > >>>>> outputs
> > >>>>>
> > >>>>> Just like when exactly the new multi mon support will be
> > >>>>> available
> > >>>>> for guests, it is a similar question mark for when it will be
> > >>>>> available for
> > >>>>> the host.
> > >>>>
> > >>>> this is the ovirt mailing list, so upstream versions are more
> > >>>> relevant
> > >>>> here.
> > >>>> in any case, I have the same issue with backward compatibilty.
> > >>>> say you fix this in fedora 17.
> > >>>> user started a guest VM when host was fedora 16.
> > >>>> admin upgraded host and changed cluster level to utilize new
> > >>>> features.
> > >>>> suddenly on next boot guest will move from 4 heads to single
> > >>>> head? I'm
> > >>>> guessing it will break user configuration.
> > >>>> i.e., user should be able to choose to move to utilize the new
> > >>>> mode?
> > >>>
> > >>> I see this as somethin

Re: [Spice-devel] [Engine-devel] SPICE related features

[David Jaša]

Oved Ourfalli píše v St 15. 02. 2012 v 08:06 -0500:
> 
> - Original Message -
> > From: "Alon Levy" 
> > To: "Oved Ourfalli" 
> > Cc: "David Jaša" , spice-devel@lists.freedesktop.org, 
> > dl...@redhat.com, engine-de...@ovirt.org
> > Sent: Wednesday, February 15, 2012 2:51:47 PM
> > Subject: Re: [Engine-devel] [Spice-devel]SPICE related features
> > 
> > On Wed, Feb 15, 2012 at 06:25:37AM -0500, Oved Ourfalli wrote:
> > > 
> > > 
> > > - Original Message -
> > > > From: "Dor Laor" 
> > > > To: spice-devel@lists.freedesktop.org, engine-de...@ovirt.org
> > > > Cc: "David Jaša" , "Oved Ourfalli"
> > > > , "Hans de Goede" 
> > > > Sent: Wednesday, February 15, 2012 12:52:46 PM
> > > > Subject: Re: [Engine-devel] [Spice-devel]  SPICE related features
> > > > 
> > > > On 02/09/2012 02:50 PM, David Jaša wrote:
> > > > > Itamar Heim píše v Čt 09. 02. 2012 v 11:07 +0200:
> > > > >> On 02/09/2012 11:05 AM, Hans de Goede wrote:
> > > > >>> Hi,
> > > > >>>
> > > > >>> On 02/09/2012 09:33 AM, Itamar Heim wrote:
> > > > >>>> On 02/09/2012 10:31 AM, Hans de Goede wrote:
> > > > >>>
> > > > >>> 
> > > > >>>
> > > > >>>>>> so this means we need to ask the user for linux guests if
> > > > >>>>>> they
> > > > >>>>>> want
> > > > >>>>>> single head or multiple heads when they choose multi
> > > > >>>>>> monitor?
> > > > >>>>>
> > > > >>>>> We could ask the user, but I don't think that that is a
> > > > >>>>> good
> > > > >>>>> idea.
> > > > >>>>>
> > > > >>>>>> this will cause their (single) head to spin...
> > > > >>>>>
> > > > >>>>> With which you seem to agree :)
> > > > >>>>>
> > > > >>>>>> any better UX we can suggest users?
> > > > >>>>>
> > > > >>>>> Yes, no UI at all, the current solution using multiple
> > > > >>>>> single
> > > > >>>>> monitor
> > > > >>>>> pci cards means using Xinerama, which disables Xrandr, and
> > > > >>>>> thus
> > > > >>>>> allows
> > > > >>>>> no dynamic adjustment of the monitor settings of the guest,
> > > > >>>>> instead
> > > > >>>>> an xorg.conf file must be written (the linux agent can
> > > > >>>>> generate
> > > > >>>>> one
> > > > >>>>> based on the current client monitor info) and Xorg needs to
> > > > >>>>> be
> > > > >>>>> restarted.
> > > > >>>>>
> > > > >>>>> This is the result of the multiple pci cards which each 1
> > > > >>>>> monitor model
> > > > >>>>> we've been using for windows guests being a poor match for
> > > > >>>>> Linux guests.
> > > > >>>>>
> > > > >>>>> So we are working on adding support to drive multiple
> > > > >>>>> monitors
> > > > >>>>> from a
> > > > >>>>> single qxl pci device. This requires changes on both the
> > > > >>>>> host
> > > > >>>>> and
> > > > >>>>> guest side, but if both sides support it this configuration
> > > > >>>>> is
> > > > >>>>> much
> > > > >>>>> better, so IMHO ovirt should just automatically enable it
> > > > >>>>> if both the host (the cluster) and the guest support it.
> > > > >>>>>
> > > > >>>>> On the guest side, this is the current status:
> > > > >>>>>
> > > > >>>>> RHEL<= 6.1 no multi monitor support
> > > > >>>>> RHEL 6.2(*) - 6.? multi monitor support using Xiner

Re: [Spice-devel] Problem to render cursor in SDL/VNC using QXL driver

[David Jaša]

Fabiano Fidêncio píše v St 22. 02. 2012 v 02:53 -0200:
> Howdy!
> 
> I found out the problem. It was a regression introduced by commit
> 075360945860ad9bdd491921954b383bf762b0e5, in QEMU (almost had a
> birthday).
> There's one attached patch, that reverts the problematic commit and
> fixes the conflicts. So, could you take a look and apply?
> 

Hi Fabiano,

I guess that you should send the patch to qemu-de...@nongnu.org and only
CC this list in order to get it pushed to qemu.

David

> Best Regards,
> --
> Fabiano Fidêncio
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] xpi, spicec, remote-viewer & update-alternatives

[David Jaša]

Hi,

there is a problem with running the controller driven clients:

  * spice-xpi doesn't pass any option to spice-xpi-client symlink
  * remote-viewer expects --spice-controller option
  * spicec expects --controller option
  * spice-xpi doesn't know which client is target of
spice-xpi-client symlink

The result is that current xpi can not run any client. I can see two
possibilites of getting this working again:

  * remote-viewer's --spice-controller option will change to
--controller, spice-xpi will always run spice-xpi-client with
--controller option
  * some magic is added to XPI to recognize client to which
spice-xpi-client symlink points to and based on that, decide if
it should be run with --controller or with --spice-controller.
(I don't like this option, think about slightly different paths
in different distros)
  * remote-viewer is modified so that it behaves like when run with
--spice-controller option if file speficied SPICE_XPI_SOCKET
exists, ignoring other options

I don't want to file concrete bugs until it is decided what is the best
way.

David

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] xpi, spicec, remote-viewer & update-alternatives

[David Jaša]

Daniel P. Berrange píše v Čt 23. 02. 2012 v 14:50 +:
> On Thu, Feb 23, 2012 at 03:38:28PM +0100, David Jaša wrote:
> > Hi,
> > 
> > there is a problem with running the controller driven clients:
> > 
> >   * spice-xpi doesn't pass any option to spice-xpi-client symlink
> >   * remote-viewer expects --spice-controller option
> 
> This shouldn't be any problem, as the spice-xpi-client alternative
> is not pointing directly at /usr/bin/remote-viewer. Instead it
> points to /usr/libexec/spice-xpi-client-remote-viewer.  This wrapper
> script does *not* expect any option, and will automatically add in
> --spice-controller before invoking remote-viewer.

Ah, thanks for pointer. I updated virt-viewer, created analogous script
for spicec and now the switching works for me without any more changes
needed.

David

> 
> >   * spicec expects --controller option
> >   * spice-xpi doesn't know which client is target of
> > spice-xpi-client symlink
> > 
> > The result is that current xpi can not run any client. I can see two
> > possibilites of getting this working again:
> > 
> >   * remote-viewer's --spice-controller option will change to
> > --controller, spice-xpi will always run spice-xpi-client with
> > --controller option
> >   * some magic is added to XPI to recognize client to which
> > spice-xpi-client symlink points to and based on that, decide if
> > it should be run with --controller or with --spice-controller.
> > (I don't like this option, think about slightly different paths
> > in different distros)
> >   * remote-viewer is modified so that it behaves like when run with
> > --spice-controller option if file speficied SPICE_XPI_SOCKET
> > exists, ignoring other options
> 
> AFAICT, there's no need for this, since 
> /usr/libexec/spice-xpi-client-remote-viewer
> already takes care of things
> 
> > I don't want to file concrete bugs until it is decided what is the best
> > way.
> 
> 
> Daniel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-xpi 3/4] Switch from log4cpp to glib

[David Jaša]

Marc-André Lureau píše v Pá 24. 02. 2012 v 12:18 +0100:
> Hi
> 
> On Fri, Feb 24, 2012 at 12:10 PM, Alon Levy  wrote:
> >
> > I was with you until you suggested to use ldpreload. Is there an actual
> > easy way to do this to redirect error messages somewhere?
> 
> ldpreload can be useful if you want to override and use your own g_log
> handler for debugging. I don't mean it should be used as a solution,
> in production..
> 
> You can redirect with normal redirection > | etc.. I use logger to
> redirect to syslog in the spice-xpi-client scripts for example.
> 
> > So how would we make sure there is a log file for SpiceXPI?
> 
> Tbh, I think there should be *no* log file, and it should use standard
> methods instead. stderr is redirected to .xsession-errors normally,
> but you should try to reproduce an issue by setting
> G_MESSAGES_DEBUG=SpiceXPI (and other domain), starting firefox and
> redirecting output to a file.
> 

I expect that logging of remote-viewer will be controlled in the same
manner - if so, it would help debugging of any issue.

Anyway, when spice-xpi gets ported to Windows, how can one achieve
redirection of log output to the file, analogous to this:
ENV_VAR=value firefox > log_file 2>&1

?

David

> 
> >>  if (NPN_InvokeDefault(m_instance, call_on_disconnected, args, 
> >> sizeof(args) / sizeof(args[0]), &void_result))
> >> -{
> >> -LOG_DEBUG("OnDisconnected successfuly called");
> >> -}
> >> +g_debug("OnDisconnected successfuly called");
> >
> > Why are you dropping the scope?
> 
> Just saving 4 empty lines. I thought about rewriting it to one line
> without condition too, ex:
> 
> g_debug("OnDisconnected: ", err != 0 ? "success" : "failed");
> 

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Announcing spice-protocol 0.10.1 aka the miniheader release

[David Jaša]

Hi,

the release lacks 0.10.1 tag in git. (I don't know if it has any other
meaning than that I can not recognize it as a release in cgit so quickly
but even then...)

David


Hans de Goede píše v Po 16. 01. 2012 v 19:49 +0100:
> Hi All,
> 
> I'm happy to announce spice-protocol-0.10.1
> 
> Major changes in 0.10.1
> ===
> * Add support for a header without sublist and serial (mini header)
> 
> You can download it here:
> http://spice-space.org/download.html
> 
> Regards,
> 
> Hans
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] How to install virtio-serial driver in guest OS (ubuntu 10.4 64)

[David Jaša]

Andrew Zhang píše v Čt 01. 03. 2012 v 23:16 -0500:
> Hi
> 
> Anybody know how to install virtio-serial driver in guest OS (ubuntu
> 10.4 64)?

the driver is a kernel driver so if your kernel doesn't recognize the
device, you either have to backport the driver to your current kernel or
(this is the better way), install a newer kernel from *updates or
*backports repository that already contains the driver. (I already
forgot what kernels are available for Ubuntu and what the repository
names are so YMMV.)

David


> -- 
> Thanks!
> Andrew
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Problem about qxl and vmc

[David Jaša]

Hi,

I'm curious about one detail of your setup:

wangfeng wangfeng píše v St 07. 03. 2012 v 17:22 +0800:
> 
> 
> Thank you all.
> I have another problem. I started a Win7 VM with vdagent and it worked
> well. Then I made a snapshot through libvirt by the following
> commands:
> #virsh save (id) win7.snp
> #virsh restore win7.snp
> When I reconnected the VM ,the mouse‘s moving seems to be some lags,
> or maybe missing some mouse nstructions. Have I made a mistake?
> 
> 
> Here is the libvirt xml :
> 
> 
>  xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
>   win7template
>   524288
>   524288
>   1
>   
> hvm
> 
>   
>   
> 
> 
> 
>   
>   
>   destroy
>   restart
>   restart
>   
> /usr/bin/qemu-kvm
> 
>   
>   
>   
>   
> 
> 
>function='0x1'/>
> 
> 
>   
>   
>function='0x0'/>
> 
> 
>   
> 
> 
>   
> 
>  
>  listen='192.168.12.236'>
>   

 ^^

Why do you force mouse to work in server mode? In my experience, it
severely harms Spice performance and leads to way worse user experience.

David

>   
> 
> 
>   
> 
> 
>   
>function='0x0'/>
>
> 
> 
>function='0x0'/>
> 
>   
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Qemu-devel] seamless migration with spice

[David Jaša]

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<->  server session.  Today spice client
> > creates a new session on migration, so there is simply no need to
> > maintain any state.  Drawback is that everything needs to be resent from
> > the server to the client.  Thats why we want be able to continue the
> > spice session, so the client caches will stay valid.
> >
> > Of course the spice-server on the migration target needs the session
> > state for that, i.e. know for example which bits the client has cached
> > which it hasn't.
> >
> >> If the state is stored in the server, wouldn't it be marshaled as part
> >> of the server's migration state?
> >
> > spice-server is stateless today when it comes to migration.  QXL handles
> > all (device) state, by keeping track of some commands (such as
> > create/destroy surface) which it needs to transfer on migration, and by
> > asking spice-server to render all surfaces on migration, which
> > effectively flushes the spice server state to qxl device memory.
> >
> > To transfer the client session state there are basically two options:
> >
> >(a) transfer it as part of the qemu migration data stream.  I don't
> >want have any details about the qemu migration implementation
> >and/or protocol in the spice-server library api, which basically
> >leaves a ugly "transfer-this-blob-for-me-please" style interface
> >as only option.
> >
> >(b) transfer it as part of the spice protocol.  As the spice
> >client has a connection to both source and target while the
> >migration runs we can send session state from the source host via
> >spice client to the target host.  This needs some form of
> >synchronization, to make sure both vmstate and spice migration
> >are completed when qemu on the source machine quits.
> 
> 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-implementing this to me the
> send a blob through the client approach is simply not acceptable from a
> security pov, also see my previous mail in this thread.
> 

In addition to security POV, it's also bad from network usage POV -
while network connection among hosts is gigabit or better, client may be
connected over high-latency low-bandwidth WAN. Sending any data through
client makes absolutely no sense in such cases.

David

> > I think (b) is the better approach.
> 
> I disagree. Note that there is more info to send over then just which
> surfaces / images are cached by the client. There also is things like
> partial complete agent channel messages, including how much bytes must be read
> to complete the command, etc.
> 
> IMHO (b) would only be acceptable if the data send through the client stops
> becoming a blob. Instead the client could simply send a list of all surface 
> ids,
> etc. which it has cached after it connects to / starts using the new host. 
> Note
> that the old hosts needs to send nothing for this, this is info the client 
> already
> has, also removing the need for synchronization. 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.
> 
> So I see 2 options
> 
> 1) Do (a), sending everything that way
> 2) Do (a) sending non client state that way; and
> let the client send state like which surfaces it has cached
> when the new session starts.
> 
> Regards,
> 
> Hans
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Users] Really need serious help with spice (its just not working !!) - attached ~/.spicec/spicec.log

[David Jaša]

Hi,

Itamar Heim píše v St 21. 03. 2012 v 17:28 +0200:
> cc'ing spice-devel
> 
> On 03/20/2012 07:01 PM, Morgan Cox wrote:
> > Hi.
> >
> > My Setup - 3 servers
> >
> > 1 Frontend (ovirt engine) - Fedora 16- external + local IP
> > 1 Ovirt node (using the node .iso)   - external + local IP
> > 1 NFS storage - external + local IP - I attached the storage using the
> > Local IP (10.0.0.190)
> >
> > I have launched firefox with -  SPICEC_LOG_LEVEL=0 firefox
> >
> > I create a VM, turn it on - click the spice console button - it crashes
> >
> > I can see
> >
> > Warning: failed to connect: Connection refused (111)
> >
> >   ~/.spicec/spicec.log  ( I have removed the IP / domain name)
> > -
> >
> >
> > 1332262683 INFO [5895:5895] Application::main: starting 0.10.0
> > 1332262683 DEBUG [5895:5895] Application::Application:
> > 1332262683 DEBUG [5895:5895] HotKeysParser::HotKeysParser: hotkeys =
> > toggle-fullscreen=shift+f11,release-cursor=shift+f12
> > 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> > 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = f11
> > 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> > 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = f12
> > 1332262683 DEBUG [5895:5895] Platform::init:
> > 1332262683 INFO [5895:5895] init_key_map: using evdev mapping
> > 1332262683 INFO [5895:5895] MultyMonScreen::MultyMonScreen:
> > platform_win: 104857601
> > 1332262683 INFO [5895:5895] ForeignMenu::ForeignMenu: Creating a foreign
> > menu connection /tmp/SpiceForeignMenu-5895.uds
> > 1332262683 DEBUG [5895:5895] LinuxListener::LinuxListener: listening
> > socket - /tmp/SpiceForeignMenu-5895.uds, added to events_loop
> > 1332262683 INFO [5895:5895] Controller::Controller: Creating a
> > controller connection /tmp/spicec-y6x224/spice-xpi
> > 1332262683 DEBUG [5895:5895] LinuxListener::LinuxListener: listening
> > socket - /tmp/spicec-y6x224/spice-xpi, added to events_loop
> > 1332262684 DEBUG [5895:5895] LinuxListener::on_event: New connection
> > created, fd: 22
> > 1332262686 DEBUG [5895:5895] Application::set_host_cert_subject: subject
> > entry: O=frontend.ovirt.domain.co.uk <http://frontend.ovirt.domain.co.uk>
> > 1332262686 DEBUG [5895:5895] Application::set_host_cert_subject: subject
> > entry: CN=91.***.***.***
> > 1332262686 DEBUG [5895:5895] HotKeysParser::HotKeysParser: hotkeys =
> > release-cursor=shift+f12,toggle-fullscreen=shift+f11
> > 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> > 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = f12
> > 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> > 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = f11
> > 1332262686 DEBUG [5895:5896] RedPeer::connect_to_peer: Trying
> > 91.***.***.***.*** 65535

^^^ this looks suspicious. It seems like no port is passed to the client
from User Portal and spice-xpi subsequently tries 65535.

David

> > 1332262686 INFO [5895:5896] RedPeer::connect_to_peer: Connect failed:
> > Connection refused (111)
> > 1332262686 WARN [5895:5896] RedChannel::run: failed to connect:
> > Connection refused (111)
> > 1332262686 INFO [5895:5895] main: Spice client terminated (exitcode = 3)
> > 1332262686 DEBUG [5895:5895] cleanup:
> >
> > -
> >
> > The IP it seems to be trying is the external IP of the Ovirt node...
> >
> >
> >
> > ~/.spicec/spice-xpi.log  shows
> > -
> > 2012-03-20 16:58:03,134 ERROR nsPluginInstance::Connect: ERROR failed to
> > run spice-xpi-client
> > 2012-03-20 16:58:06,260 ERROR nsPluginInstance::CallOnDisconnected:
> > OnDisconnected is not object
> > -
> >
> > Any ideas ?
> >
> > Also is there any way of adding a ovirt node via host name rather than
> > IP - I can't seem to using the ovirt node / ovirt engine.
> >
> > Any help will be welcomed
> >
> > Regards
> >
> >
> > ___
> > Users mailing list
> > us...@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Users] Really need serious help with spice (its just not working !!) - attached ~/.spicec/spicec.log

[David Jaša]

Yaniv Kaul píše v St 21. 03. 2012 v 18:21 +0200:
> On 03/21/2012 05:52 PM, David Jaša wrote:
> > Hi,
> >
> > Itamar Heim píše v St 21. 03. 2012 v 17:28 +0200:
> >> cc'ing spice-devel
> >>
> >> On 03/20/2012 07:01 PM, Morgan Cox wrote:
> >>> Hi.
> >>>
> >>> My Setup - 3 servers
> >>>
> >>> 1 Frontend (ovirt engine) - Fedora 16- external + local IP
> >>> 1 Ovirt node (using the node .iso)   - external + local IP
> >>> 1 NFS storage - external + local IP - I attached the storage using the
> >>> Local IP (10.0.0.190)
> >>>
> >>> I have launched firefox with -  SPICEC_LOG_LEVEL=0 firefox
> >>>
> >>> I create a VM, turn it on - click the spice console button - it crashes
> >>>
> >>> I can see
> >>>
> >>> Warning: failed to connect: Connection refused (111)
> >>>
> >>>~/.spicec/spicec.log  ( I have removed the IP / domain name)
> >>> -
> >>>
> >>>
> >>> 1332262683 INFO [5895:5895] Application::main: starting 0.10.0
> >>> 1332262683 DEBUG [5895:5895] Application::Application:
> >>> 1332262683 DEBUG [5895:5895] HotKeysParser::HotKeysParser: hotkeys =
> >>> toggle-fullscreen=shift+f11,release-cursor=shift+f12
> >>> 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> >>> 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = f11
> >>> 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> >>> 1332262683 DEBUG [5895:5895] HotKeysParser::add_key: keys = f12
> >>> 1332262683 DEBUG [5895:5895] Platform::init:
> >>> 1332262683 INFO [5895:5895] init_key_map: using evdev mapping
> >>> 1332262683 INFO [5895:5895] MultyMonScreen::MultyMonScreen:
> >>> platform_win: 104857601
> >>> 1332262683 INFO [5895:5895] ForeignMenu::ForeignMenu: Creating a foreign
> >>> menu connection /tmp/SpiceForeignMenu-5895.uds
> >>> 1332262683 DEBUG [5895:5895] LinuxListener::LinuxListener: listening
> >>> socket - /tmp/SpiceForeignMenu-5895.uds, added to events_loop
> >>> 1332262683 INFO [5895:5895] Controller::Controller: Creating a
> >>> controller connection /tmp/spicec-y6x224/spice-xpi
> >>> 1332262683 DEBUG [5895:5895] LinuxListener::LinuxListener: listening
> >>> socket - /tmp/spicec-y6x224/spice-xpi, added to events_loop
> >>> 1332262684 DEBUG [5895:5895] LinuxListener::on_event: New connection
> >>> created, fd: 22
> >>> 1332262686 DEBUG [5895:5895] Application::set_host_cert_subject: subject
> >>> entry: O=frontend.ovirt.domain.co.uk<http://frontend.ovirt.domain.co.uk>
> >>> 1332262686 DEBUG [5895:5895] Application::set_host_cert_subject: subject
> >>> entry: CN=91.***.***.***
> >>> 1332262686 DEBUG [5895:5895] HotKeysParser::HotKeysParser: hotkeys =
> >>> release-cursor=shift+f12,toggle-fullscreen=shift+f11
> >>> 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> >>> 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = f12
> >>> 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = shift
> >>> 1332262686 DEBUG [5895:5895] HotKeysParser::add_key: keys = f11
> >>> 1332262686 DEBUG [5895:5896] RedPeer::connect_to_peer: Trying
> >>> 91.***.***.***.*** 65535
> > ^^^ this looks suspicious. It seems like no port is passed to the client
> > from User Portal and spice-xpi subsequently tries 65535.
> >
> > David
> >
> >>> 1332262686 INFO [5895:5896] RedPeer::connect_to_peer: Connect failed:
> >>> Connection refused (111)
> 
> But then why would the connection be REFUSED? You should get (AFAIR), 
> timeout (110).

Because nothing listens on port 65535. I've created a spice-xpi for to
handle such situations better:
https://bugzilla.redhat.com/show_bug.cgi?id=805602

see the pasted log - the mode of failure is exactly the same.

David

> I suggest getting the VM's QEMU logs as well.
> Y.
> 
> >>> 1332262686 WARN [5895:5896] RedChannel::run: failed to connect:
> >>> Connection refused (111)
> >>> 1332262686 INFO [5895:5895] main: Spice client terminated (exitcode = 3)
> >>> 1332262686 DEBUG [5895:5895] cleanup:
> >>>
> >>> -
> >>>
> >>

Re: [Spice-devel] spice client for windows

[David Jaša]

Hi Frederic,

Frederic Bouchard píše v Po 19. 03. 2012 v 15:25 -0400:
> Hi,
> 
> 
> I would like to know if with the spice client for windows can run in
> full screen mode. 

The client available at download page is capable of it - run it with -f
option (or --full-screen=auto-conf that will also adjust guest
resolution if guest agent is up'n'running).

>  Also if we can to save the configuration of the remote connection
> (like Microsoft client RDP which can save rdp session configuration.)
> 
It's not possible. spicec is intentionally 'dumb' in this regard, it is
expected that connection will be managed by something else that will
drive spice over controller interface - like oVirt user portal with (not
yet open-sourced) activex plug-in. The plugin for firefox is available
but it's currently linux-only.

David

> 
> Regards
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SSL connect problem

[David Jaša]

Hi Anthony,

Anthony James píše v Čt 22. 03. 2012 v 15:40 -0400:
> I'm having problems connecting to a spice virtual machine using SSL.
>  I use the following command to connect:
> 
> 
> spicec -h localhost -p $PORT -s $SPORT --secure-channels all
> --host-subject "$HOSTSUBJECT" -w $PASSWD
> 
You're missing --ca-file $CA_CERTIFICATE_FILE in your command line.

David
> 
> The error I receive is:
> 
> 
> Error: failed to connect w/SSL, ssl_error
> error:0001:lib(0):func(0):reason(1)
> 139699632096512:error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:s3_clnt.c:1063:
> Warning: SSL Error:
> 
> 
> I have followed the instructions from the following 2 sites to
> configure the SSL certs:
> 
> 
> http://www.spice-space.org/page/SSLConnection
> 
> 
> http://fedoraproject.org/w/index.php?title=QA:Testcase_Virtualization_Manually_set_spice_listening_port_with_TLS_port_set&oldid=255162
> 
> 
> Any help would be greatly appreciated, I'm sure I'm missing something.
> 
> 
> Thanks,
> Tony
> _______
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SSL connect problem

[David Jaša]

Anthony James píše v Pá 23. 03. 2012 v 06:26 -0400:
> David,
> 
> Thanks for the reply.  I've tried adding --ca-file to the spicec
> command line but still receive the same error.  Here is the command:
> 
> spicec -h localhost -p $PORT -s $SPORT --secure-channels all
> --host-subject "$HOSTSUBJECT" --ca-file ca-cert.pem -w $PASSWD
> 
> Same error:
> 
> Error: failed to connect w/SSL, ssl_error
> error:0001:lib(0):func(0):reason(1)
> 140613653984512:error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:s3_clnt.c:1063:
> Warning: SSL Error:

Hi Anthony,

try several times. It's a known bug in spicec that when you're
connecting manually, the connection fails several times before it is
established. Actually it's more frequent if you specify --secure
channels all or if you omit -p altogether (both have the same effect).

David
> 
> On Fri, Mar 23, 2012 at 6:06 AM, David Jaša  wrote:
> Hi Anthony,
> 
> Anthony James píše v Čt 22. 03. 2012 v 15:40 -0400:
> > I'm having problems connecting to a spice virtual machine
> using SSL.
> >  I use the following command to connect:
> >
> >
> > spicec -h localhost -p $PORT -s $SPORT --secure-channels all
> > --host-subject "$HOSTSUBJECT" -w $PASSWD
> >
> 
> You're missing --ca-file $CA_CERTIFICATE_FILE in your command
> line.
> 
> David
> >
> > The error I receive is:
> >
> >
> > Error: failed to connect w/SSL, ssl_error
> > error:0001:lib(0):func(0):reason(1)
> > 139699632096512:error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> > failed:s3_clnt.c:1063:
> > Warning: SSL Error:
> >
> >
> > I have followed the instructions from the following 2 sites
> to
> > configure the SSL certs:
> >
> >
> > http://www.spice-space.org/page/SSLConnection
> >
> >
> >
> 
> http://fedoraproject.org/w/index.php?title=QA:Testcase_Virtualization_Manually_set_spice_listening_port_with_TLS_port_set&oldid=255162
> >
> >
> > Any help would be greatly appreciated, I'm sure I'm missing
> something.
>     >
> >
> > Thanks,
> > Tony
> 
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
> 
> --
>     
> David Jaša, RHCE
> 
> SPICE QE based in Brno
> GPG Key: 22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> 
> 
> 
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] SSL connect problem

[David Jaša]

Anthony James píše v Pá 23. 03. 2012 v 06:46 -0400:
> David,
> 
> 
> I just tried about 20 times in a row, same error.  When you say it's a
> known bug in spicec when connecting manually, what is the alternative
> to connecting manually?  Is this bug present in spicy or
> remote-viewer?  Thanks in advance.

I don't recall hitting it with remote-viewer. FTR, remote-viewer's
invocation format differs from that of spicec and spicy:

remote-viewer  spice:///?port=&tls-port=

you can get the complete list of of options with:

remote-viewer --help-all

Speaking about it, it might be also the libvirt/qemu bug that both fired
up with main channel forced to SSL/TLS but without setting up tls-port
on which would qemu actually listen. Could you post qemu command line
here so we can rule it out?

David
> 
> On Fri, Mar 23, 2012 at 6:37 AM, David Jaša  wrote:
> Anthony James píše v Pá 23. 03. 2012 v 06:26 -0400:
> > David,
> >
> > Thanks for the reply.  I've tried adding --ca-file to the
> spicec
> > command line but still receive the same error.  Here is the
> command:
> >
> > spicec -h localhost -p $PORT -s $SPORT --secure-channels all
> > --host-subject "$HOSTSUBJECT" --ca-file ca-cert.pem -w
> $PASSWD
> >
> > Same error:
> >
> > Error: failed to connect w/SSL, ssl_error
> > error:0001:lib(0):func(0):reason(1)
> > 140613653984512:error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> > failed:s3_clnt.c:1063:
> > Warning: SSL Error:
> 
> 
> Hi Anthony,
> 
> try several times. It's a known bug in spicec that when you're
> connecting manually, the connection fails several times before
> it is
> established. Actually it's more frequent if you specify
> --secure
> channels all or if you omit -p altogether (both have the same
> effect).
> 
> David
> >
> > On Fri, Mar 23, 2012 at 6:06 AM, David Jaša
>  wrote:
> > Hi Anthony,
> >
> > Anthony James píše v Čt 22. 03. 2012 v 15:40 -0400:
> > > I'm having problems connecting to a spice virtual
> machine
> > using SSL.
> > >  I use the following command to connect:
> > >
> > >
> > > spicec -h localhost -p $PORT -s $SPORT
> --secure-channels all
> > > --host-subject "$HOSTSUBJECT" -w $PASSWD
> > >
> >
> > You're missing --ca-file $CA_CERTIFICATE_FILE in
> your command
> > line.
> >
> > David
> > >
> > > The error I receive is:
> > >
> > >
> > > Error: failed to connect w/SSL, ssl_error
> > > error:0001:lib(0):func(0):reason(1)
> > > 139699632096512:error:14090086:SSL
> > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate
> verify
> > > failed:s3_clnt.c:1063:
> > > Warning: SSL Error:
> > >
> > >
> > > I have followed the instructions from the
> following 2 sites
> > to
> > > configure the SSL certs:
> > >
> > >
> > > http://www.spice-space.org/page/SSLConnection
> > >
> > >
> > >
> >
> 
> http://fedoraproject.org/w/index.php?title=QA:Testcase_Virtualization_Manually_set_spice_listening_port_with_TLS_port_set&oldid=255162
> > >
> > >
> > > Any help would be greatly appreciated, I'm sure
> I'm missing
> > something.
> > >
> > >
> > > Thanks,
> > > Tony
> >
> > > ___
> > > Spice-devel mailing list
> > > Spice-devel@lists.freedes

Re: [Spice-devel] SSL connect problem

[David Jaša]

Hi Anthony,

I don't see anything clearly wrong in what you posted in your last two
mails. Just one note: -spice addr=127.0.0.1 means that the host will
only be accessible on the localhost - if you add "" element to "" element in domain xml, qemu
will bind to all ipv4 addresses.

I'd just check the SSL/TLS stuff again - if your certs are OK, if you
pass correct host subject (without space after comma!), if you pass
correct CA file and so on...

David

Anthony James píše v Pá 23. 03. 2012 v 07:20 -0400:
> I just tried connecting using remote-viewer, here is the command:
> 
> 
> remote-viewer --spice-ca-file=ca-cert.pem
> --spice-host-subject="$HOSTSUBJECT" spice://localhost/?port=
> $PORT&tls-port=$SPORT
> 
> 
> It connects but using only the non-tls port.  When I remove port=$PORT
> to try and force it to use the tls-port the connection fails and I see
> this in the VM log:
> 
> 
> reds_handle_ssl_accept: SSL_accept failed, error=1
> 
> 
> The remote-viewer version is 0.5.2.
> 
> On Fri, Mar 23, 2012 at 7:10 AM, Anthony James
>  wrote:
> I created and started the VM with virt-manager.  Here is what
> looks like the qemu cmd from /var/log/libvirt/qemu/$VM.log
> 
> 
> /usr/bin/qemu-kvm -S -M pc-0.15 -cpu core2duo,+lahf_lm,
> +rdtscp,+popcnt,+sse4.2,+sse4.1,+pdcm,+xtpr,+cx16,+tm2,+est,
> +smx,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds -enable
> -kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name $VMNAME
> -uuid 9046e3aa-81d5-028d-010f-2a755e20aa97 -nodefconfi
> g -nodefaults -chardev
> 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/$VMNAME.monitor,server,nowait
>  -mon chardev=c
> harmonitor,id=monitor,mode=control -rtc base=localtime
> -no-shutdown -device
> virtio-serial-pci,id=virtio-serial0,bus=pci.
> 0,addr=0x5 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8
> -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0
> ,addr=0x9 -device
> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0xa
> -device ich9-usb-uhci3,masterbus=usb.0,f
> irstport=4,bus=pci.0,addr=0xb -drive
> file=/vm/$VMNAME.img,if=none,id=drive-virtio-disk0,format=raw
> -device virtio-bl
> 
> k-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
>  -drive file=/iso/virtio-win-0.1-2
> 2.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw 
> -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1
> -0,id=ide0-1-0 -netdev
> tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:5
> 4:00:43:e6:dd,bus=pci.0,addr=0x3 -chardev pty,id=charserial0
> -device isa-serial,chardev=charserial0,id=serial0 -chardev 
> spicevmc,id=charchannel0,name=vdagent -device
> 
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,
> name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice
> port=$PORT,tls-port=
> $SPORT,addr=127.0.0.1,x509-dir=/etc/pki/lib
> virt-spice -k en-us -vga qxl -global
> qxl-vga.vram_size=67108864 -device
> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device h
> da-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev
> spicevmc,id=charredir0,name=usbredir -device
> usb-redir,chardev=ch
> arredir0,id=redir0 -device
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
> 
> 
> Also in the log I see the following messages for everytime I
> try to connect using SSL:
> 
> 
> reds_handle_ssl_accept: SSL_accept failed, error=1
> reds_handle_ssl_accept: SSL_accept failed, error=1
> 
> 
> Here are the package versions I'm running:
> 
> 
> spice-xpi-2.7-2.fc16.x86_64
> spice-gtk3-0.11-4.fc16.x86_64
> spice-gtk-tools-0.11-4.fc16.x86_64
> spice-client-0.10.1-1.fc16.x86_64
> spice-server-0.10.1-1.fc16.x86_64
> spice-gtk-python-0.11-4.fc16.x86_64
> spice-gtk-0.11-4.fc16.x86_64
> spice-protocol-0.10.1-1.fc16.noarch
> spice-glib-0.11-4.fc16.x86_64
> libvirt-0.9.10-2.fc16.x86_64
> libvirt-python-0.9.10-2.fc16.x86_64
> libvirt-client-0.9.10-2.fc16.x86_64
> qemu-system-x86-1.0-7.fc16.x86_64
> gpxe-roms-qemu-1.0.1-4.fc16.noarch
> qemu-common-1.0-7.fc16.x86_64
> qemu-img-1.0-7.fc16.x86_64
> virt-manager-common-0.9.1-2.fc16.noarc

Re: [Spice-devel] SSL connect problem

[David Jaša]

Anthony James píše v Pá 23. 03. 2012 v 08:03 -0400:
> I did have spaces after the commas in the host subject but after
> regenerating the certs 

Hi Anthony,

You should not need to regenerate the certs, just do 's/, /,/' on the
existing string.

> and modifying the command I receive the same error.  I followed the
> steps to create the certs from the
> http://www.spice-space.org/page/SSLConnection site.  Should those
> steps work?
> 
They should. You have to put those cert/key files
to /etc/pki/libvirt-spice (or any other location configured
in /etc/libvirt/libvirtd.conf) but I think you have to have this right,
otherwise qemu wouldn't start at all.

I'm starting to suspect that you have some incompatible characters in
host subject string.

I tried basic plain qemu test here and it works for me. Please try these
steps and tell me how far you got:

 1. create an empty directory, cd to it
 2. copy there the script from the page without any modifications
 3. generate certs
 4. run:
/path/to/qemu_executable -spice tls-port=,disable-ticketing
 5. make sure that qemu indeed listens on the port and it's not blocked by
anything (iptables, selinux)
 5. from other terminal on the same machine, run:
remote-viewer --spice-ca-file 
/ca-cert.pem --spice-host-subject 
'C=IL,L=Raanana,O=Red Hat,CN=my server' spice://127.0.0.1/?tls-port=
or:
spicec --ca-file /ca-cert.pem 
--host-subject 'C=IL,L=Raanana,O=Red Hat,CN=my server' -h 127.0.0.1 -s 5900

If this will not work for you, there is a bug somewhere. If it does, you
should double-check your configuration again.

David


> On Fri, Mar 23, 2012 at 7:36 AM, David Jaša  wrote:
> Hi Anthony,
> 
> I don't see anything clearly wrong in what you posted in your
> last two
> mails. Just one note: -spice addr=127.0.0.1 means that the
> host will
> only be accessible on the localhost - if you add " type='address'
> address='0.0.0.0'/>" element to "" element in domain
> xml, qemu
> will bind to all ipv4 addresses.
> 
> I'd just check the SSL/TLS stuff again - if your certs are OK,
> if you
> pass correct host subject (without space after comma!), if you
> pass
> correct CA file and so on...
> 
> David
> 
> Anthony James píše v Pá 23. 03. 2012 v 07:20 -0400:
> > I just tried connecting using remote-viewer, here is the
> command:
> >
> >
> > remote-viewer --spice-ca-file=ca-cert.pem
> > --spice-host-subject="$HOSTSUBJECT" spice://localhost/?port=
> > $PORT&tls-port=$SPORT
> >
> >
> > It connects but using only the non-tls port.  When I remove
> port=$PORT
> > to try and force it to use the tls-port the connection fails
> and I see
> > this in the VM log:
> >
> >
> > reds_handle_ssl_accept: SSL_accept failed, error=1
> >
> >
> > The remote-viewer version is 0.5.2.
> >
> > On Fri, Mar 23, 2012 at 7:10 AM, Anthony James
> >  wrote:
> > I created and started the VM with virt-manager.
>  Here is what
> > looks like the qemu cmd
> from /var/log/libvirt/qemu/$VM.log
> >
> >
> > /usr/bin/qemu-kvm -S -M pc-0.15 -cpu core2duo,
> +lahf_lm,
> > +rdtscp,+popcnt,+sse4.2,+sse4.1,+pdcm,+xtpr,+cx16,
> +tm2,+est,
> > +smx,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds
> -enable
> > -kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1
> -name $VMNAME
> > -uuid 9046e3aa-81d5-028d-010f-2a755e20aa97
> -nodefconfi
> > g -nodefaults -chardev
> >
> 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/$VMNAME.monitor,server,nowait
>  -mon chardev=c
> > harmonitor,id=monitor,mode=control -rtc
> base=localtime
> > -no-shutdown -device
> > virtio-serial-pci,id=virtio-serial0,bus=pci.
> > 0,addr=0x5 -device
> ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8
> > -device
> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0
> > ,addr=0x9 -device
> >
> ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0xa
> >  

Re: [Spice-devel] [spice-devel] spice-xpi rhbz#805602

[David Jaša]

Marc-André Lureau píše v Út 03. 04. 2012 v 08:39 -0400:
> 
> - Mensaje original -
> > +if (port < 0 && sport < 0)
> > +{
> > +if (port < 0)
> > +LOG_ERROR("invalid port: " << m_port);
> > +if (sport < 0)
> > +LOG_ERROR("invalid secure port: " << m_secure_port);
> > +return;
> > +}
> 
> If one of the value is invalid or garbage and the second is valid, you will 
> silently ignore the error and continue. 

Yeah, the workflow should be a little different:

1) for port and sport, convert string to int. It can have three results:
  1. port is int in valid range
  2. string has zero length -> value should not be sent at all
  3. string is garbage

2) connect function should have IMO these paths:
  1. both values are valid -> execute client and pass the values to it
  2. one of values is valid and the other is disabled -> execute the
 client and pass the valid value to it
  3. one of values is valid: execute the client and:
1. if the other is disabled -> ignore it
2. the other is garbage -> LOG_ERROR the original string value
  4. neither of the values is valid -> LOG_ERROR the original string
 values and don't bother to start the client.

in case of 2) 4., it would make a lot of sense to pass the error to the
web page too when it is possible (when OnDisconnected will work).

David

> I think if any value is wrong (not within -1..65535, it should error out)
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key: 22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel