If you are using Rocky Linux 9 or any other RHEL 9 distro as your workstation and using KVM, you are stuck with VNC as SPICE support was removed.
So in short:
SPICE has been deprecated for qemu and has been removed in RHEL 9. We still do have SPICE client support for RHV - which is shipped in the RHV-Tools repos on RHEL 9.
Unfortunately I don’t know if and how oVirt is solving this for RHEL 9. Anyways the RHV-tools repo will be supported until RHV is EOLed in 2026.
Why no SPICE:
Due to some license restrictions around H.264 codecs we are not able to provide a Streaming solution which is needed for modern workloads (as all drivers are using 3D today). Also vGPU support is not possible without this.
There are quite some 3rd party solutions that already have a proper implementation (licensed software due to H.264 restrictions unfortunately).
For console access and local acceleration VNC is capable of doing the job - and VNC is also used for OpenStack and KubeVirt and they are both not interested in using SPICE instead.
Mainly due to (1) and (3) we decided to deprecate our work on SPICE.
Since I rebuilt the spice stack with phodav 3.0, there has been a virt-manager core dump due to using libsoup2 and libsoup3 in the same process which is not supported. This is now fixed.
Hi, ligenix!
I used this repo ligenix/enterprise-qemu-spice Copr for my RockyLinux 9 distro, but I meet some problems on virt-manager when I open windows10 guest os on virt-manager config spice server and QXL driver.
I do the steps on new installed Rocky Linux 9:
dnf update -y
dnf -y copr enable ligenix/enterprise-qemu-spice
dnf install qemu-kvm-ui-spice
dnf install virt-manager
virt-manager import my exists win10 guest os disk img and config is use spice display server&QXL driver
boot win10 guest os, then prompt “could not get a reference to type class”
I’m struggling to find a way to display graphics using spice on RockyLinux 9.
I think your copr repository should be a good solution, but unfortunately I can’t use it perfectly.
Can you help me with a solution to the problem I’m having?
I had to upgrade a set of packages in order to provide spice support with the last librairies versions. So a dnf update is required after enabling the repository.
This point is now precised in the install instructions.
Yes, spice seems to be working normally, it should be because you have updated the package in the repository.
Currently the installation instructions and packages in your repository are working correctly.
I need to test the reason why the default network configured by virt-manager cannot be connected. At present, this is the only problem. I will try to find out the reason later.
Should I keep this repository enabled and dnf update? Or disable the repository after installing spice?
Finally there is a way to use spice in RockyLinux 9.
Thanks a lot ligenix!
Thank you for this positive feedback.
Yes you can keep this repository enabled for updates.
The next step is to merge it into the upcoming Rocky Linux FastTrack Updates repository, but I have currently a bit of work to do to reach the standard quality level of this distro.
Can you make qemu-kvm-block-gluster also available in you repo ligenix/enterprise-qemu-spice Copr ?
I’m using oVirt, dnf swap to packages in your other repo wants just kill all installation, though there’s qemu-block-gluster in it, but I can’t go with it
Unfortunately, like SPICE, GluterFS and oVirt were left behind by Red Hat for RHEL 9. I pushed a rebuild wih qemu-block-gluster, depending on Gluster 11 but it breaks system updates. I have to reworking it a little more with epoch probably needs to be bumped.
Hi ligenix ! I rebuilt libsoup3, glib2 and virt-manager from your repo. When connecting to a virtual machine using virt-manager I get a double boot error with libsoup versions 2 and 3. Can you help ? You solved this problem in your repo.
Hi smusich ! Sure, I seeked for it during hours by parsing the crossing library dependencies one by one. You have to rebuild libosinfo also, all the packges I modified for spice have a specific _spice tag to be properly identified.
As previously assumed, I had to change the epoch from 17 to 18 to bypass the Obsoletes directive placed on the block-gluster subpackage, moreover I did the same for the block-iscsi and block-ssh subpackages to fully revert qemu-kvm to RHEL 8 state.