In a windows 10 guest managed by virt-manager (qemu), a program requires opengl to run.
I however can’t get over this error:
https://i.imgur.com/fnz5eun.png
Some google results shows I need to change the option from
--graphics spice,port=20001,listen=127.0.0.1
to
--graphics spice,listen=127.0.0.1
Wonder how I should do it with the GUI? I switched the “port”, “tls” on and off in the GUI but they just give me different errors.
I’m guessing you probably found the following reference
My instinct is that the second answer and not the one promoted by the author of that thread makes more sense… Assuming that the error is complaining about the lack of encrypted connection instead of some port definition, setting the connection to “insecure” makes more sense.
If the described solution fails, I would still assume that the error is not passing on faulty information to you and either look for a way to set up the TLS encryption or set the connection to not require TLS.
I’d also take a look at whether QEMU and SPICE are required for your use of OpenGL, I’m guessing a solution exists that bypasses this problem by relying only on configuring the appropriate Mesa support in combination with latest DirectX in your Guest as described in the following VMware thread
https://forums.opensuse.org/showthread.php/538612-OpenGL-version-outdated?p=2924173#post2924173
BTW - in the future, it will be important to clarify if you are running KVM or Xen with QEMU support or only QEMU… That’s pretty important info you left out.
IMO,
TSU
It shows kvm/qemu.
I’m complete newbie about the kvm/xen qemu thing. I used to use just virtualbox but I couldn’t solve the choppy audio problem in the windows guest.
Then I thought I’d give this qemu another try. Last time I tried it it was way too complicated to setup.
Now I used the default setting to create the machine the audio was very smooth. Then I run into one another issue that I have no clue what the error is even about.
I read the link you provided but I could not understand most of it. I thought this opengl thing is a common problem that is easy to solve.
Since I use the virt-manager, I don’t find a place where I can change the connection type from secure to insecure either.
That’s OK, ask and you shall receive… Everyone has to start from the beginning.
The thing to understand about qemu is that it was once its own project but eventually was merged primarily into the KVM project (and with less fanfare into the Xen project as well). So today when you run just KVM, you’ll get some benefits from what qemu can provide in the way of certain ways to access different types of hardware. For those who want to run full emulation however, you would run only qemu for its ability to emulate (which is the ability to seem like completely different hardware) instead of virtualize (which is a kind of modified access but still cannot be different than the basic hardware).
OpenGL has to do with the ability to support advanced graphics of the type you might see in cartoons and artificial environments like FPV shooter games.
It won’t affect audio.
It won’t affect streaming video, like NetFlix or YouTube(unless it’s showing the type of cartoon-like content, then maybe or maybe not)
In other words, if you never watch the type of graphics that use OpenGL, fixing your problem may not be important.
As for the error itself…
You should know that Spice is one option for viewing a Guest’s Desktop, but it promises being able to provide “better” quality through support like OpenGL. The alternative is to use the VNC protocol which provides reliable basic but is not especially high performing.
To use Spice always requires a network connection, even if connecting to a Guest running on the same machine you’re sitting at, and it seems that Spice is requiring the network connection to be encrypted similar to how you use SSL to connect to an encrypted website.
So, the error you’re seeing is much the same as if you tried to connect to a website that has its own self-signed certificate, if you did that using a web browser your browser would complain that the website can’t be trusted and a secure connection cannot be set up.
In the same way, Spice is complaining that you’re connecting to a Guest which can’t be trusted and a secure connection can’t be set up.
Note that this Spice connection between your libvirt viewer and the Guest is not the same as the network connection you set up in your Guest, your Guest will likely be able to access anything on the Internet without a problem while this opengl problem exists.
The link I provided describes how to modify the Spice setting to “insecure,” thereby disabling the encryption requirement,
But whether it works or not may not be important to you, you can ignore the error if you don’t intend to view anything that requires opengl.
And, the error won’t affect anything else running in your Windows Guest, it should run just find doing anything you want including listening to audio.
TSU
It seems that qemu doesn’t actually support opengl without a custom build of it.
https://askubuntu.com/questions/1092642/qemu-doesnt-support-spice-opengl
I spent all my time on how to make the spice connection insecure and succeeded but it doesn’t make a change for me.
A program insists it wants opengl to run. I’m giving up.
Took a look at this.
Bottom line is that at least for running QEMU, right now well performing opengl is on the bleeding edge.
Some hightlights…
Recommend use the Virgil3D stack, the most recent release as of today is Aug 2019.
There are various blog articles that describe implementing without libvirt on Debian, skimming them nothing jumps out at me that they wouldn’t also work on openSUSE.
But, whether OpenGL will properly work in a Windows Guest is unknown, I don’t see that anyone has set it up and posted results. In theory, you <should> get expected performance in Windows because MS embeds OpenGL (and other drivers) support in its own kernel similar to how drivers are distributed in the Linux kernel today.
So, this is a path to possible success but has not been tested and published.
Alternatives to Virgil3D exist,
The ArchWiki for QEMU suggests configuring a Unix socket instead of a network socket for SPICE. That won’t cause error messages to go away, but would likely improve performance
https://wiki.archlinux.org/index.php/QEMU#SPICE
The following command tests for QEMU support for OpenGL which would be required if running virt-io. If you return a message support is not compiled, then I’d recommend you submit a request for the standard QEMU to include OpenGL support. Else, it looks like re-compiling QEMU should not be difficult
qemu-system-x86_64 -display sdl,gl=on
If you’re hoping for an easy support for OpenGL, I wouldn’t expect that from KVM/QEMU at the moment, although possibly getting close.
My recommendation is to instead run a VMware product (VMware Player is free) because VMware has always been MS-centric, that’s the primary focus of VMware products… To run well and sometimes exclusively on Windows. If you decide to deploy VMware, see the reference in my first post in this thread.
TSU
Hi
Is this a desktop machine? If so maybe look at gpu passthrough with an extra GPU if you motherboard supports it?
Yes, a GPU pass-through is another option,
In fact these are th various recommended options from the QEMU project
https://wiki.archlinux.org/index.php/QEMU/Guest_graphics_acceleration
For those who are using a laptop,
I came across a recent article that enables you to use an external GPU…
If you have a laptop manufactured since 2017, it’s likely your system doesn’t have SATA connectors for your drives, you have an M.2 connector, and there may be at least one additional, unused M.2 interface in your machine.
There is a YouTube video of the guy cracking open his laptop’s shell, connecting a graphics drive board to the M.2 connector, driving an nVidia GPU and an external monitor.
Not for the average User…
Myself, I’d just use VMware for now…
TSU
Hi
My passthrough gpu is driven over the mini PCIe to PCIeX1 that was spare on the M/B, freed up a PCIx1 slot to use a SATA controller and SSD for my qemu machines;
pinxi -Fxxz
System: Kernel: 4.12.14-lp151.28.36-default x86_64 bits: 64 compiler: gcc v: 7.4.1 Desktop: Gnome 3.26.2 wm: gnome-shell
dm: GDM Distro: openSUSE Leap 15.1
Machine: Type: Vm-other System: QEMU product: Standard PC (Q35 + ICH9, 2009) v: pc-q35-4.0 serial: <filter> Chassis: type: 1
v: pc-q35-4.0 serial: <filter>
Mobo: N/A model: N/A serial: N/A UEFI: EFI Development Kit II / OVMF v: 0.0.0 date: 02/06/2015
CPU: Topology: Dual Core model: Intel Xeon E3-1245 V2 bits: 64 type: MT MCP arch: Ivy Bridge rev: 9 L2 cache: 16.0 MiB
flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27139
Speed: 3392 MHz min/max: N/A Core speeds (MHz): 1: 3392 2: 3392 3: 3392 4: 3392
Graphics: Device-1: NVIDIA GK208B [GeForce GT 710] vendor: ZOTAC driver: nvidia v: 440.59 bus ID: 00:03.0 chip ID: 10de:128b
Display: x11 server: X.Org 1.20.3 driver: nvidia compositor: gnome-shell resolution: 1360x768~60Hz
OpenGL: renderer: GeForce GT 710/PCIe/SSE2 v: 4.6.0 NVIDIA 440.59 direct render: Yes
Audio: Device-1: NVIDIA GK208 HDMI/DP Audio vendor: ZOTAC driver: snd_hda_intel v: kernel bus ID: 00:04.0
chip ID: 10de:0e0f
Sound Server: ALSA v: k4.12.14-lp151.28.36-default
Network: Device-1: Intel 82574L Gigabit Network driver: e1000e v: 3.2.6-k port: 6160 bus ID: 00:01.0 chip ID: 8086:10d3
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives: Local Storage: total: 119.24 GiB used: 14.85 GiB (12.5%)
ID-1: /dev/sda vendor: OCZ model: VERTEX4 size: 119.24 GiB speed: 6.0 Gb/s serial: <filter>
Partition: ID-1: / size: 60.00 GiB used: 14.82 GiB (24.7%) fs: btrfs dev: /dev/sda3
ID-2: /home size: 60.00 GiB used: 14.82 GiB (24.7%) fs: btrfs dev: /dev/sda3
ID-3: /opt size: 60.00 GiB used: 14.82 GiB (24.7%) fs: btrfs dev: /dev/sda3
ID-4: /tmp size: 60.00 GiB used: 14.82 GiB (24.7%) fs: btrfs dev: /dev/sda3
ID-5: /var size: 60.00 GiB used: 14.82 GiB (24.7%) fs: btrfs dev: /dev/sda3
ID-6: swap-1 size: 4.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda4
Sensors: Missing: Required tool sensors not installed. Check --recommends
Info: Processes: 218 Uptime: N/A Memory: 7.78 GiB used: 902.9 MiB (11.3%) Init: systemd v: 234 runlevel: 5
target: graphical.target Compilers: gcc: 7.5.0 alt: 7 Shell: bash v: 4.4.23 running in: tilda pinxi: 3.0.37-37
If “custom build” means “out of tree patches” - I do not know what you mean. If “custom build” means suitable build options - as far as I can tell, QEMU in Leap 15.1 is built with necessary support.
And how exactly the fact that Ubuntu builds QEMU without necessary support is relevant for openSUSE?
Like many other builds, some settings are optional. Which is why I posted the command to query for support so no guessing.
TSU