<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> Hello (very fearfully, because I found no list that could be helpful and this one seems to be for developers...), I have been trying for a long while now to get my VM machines to perform well, but I can't seem to get it right. I seem to be suffering from two issues: <ol> <li>remote-viewer / libvirt host uses inefficient codecs to transfer audio / video</li> <li>virtual machines themselves don't seem to have their graphics accelerated sufficiently </li> </ol> I proceed to elaborate on both: #1 - inefficient codecs So I have a number of VMs running under qemu on Ubuntu 18.04. AMD 2700x + nvidia 1060 gtx (driver nvidia). qemu 4.2, libvirt 6.0.0. Everything works fine except accessing the VMs remotely: the slower the connection, the worse it gets. Running them on 4K monitor - please note the resolution. Using remmina or virt-viewer, makes no difference. <ul> <li>on local machine, everything is next to perfect, the only noticeable quality degradation is video full-screen.</li> <li>1gbit LAN: noticeable delays rendering stuff, video becomes grainy even when in a small window</li> <li>100 mbit LAN / internet: a full screen refresh can take several seconds</li> <li>20/4 mbit internet: when a full screen refresh is needed, I can observe the 64x64 squares being rendered across the screen and it takes multiple seconds. Scrolling an editor window is an operation that takes patience. Connection useless but for the most urgent tasks where patience is not an issue. Even X over ssh seems the better option here.</li> </ul> I compare this to Win10 RDP, which - over the same 20/4 connection - behaves as if I were at the machine in question, even for full-screen video. The VMs are all setup thus: <ul> <li>Display spice: Spice server with everything on default, no OpenGL</li> <li>Video VirtIO: model VirtIO, 3D acceleration: yes, heads:2, RAM 128MB</li> </ul> I tried video: QXL, but that one completely hogged my LAN, even at gbit, delivering little for the bandwidth taken (it was less performant than VirtIO). Same for running everything on local machine too. It seems it just continuously grabs frames and transmits them regardless of whether there's any action or not. Driver in use for guests is virtio-pci for manjaro (video frames undistorted, but frames lost depending on bandwidth), qxl for ubuntu (video frames are chopped up, presumably by algorithm snapping them partially before transmission). QXL despite the fact that video for the vm in question is set to VirtIO. May also be a result of my tinkering but useful for comparison anyway. I have searched all 'round the place and I did find <a href="https://spice-devel.freedesktop.narkive.com/m7FY7Dvb/spice-v12-00-26-add-gstreamer-support-for-video-streaming">this thread</a>. It seems to have been merged, but there are no instructions on how to modify VM configuration to use H264 instead of MJPEG for video encoding. #2 - inadequate graphics acceleration Well, I mostly base this one on observed CPU usage. I have noticed on all my linux guests (Manjaro, Ubuntu) that even moving a window around the desktop significantly raises CPU usage in the guest. I would venture to guess one core gets taken by such an endeavor. Playing a video in browser full screen would take closer to two cores. It is not much different for Windows guests: running a video or a skype video session absolutely hogs the CPU. While skype itself takes little CPU, the overall CPU usage goes toward 80 - 100% on a 6 core VM. The actual process consuming that CPU is not shown in details pane. Using Red Hat QXL controller for display adapter on Win10 64-bit. I have found no solution to this problem. After a very long time and continuing frustration with the problem, I turn to you guys in hope of a suggestion on what I'm doing wrong. Just as gladly I would hear of a setup that is known to perform well, I have no particular need to resolve my exact issues. Reinstalling the host and / or guests is not a problem if a known good configuration will perform for me too... Thanks, Jure </body> </html>