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
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.
Took a look at this.
Bottom line is that at least for running QEMU, right now well performing opengl is on the bleeding edge.
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.
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…