[Spice-devel] Our current open issues

[John A. Sullivan III]

On Wed, 2011-07-20 at 10:13 +0300, Yaniv Kaul wrote:
> On 07/20/2011 05:31 AM, John A. Sullivan III wrote:
> > Hello, all.  I know I've raised a large number of issues over the last
> > few weeks most of which are still open.  I'd like to summarize them here
> > and ask for your direction on how we can further troubleshoot and
> > resolve them, in other words, how can we as integrators rather than
> > programmers help.
> >
> > The bottom line is that SPICE is much slower than RDP for accessing the
> > same Windows guest and it is not only orders of magnitude slower than
> > X2Go for accessing Linux guests, it is not even usable.  It is quite
> > possible we have mangled the installation but we have tried to be
> > careful and have stuck primarily with Fedora 15 to make our installation
> > as much "out of the box" as possible.  Here are the specifics:
> 
> I'd like to suggest you open bugs on each issues, so they can be 
> identified and tracked by all.
> I know you have opened on some, but having the ability to talk about bug 
> XYZ is easier than 'Linux guest driver issue'.

Gladly but I'm not sure all are bugs.  I suppose that's part of what I'm
asking. For example, the high CPU utilization in Linux and the
non-responsive VDAgent seem to be so I've opened those but I'm not sure
about the general performance issues. That's why I was asking for some
guidance for us to do more troubleshooting before we open it as a bug
> 
> <snip>>
> > Windows guest - both Windows 7 and Windows Server 2008:
> > SPICE is transferring four to five times as much data across the wire as
> > RDP even with effects disabled.  VDAgent is running although it is
> > sometimes unstable and we are using a virtio serial driver.  QXL driver
> > is working.  We were told it that our packet traces seemed to indicate
> > we were not compressing images even though we are configured to do so,
> > our bandwidth is less than 10 Mbps, and the qemu server logs seem to
> > indicate we are using compression.  We reconfigured to force compression
> > and saw the same anecdotal results.  I'm not sure how we measure this if
> > the configuration and logs are saying we are compressing.  How can we
> > verify this lack of compression? Is this discerned from the Wireshark
> > dissector? If so, is there a newer one available than the one on the web
> > site?
> 
> Attached please find the latest source of the Spice dissector. It's not 
> that great (and it's a hacky reverse-engineered dissector), but it gets 
> the work done.
> Feel free to send me (off-list, compressed) packet captures that look 
> wrong, and I might try to fix some of the issues (I'm aware of many 
> already, the code is full of FIXME's and TODOs).
> Y.
> 
> <snip>>
> > So, I suppose one question is, are these because of misconfigurations on
> > our part or are they bugs still being worked out in SPICE? Would it make
> > more sense for use to recompile everything from git? If so, which
> > repository? However, does that then imply that SPICE is not yet really
> > ready for production WAN use?
> >
> > Sorry to be a pain but I suppose it is because we really want to use
> > SPICE but we keep coming up a little short compared to more mature
> > technologies.  Thanks - John
<snip>