[ovirt-users] poor graphic performances with spice

[David Jaša]

On Po, 2015-11-02 at 11:13 +0100, Nathanaël Blanchet wrote:
> Hello Jiri and David,
> 
> 
> Le 02/11/2015 10:22, David Jaša a écrit :
> > Hi Nathanaël,
> >
> > On St, 2015-10-28 at 17:06 +0100, Nathanaël Blanchet wrote:
> >> Hello,
> >>
> >> I'm studying a possibility to use ovirt as a vdi solution with centos or
> >> fedora guests. But using spice is awfull
> > in what sense, just a performance you mention below, or something else?
> I'm used to use spice with virt-manager, and I always have been pleased 
> with it.
> >
> >> and graphics are very slow (in
> >> particulary videos). 

You say youtube videos in bottom of the email. Is it flash or html5? Are
standard and cinema-mode-sizes working OK, or all sizes are affected?

Bear in mind that video is in general most cpu-heavy use case for spice
because lots of work needs to be done on guest vCPU (decode, upscale to
fullscreen) and host CPU (mjpeg-encode the actual video size: fullhd for
any video played in full screen on full hd monitor).

> Qxl drivers are installed and spice-vdagent works
> >> as expected on the guest side.
> > What hosts and clients do you use, what is your network environment?
> ubuntu spice-client-gtk (0.22) for the client side, 

That's pretty old, could you update to distro with at least spice-gtk
0.26 (which itself is ~1 year old, 0.30 was released recently)?

> and my hosts (latest 
> intel CPU and 128 GB of RAM) are centos 7.1 one connected to a FC 
> storage domain. The network is a gigabit one. I set my vms with 2GB of RAM.

That sounds that you should be good (unless _everybody_ plays youtube in
fullscreen)

> > When you say centos guests, you mean centos 6 or centos 7?
> both. 

Interesting. I'd expect rhel 6 (or KDE4 with disabled compositing on
rhel 7) to be significantly better to gnome 3.

> I also tested fedora 22 but I supposed that default gnome 3 shell 
> effects could be the reason of the slowness.

The problem aren't mainly effect but it's the compositing which changes
screen updates from lot of operations on limited area of screen to
updates of whole screen, making lots of spice optimization pointless.
Some time ago (~2 years), gnome-shell rendering was improved so that
stream didn't update whole display but just the video stream area which
can be detected as a stream and transferred in an optimized way.

I'd bet that your issue is one of those two described above (CPU
overloading or streaming detection error) but further testing is needed
to find what it really is.

> >
> > David
> >
> >> However, it is amazing to see that glxgears benchmarks are good...
> >> I wonder how it is possible to adopt such a vdi solution when the user
> >> experience is so bad.
> >> I may miss something and may need recommandations of experimented vdi
> >> users :)
> >> Thank you for your help.
> >>
> >
> Ovirt is an awesome product, and I've been used to be pleased with its 
> great integrated quality tools, that's why I'm supposed to mistake in my 
> configuration.
> I don't know the vdi part, but problematic is not the same compared to 
> the server virtualization. User should have a very good interface 
> experience, integrating fluidity and multimedia capabilities.
> Sound redirection is okay with no latence, USB redirection works great, 
> but watching a youtube video is painful.
> The same when moving a simple gui window, there is a big latence.
> In comparison, direct RDP session on windows servers gives entire 
> satisfaction in graphic rendering.
> Please tell me if I do or say something wrong.
> Thank you for your job.
> 

Can you see something in Xorg.0.log in the guest or in qemu log on the
host? (@ /var/log/libvirt/qemu/VM_NAME.log)

David