Assigned to Meirav since her teams owns SPICE, but added Martin in a needinfo to give the product management perspective on the above.

Adding my note:

I use virt-manager with spice every day for my work. I updated my laptop to centos9 stream and it broke my work setup. I was very surprised on this deprecated feature, removed with no explanation.
Maybe Centos9stream isn't the OS that i need?


Luckily i have another working pc using fedora. I don't understand why spice is getting dropped while it is shipped & usable in fedora 35. I thought Centos was a "more stable" fork from fedora.
It seems it isn't the case.

Hello Redhat, any update on this?

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:
1. 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.
2. There are quite some 3rd party solutions that already have a proper implementation (licensed software due to H.264 restrictions unfortunately).
3. 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.

For the folks who just ended up here like me, one possible solution is:

REMMINA
https://flathub.org/apps/details/org.remmina.Remmina
It still has spice support.
In case you want to find/forward the port from a hypervisor where spice is listening on:
ps ax| grep vm-name | grep -o "spice port=[0-9]*,"

This is really sad. I'm trying to understand the reasons, but I just can't.
I'm pretty sure many people will use different hypervisor solutions because of this single decision. :(
SPICE was superior.

I set up some Windows builder VMs this week and ran across this bug. Spice works fine on my Fedora 35 laptop, and I use it to copy & paste large commands. For example, installing and starting OpenSSH in Windows is more complicated than Linux. Modern MS Windows Server OSes are very slimmed down, and Windows Server admins expect to do more CLI work now. Typing long commands into virt-viewer character-by-character is painful.

What packages do we need to support Spice server-side in RHEL 9? Maybe we could maintain those in a CentOS Stream SIG.

That would be awesome if possible...  I had to go with RHEL 8 because of SPICE removal in RHEL 9.  USB redirection, sound, etc worked great with spice even over a remote connections with Virtual Manager/SPICE.  The nice thing about SPICE also is that can be done directly to the host itself (you don't have to route to the VM network side of things which can be problematic depending on network design/security).  I really hope someone turns this around and gets SPICE back into qemu (QXL driver, etc).  Even if it is an alternative SIG/repo, that would be better than nothing.  SPICE works really well for desktop workstation use for devs and IT.

I found an article below (with a lot of time and searching trying to find the info) to at least get clipboard and auto-resize working.  I couldn't find this info on any redhat articles.  It appears the VNC driver has those functions at least on RHEL 9.  Without easy USB redirection as well as sound though, it wasn't enough for the needs where I work.

At a minimum, redhat should document the info at the bottom of that article explaining that clipboard.  I think the qemu config addition at the bottom of the linked webpage below should be set by default for windows installs using libvirt/KVM/Virtual Manager on RHEL 9.  It would at least help some that don't need the SPICE USB redirection, SPICE remote sound, or management using SPICE/VirtualManager.
https://www.reddit.com/r/qemu_kvm/comments/sytgvd/clipboard_without_spice/

I found from my testing with a win11 VM that qemu-vdagent cannot be set in the actual XML as a controller,etc yet.  qemu-vdagent can't be parsed using virsh edit.  There is work upstream that seems to have that implemented but redhat 9 doesn't have it yet.  There is even work on VirtualManager this past month to allow qemu-vdagent to be set using the GUI.  That also is not part of RHEL 9 (yet?).  You have to use <qemu:commandline> tags manually to get it working through libvirt (make sure to add the xmls at the top of the XML file or the validator won't be able to parse the <qemu...> tag).

I also can not get dynamic screen resolution working.  I suspect that is just not a thing for qemu-vdagent.

And finally, I could not get copy paste to work until I found a post on a mailing list somewhere (after much searching) that mentioned that virt-viewer does not support copy paste so you have to use realvnc package executable (vncviewer) with qemu-vdagent.  I figured VirtualManager might be the same so I connected to the qemu instance with the realvnc vncviewer and sure enough... copy paste works.  I could never get it to work with a lot of effort with VirtualManager so all that time I thought there was a problem with how I was setting it up with the <qemu..> tags but since realvnc works, it must just be a problem with VirtualManager.

This is some things that I think need to be in place for qemu-vdagent to be a good easy solution for copy/paste(that used to use spice) on RHEL 9.  It does not solve the dynamic screen resizing, easy USB redirection (through SSH even), and sound that SPICE provided though.

1. libvirt needs to be updated (or backported feature) so know about the qemu-vdagent.
2. VirtualManager needs to be able to setup a qemu-vdagent (similar to the spicevmc).
3. Need to figure out why VirtualManager doesn't work with copy/paste but the rhel9 realvnc rpm package (vncviewer executable) does.

Correction.  I meant to say tigervnc rpm package supports copy paste with newish VNC qemu clipboard feature instead of realvnc (realvnc third party app doesn't work with it).  Virtual Manager gui on RHEL doesn't seem to support the qemu clipboard feature... or at least doesn't work with it.

@agibson2 I wonder who would know what all packages we would need to rebuild for EL9 to provide full Spice support (i.e. both in guest drivers for VM's themselves, and the qemu infrastructure drivers, and the bits needed to re-integrate Spice with virt-manager?

Another thing to keep is dual screens/monitors.  Spice was able to add an additional QXL display, but changing the number of heads in the XML in the adapter doesn't appear to work with VNC in this build.

I don't have specific knowledge of what all was done to remove it but from what I read...  The XQL video driver would need to be compiled for the kernel, Not sure what USB redirection stuff would need to be put back in, qemu would need to have the patches removed that remove SPICE support(?).  Currently, SPICE is still in the GUI (Virtual Manager) to be able to add SPICE stuff, but hopefully they don't remove that stuff too in the future.
I have a feeling this would be a popular project to do something like this.

I found this bugzilla about removal of SPICE and they list things that might have been done to remove SPICE support...

https://bugzilla.redhat.com/show_bug.cgi?id=1946939

"Description of problem:
SPICE has been deprecated in RHEL-8.3 and is to be removed from RHEL-9.

Please:
- Disable support for SPICE components (graphics, smart-card, USB, etc)
- Remove SPICE components from the default configuration (including QXL)
- Remove "Requires: spice-gtk3" in virt-manager.spec"

I don't know that all of that was done though.  It would be great to get input from the developers that removed it so that any project to put it back would be much easier.  I am not sure who has the skills to do such thing though.  I have seen this appear on the Rocky Linux chat and forums too wanting a SIG for putting it back in.

My virtualized development machines are almost unusable with VNC on RHEL 9. As a result, I decided to rebuild the packages myself, so I could enable SPICE support. It felt like the like the superior alternative, with said alternative being a commercial/propitiatory solution.

I'm not an expert, but I was wondering if Red Hat couldn't simply use the VP 8 / VP 9 codec(s) to for streaming, and avoid the H264 licensing issue? 

Either way, anybody else facing this same problem can use my RPMs (or use the included script to build their own). The files are available here:

https://github.com/ladar/qemu-spice-el9

If there is enough interest, I can setup a DNF repo in the future.

I was going with RHEL8 because of this but I installed a RHEL9 to keep experimenting with it to see how close I could get to a good experience on RHEL 9 and libvirt/qemu/VirtualManager but it has a lot of issue.

Spice USB redirection was very easy to use on previous RHEL versions.  There is native host USB passthrough in RHEL9 but it is a bit troublesome to use.  Adding a USB host device to the VM is relatively easy but then the host requires it to be running and unplugging and plugging back in the device, the VM doesn't always see it.  I never had that issue with SPICE usb redirection.

Audio is another huge issue.  With spice on previous RHEL versions, audio worked great.  You now have to manually figure out how to connect the VM audio to jack or pulseaudio which after lots of struggling, I still haven't been successful and seems to require manual XML edits to even attempt it.  I tried a workaround of using a USB headset and USB Host passthrough to listen to audio but that has the problems mentioned above where sometimes plugging and unplugging it, it stops working.  Using the native audio hardware though would be much preferred anyway.

Then to work around copy-paste issue, I had to do lots of searching to find manual XML edits to get that working and that only works with tigervnc VNC client so the native Virtual Manager doesn't support qemu's native copy-paste feature.

All of this just adds up to a very bad experience for my use case compared to previous RHEL versions that supported SPICE.

(In reply to Ladar Levison from comment #13)
> Either way, anybody else facing this same problem can use my RPMs (or use
> the included script to build their own). The files are available here:
> 
> https://github.com/ladar/qemu-spice-el9
> 
> If there is enough interest, I can setup a DNF repo in the future.

I've tested it (AlmaLinux 9.1). Works, but you get the feeling that half of the system has been replaced (several hundred packages), so this rises some security issues. And I assume that maintaining the packages will be an effort of its own (I'm impressed by your work).

I've just tested to run Fedora libvirtd in a container as outlined here (https://projectatomic.io/blog/2014/10/libvirtd_in_containers/). Although this is from 2014 it basically still works (VM runs, sound and USB redirect work, some minor issues remain to be clarified). I think this will be my way to go (and if RedHat drops spice support from Fedora as well, I can switch to some other base system for libvirtd).

Remote access to my Workstation (running as a VM) over the internet is a major use case for running my server in the first place and I'm just setting up a cluster to make this available for others as well. So dropping the support for this just now is really bad timing. And I still don't get the reasons. I have found no indication that the qemu project is going to drop spice support. So why does RedHat deliberately cripple a great solution?

(In reply to Michael Lipp from comment #15)
> 
> I've tested it (AlmaLinux 9.1). Works, but you get the feeling that half of
> the system has been replaced (several hundred packages), so this rises some
> security issues. And I assume that maintaining the packages will be an
> effort of its own (I'm impressed by your work).

In terms of maintaining it, I've automated the entired process. I run one (albeit very long) command, and 2-3 hours later, I have a set of updated RPMs. The trick is knowing when a rebuild is necessary, and then tolerating all the huffing and puffing as my middle aged laptop does the work.

The _total_ number of packages in the git repo is rather inflated, since it includes all of the source/debug/debugsource packages, plus some of the dependencies which aren't available from the default repos (or EPEL). I include those so users can won't need to install/setup a new DNF repo just to install these packages.

As for your other concerns. they have also crossed my mind, especially given that I have started rebuilding the libvirt packages as well. Which is why, I only plan to use the rebuilt packages on my workstations, I plan on sticking with the official RPMs on my servers, where stability/security take precendence. At least for now, as the servers are rarely run graphical applications of any kind. Plus, my servers don't have discrete GPUs, so the impetus for needing SPICE is missing.

Long term I'm hoping RH will realize how many customers (and developers) they're hurting, and find a long term solution which allows for accelerated virtualized environments, and included with a point release.

If not, then perhaps a SiG will need to form which can maintain an alternative package set, like the CentOS advanced virt SiG did once upon a time.
 
> I've just tested to run Fedora libvirtd in a container as outlined here
> (https://projectatomic.io/blog/2014/10/libvirtd_in_containers/). Although
> this is from 2014 it basically still works (VM runs, sound and USB redirect
> work, some minor issues remain to be clarified). I think this will be my way
> to go (and if RedHat drops spice support from Fedora as well, I can switch
> to some other base system for libvirtd).

Part of the reason I have to rebuild so many packages is because I'm actually rebuilding the Fedora packages, which provide newer versions. Since Fedora provides more functionality, that means more dependencies which aren't available on RHEL (or the RHEL version isn't new enough). 

I believe someone else forked my work, and used it to created a less ambitious variant which only recompiles a handful of RHEL packagers with SPICE support. 

> Remote access to my Workstation (running as a VM) over the internet is a
> major use case for running my server in the first place and I'm just setting
> up a cluster to make this available for others as well. So dropping the
> support for this just now is really bad timing. And I still don't get the
> reasons. I have found no indication that the qemu project is going to drop
> spice support. So why does RedHat deliberately cripple a great solution?

It's because RH is focused on containers, and Kubernetes, and OpenStack (in my opinion) and not on graphical desktops (aka workstations), or virtualization. The cloud is where their business is focused right now, and unfortunately, it led them to drop a lot of critical tools/packages in v9 that developers/power users with GUI Workstations running RHEL depend on. Supporting those packages isn't critical for cloud/corporate/container users/customers.

(In reply to Michael Lipp from comment #15)
> I think this will be my way to go 

See https://github.com/mnlipp/libvirt-container

(In reply to static from comment #14)
> Audio is another huge issue.  With spice on previous RHEL versions, audio worked great.  You now have to manually figure out how to connect the VM audio to jack or pulseaudio which after lots of struggling, I still haven't been successful and seems to require manual XML edits to even attempt it. I tried a workaround of using a USB headset and USB Host passthrough to listen to audio but that has the problems mentioned above where sometimes plugging and unplugging it, it stops working.  Using the native audio hardware though would be much preferred anyway.

This is the blocker, for me. For my use case audio with sane latency is a requirement. With SPICE getting yanked out, I'll have to <shudder> go back to VirtualBox or VMWare Workstation. I'm not happy about that.

Unfortunately, I'm a self-support user - but I thought I'd throw my $0.02 in here.

----

I don't understand why H.264 licensing has anything to do with this - that specific codec is a hard requirement for the protocol? That seems like a bad architectural decision, if true. There's plenty of open-source friendly A/V codecs and containers out there.

Seems like the commercial incentive to develop better codec doesn't exist anymore. I wonder if ZFS/btrfs is stuck a similar situation. RHEL can be a more versatile solution with open transcoding, vGPU, and ZFS.

I have built rpm packages in my Copr project -  https://copr.fedorainfracloud.org/coprs/aminasyan/el9-collection
Based on the github fork of qemu-spice-el9  https://github.com/corrmaan/qemu-spice-el9
Feel free to use or rebuild from the spec/srpm.

I rebuilt the QEMU KVM stack only with SPICE enabled for our own purposes:
https://copr.fedorainfracloud.org/coprs/ligenix/enterprise-qemu-spice/

This basically KILLS RHEL/RHV as a VDI solution 100%.

How can you do PIV card logins if you can not dynamically redirect the USB card reader???  On a dedicated desktop you can try to manually add the USB device but if the user unplugs it and plugs it into a different USB port????


Don't care about the video.  If the video is all that was hitting the license issue then just take it out.  Even sound is not a must have BUT *DYNAMIC* USB redirection is an ABSOLUTE BLOCKER.


Is there any way to just start with bringing back USP redirection???   Maybe by creating a virtual mapper device node on the KVM server and using redir to redirect one TCP port for each USB device then on the client create a virtual dev device for each USB device that channels the USB into redir and over to the server virtual device that gets auto-mapped to the VM???

USB is just unfortunately too essential these dats.  Smart card readers, printers, USB drives, etc.  The clipboard support should just be in VNC but even that is not as essential as USB.

Hello. I've just arrived to the VMs and containers world. I think Xpra could be a solution for dual monitor/audio problem. It can serve applications in seamless mode and full desktops. 

https://www.xpra.org/
https://github.com/Xpra-org/xpra

After upgrading our admin pc to RHEL9, we just found, that we are no longer able to access the physical key management system of our facilty door locking system. The master was connected via USB redirection to the VM running physical key management software... Should we downgrade now to CentOS7 again?

+1

We've been using multi-monitor QXL+SPICE support for many years.

Sad to see this feature go. In our case we need `remote-viewer` to spice connect to an EL8 system (libvirt+KVM+QXL), but from my el9 workstation it says "Unsupported grpahic type 'spice'".  Fortunately el8 is good til 2029, but hopefully a solution is found in a later 9.x or RHEL 10 before el8 is EOL.

It looks like there are some options rebuild/COPR options provided above (thanks!), but I hope that ultimately gets fixed in a 9.X release.

This BZ is marked "CLOSED DEFERRED" .  What does DEFERRED mean?  Deferred until when?

FYI for others who need `remote-viewer` or `virt-viewer` to work with spice on el9.  This COPR repo worked to connect to an EL8 server with SPICE+QXL w/ multiple monitors:

```
dnf -y copr enable aminasyan/el9-collection
dnf install --disablerepo=ol9_appstream virt-viewer
dnf -y copr disable aminasyan/el9-collection
```

Big thanks to @AramMinasyan for putting up the COPR repo.

Also why is this marked as "Closed" when it is still very clearly a BIG open issue with NO REPLACEMENT or fix for MANY MANY people?

TOTALLY get why it HAD to be pulled from 9 but why is it CLOSED when it is an OPEN BIG issue?  Is it because there is no known solution and you don't want a case sitting open too long?  Why not open it and see if we here can find a solition?

What about the solution @mvmiguel posted?  Do you think that can work?

------------------------------------------------------------------------------------------
Hello. I've just arrived to the VMs and containers world. I think Xpra could be a solution for dual monitor/audio problem. It can serve applications in seamless mode and full desktops. 

https://www.xpra.org/
https://github.com/Xpra-org/xpra
------------------------------------------------------------------------------------------

If so I bet a LOT of people here can assist with coding and I can certainly assist with any and all testing.  I and I think MANY other would VER much like to see a tech preview of a fix provided in RHEL 9!



*****To all those who agree please reply with "+1" so we can get a tally of who agrees AND please DO say if you can help!!!  I am not a Dev but an Admin/Engineer/Architect with RH since 2001 in PROD.  I have TONS of lab hardware from HP blade servers to physical servers and even RHV and VMware VMs to be able to test with.

+1

(In reply to Steven Mercurio from comment #28)
> Also why is this marked as "Closed" when it is still very clearly a BIG open
> issue with NO REPLACEMENT or fix for MANY MANY people?
> 
> TOTALLY get why it HAD to be pulled from 9 but why is it CLOSED when it is
> an OPEN BIG issue?  Is it because there is no known solution and you don't
> want a case sitting open too long?  Why not open it and see if we here can
> find a solution?

Indeed!

> What about the solution @mvmiguel posted?  Do you think that can
> work?

XPRA isn't a VM terminal solution, its a way to keep programs open while disconnected and it is X Windows specific.

What SPICE+QXL provided was:

- Integrated multi-monitor low-latency remote console
- Native hotplug USB
- Audio support
- Copy-paste via guest agent integration in both Windows and Linux

Basically, SPICE is awesome, provides a true VDI experience, and VNC (which EL9 is limited to) is just for display (ie, display-only).  VNC is great for display, I've used it since the 90's, but it is unlikely to ever support the features that SPICE does.

If the only problem is codec licensing, then for goodness sake, just change the codec.

Ok, so given this is a codec issue does ---ANYONE--- have ---ANY--- suggestions on what codec ---CAN--- be used in place of the one that can not???


VIRT-MAINT team:  Do you have any ideas on a possible codec that can be used here?

Can we fork a previous version of the existing codec form a time when it was open source?

ALL,

Red Hat is moving from BZ to Jira and this issue has been opened as this case:

https://issues.redhat.com/browse/LIBVIRT-946

As of now I do not have the ability to see the case and have asked that it be opened so all of us here can try to work towards a solution.

For npw Please do keep adding "+1" if you are affected by this but if anyone has ANY suggestions on a replacement codec PLEASE do reply withy any codecs that may work here.

All,

The new case for this that can be seen is this one:

https://issues.redhat.com/browse/RHEL-16530

As the LIBVIRT-946 one seemed to be only for internal Red Hat access.  The above case should be more visible to all.

Clearing the NEEDINFO on virt-maint because it is not necessary. There are enough NEEDINFOs as it is, and besides, the issue has been migrated to Jira.

Hi,

I'm rebuilding on a regular basis for CentOS Stream and EPEL 9 the last QEMU KVM stack packges from CentOS Stream, with last SPICE stack packages from Fedora ELN, enabled and depending on new libsoup3 library. Could someone precises where does the codec issue sit ?

https://copr.fedorainfracloud.org/coprs/ligenix/enterprise-qemu-spice/

(In reply to Jeff Nelson from comment #35)
> and besides, the issue has been migrated to Jira.

> You can't view this issue
> 
> It may have been deleted or you don't have permission to view it.

We can't see the Jira issue (LIBVIRT-946). At least, I can't.

Oh, shoot, that's something else. Please accept my apologies.

The proper URL for that looks like https://issues.redhat.com/browse/RHEL-16530

RE: "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."

Is there a reason you cannot remove (or not include) the licensed drivers ? It makes no sense to break users setups over such an easy fix (and if it's not easy, get with the people who make spice and ask them to move the licenced software to a separate RPM/exe).

We have an offline system with a MS A/D server, DBs, IIS web server and an admin terminal. We use gnome kiosk to run the VM directly so users are not exposed to the underlying linux.
Product updates, patches etc are brought in on usb and connect through to the admin terminal. High intensity graphics using a H264 driver (or any other licenced driver) is not required.

Using VNC doesn't work. Spice was better than VNC and that was it's job.
The graphics artefacts (lines and other glitches are terrible) using VNC on a Dell 7780.
If this doesn't change or a new substitute is not found, we are going to have to run vmplayer or virtualbox or just return to windows and use HyperV (cause we already pay for a licence for that). Bye Bye RedHat subscription then.

Thanks
Peter H

Clearing out the needinfo here - see the attached issue for follow up discussion instead.

Ok so this is easy *IF* we can answer this ONE question.

What *other* codec can do what the H.264 codec did - If does NOT have to do it WILL (YET) It just has to have the functionality to DO that the H.264 codec did.


 | | | | | | | | | | | | | | | | | | | | | | | | |
 V V V V V V V V V V V V V V V V V V V V V V V V V

What *other* codec can do what the H.264 codec did?

 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
 | | | | | | | | | | | | | | | | | | | | | | | | |

Ok so this is easy *IF* we can answer this ONE question.

What *other* codec can do what the H.264 codec did - If does NOT have to do it WILL (YET) It just has to have the functionality to DO that the H.264 codec did.


 | | | | | | | | | | | | | | | | | | | | | | | | |
 V V V V V V V V V V V V V V V V V V V V V V V V V

What *other* codec can do what the H.264 codec did?

 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
 | | | | | | | | | | | | | | | | | | | | | | | | |

Steven,
My understanding is that H264 provides phenomenal compression. 

There are some use cases where we don't need that.
In my case, and quite possibly many Department of Defence's around the world, RHEL is used as a hypervisor on standalone PCs or laptops. They run VM's that contain the product of choice for that system. The removal of Spice will harm us, and separate support calls will be logged.

Given this use case, it matters not what H264 can do, because there is no network involved. It could also be said that compression in this use case is a waste of CPU cycles.

Looking at the spice-gtk code, I can see that other codecs are available.
grep SPICE_DISPLAY_CAP_CODEC src/channel-display-priv.h
    { SPICE_DISPLAY_CAP_CODEC_MJPEG, "mjpeg",
    { SPICE_DISPLAY_CAP_CODEC_VP8, "vp8",
    { SPICE_DISPLAY_CAP_CODEC_H264, "h264",
    { SPICE_DISPLAY_CAP_CODEC_VP9, "vp9",
    { SPICE_DISPLAY_CAP_CODEC_H265, "h265",

I could do more work to investigate this, but if there are multiple codecs available, then there must be code for choosing the best one.
It seems to me that the commenting out of the licenced codecs and removal of the binaries is well possible.

Apologies for upsetting you, but I feel that the experts at RedHat could reasonably find a way to manage this, in communication with the people who produce Spice - to give their paying customers the best experience.

P

(In reply to Peter H from comment #39)
> RE: "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."
> 
> Is there a reason you cannot remove (or not include) the licensed drivers ?
> It makes no sense to break users setups over such an easy fix (and if it's
> not easy, get with the people who make spice and ask them to move the
> licenced software to a separate RPM/exe).
> 
> We have an offline system with a MS A/D server, DBs, IIS web server and an
> admin terminal. We use gnome kiosk to run the VM directly so users are not
> exposed to the underlying linux.
> Product updates, patches etc are brought in on usb and connect through to
> the admin terminal. High intensity graphics using a H264 driver (or any
> other licenced driver) is not required.
> 
> Using VNC doesn't work. Spice was better than VNC and that was it's job.
> The graphics artefacts (lines and other glitches are terrible) using VNC on
> a Dell 7780.
> If this doesn't change or a new substitute is not found, we are going to
> have to run vmplayer or virtualbox or just return to windows and use HyperV
> (cause we already pay for a licence for that). Bye Bye RedHat subscription
> then.
> 
> Thanks
> Peter H

Agree, Spice can still be maintained as a basic software infrastructure for the libvirt/kvm community without including those licensed tech. 
Base on that RH can folk toward open vGPU codec, or enabling more intensive guest side hardware (e.g. external GPU), or not to further develop it.

With VNC, I don't know how RH can enable these (e.g. why RH+VNC will be a vGPU choice for client). Its could be a decent cost cut, but it also remove a lot of capabilities/possibilities of having RH as a competitive hypervisor OS

(In reply to Fanky W from comment #44)
> (In reply to Peter H from comment #39)
> > RE: "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."
> > 
> > Is there a reason you cannot remove (or not include) the licensed drivers ?
> > It makes no sense to break users setups over such an easy fix (and if it's
> > not easy, get with the people who make spice and ask them to move the
> > licenced software to a separate RPM/exe).
> > 
> > We have an offline system with a MS A/D server, DBs, IIS web server and an
> > admin terminal. We use gnome kiosk to run the VM directly so users are not
> > exposed to the underlying linux.
> > Product updates, patches etc are brought in on usb and connect through to
> > the admin terminal. High intensity graphics using a H264 driver (or any
> > other licenced driver) is not required.
> > 
> > Using VNC doesn't work. Spice was better than VNC and that was it's job.
> > The graphics artefacts (lines and other glitches are terrible) using VNC on
> > a Dell 7780.
> > If this doesn't change or a new substitute is not found, we are going to
> > have to run vmplayer or virtualbox or just return to windows and use HyperV
> > (cause we already pay for a licence for that). Bye Bye RedHat subscription
> > then.
> > 
> > Thanks
> > Peter H
> 
> Agree, Spice can still be maintained as a basic software infrastructure for
> the libvirt/kvm community without including those licensed tech. 
> Base on that RH can folk toward open vGPU codec, or enabling more intensive
> guest side hardware (e.g. external GPU), or not to further develop it.
> 
> With VNC, I don't know how RH can enable these (e.g. why RH+VNC will be a
> vGPU choice for client). Its could be a decent cost cut, but it also remove
> a lot of capabilities/possibilities of having RH as a competitive hypervisor
> OS

(In reply to Peter H from comment #39)
> RE: "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."
> 
> Is there a reason you cannot remove (or not include) the licensed drivers ?
> It makes no sense to break users setups over such an easy fix (and if it's
> not easy, get with the people who make spice and ask them to move the
> licenced software to a separate RPM/exe).
> 
> We have an offline system with a MS A/D server, DBs, IIS web server and an
> admin terminal. We use gnome kiosk to run the VM directly so users are not
> exposed to the underlying linux.
> Product updates, patches etc are brought in on usb and connect through to
> the admin terminal. High intensity graphics using a H264 driver (or any
> other licenced driver) is not required.
> 
> Using VNC doesn't work. Spice was better than VNC and that was it's job.
> The graphics artefacts (lines and other glitches are terrible) using VNC on
> a Dell 7780.
> If this doesn't change or a new substitute is not found, we are going to
> have to run vmplayer or virtualbox or just return to windows and use HyperV
> (cause we already pay for a licence for that). Bye Bye RedHat subscription
> then.
> 
> Thanks
> Peter H

Agree, Spice can still be maintained as a basic software infrastructure for the libvirt/kvm community without including those licensed techs. 
Based on that RH can fork toward open vGPU codec, or enabling more intensive guest side hardware (e.g. external GPU), or not to further develop it.

With VNC, I don't know how RH can enable these. It could be a decent cost cut, but it also removes a lot of capabilities/possibilities of having RH as a competitive hypervisor OS

Furthermore, the vGPU, MxGPU, GVT-g are developmental things in virtualization. RH should not anchor too quickly into a VNC-only solution with its long support cycle. (e.g. why RHEL+VNC+vGPU will be the only setup that an RH hypervisor client would need).

The "best" part about this, is that https://www.openh264.org exists nowadays.

Note: Red Hat has already closed the JIRA issue as "won't fix." If you're affected by this, please reach out to your account manager or whatnot to make noise about this.

Adding data to this ticket, or the JIRA issue, is likely to do absolutely nothing.

My understanding is that Spice is a technology dependent from Red Hat funding.
We obviously all agree that this technology is already relevant, mature, and production ready.

The question is not about some codec, but whether Spice is sustainable without being part of RHEL.
As far as I have tested it, it is working well with Debian 12 and the latest Fedora.

A feedback from Red Hat on whether it is dead or not would be nice, but their choice.
This is and has always been how free/libre software is working.

Cheers,

Mathieu

I already asked a new case be created or the Jira reopened.  The closing comment on spice will not be added to RHEL 9 but that I should open a new ticket to add <list of what spice did> to RHEL 9 mazes ZERO sense@!  So then just don't call it spice???  What ever happened to just edit the description and title to remove the word "SPICE" and replace it with the list of what spice did?!?!???

I am curious what is the actual situation. For me, RHEL + libvirt/kvm + spice (not RHV) is a proven good hypervisor platform for small-scale projects (~10VMs). Command lines interface and long support cycle are critical differentiation. Looking up another distro requires extra risk-taking time-consuming venture for me.

Spice is a more basic infra than RHV and vGPU. The logic become vague if killing RHV or adopting vGPU are the reason to deprecate spice. 

I think possible scenarios are
1. RH doesn't have many customers using RHEL+libvirt+spice (customers don't recognize its good? cost drive?)
2. RH wants customers to shift to VNC (commercial drive? security drive?)
3. Other reasons (developers shifted? communication breakdown?)
Different cases will require different community support, perhaps RH can clarify what they are thinking behind the scenes...

I am curious what is the actual situation. For me, RHEL + libvirt/kvm + spice (not RHV) is a proven good hypervisor platform for small-scale projects (~10VMs). Command lines interface and long support cycle are critical differentiation. Looking up another distro requires extra risk-taking time-consuming venture for me.

Spice is a more basic infra than RHV and vGPU. The logic become vague if killing RHV or adopting vGPU are the reason to deprecate spice. 

I think possible scenarios are
1. RH doesn't have many customers using RHEL+libvirt+spice (customers don't recognize its good? cost drive?)
2. RH wants customers to shift to VNC (commercial drive? security drive?)
3. Other reasons (developers shifted? communication breakdown?)
Different cases will require different community support, perhaps RH can clarify what they are thinking behind the scenes...

All,

I plan to open a RH RFE for restore first USB redirection then if possible Linux file system mount in guest OS and sound redirection.

Also I just got tis SAD update from RH (SAD because there has NEVER been a better time for Linux as a desktop OS with HW support now BETTER than that other "OS":

=========================================================================

Martin Tessun on 2023/11/22 5:24 AM
 
Hi Steven,

because Red Hat will not invest in Client tooling for this anymore. SPICE has been dropped and will not be replaced. In order to run VDI like setups, you will need to have 3rd party tooling. For normal management activities VNC is available.
If you are missing specific features that only SPICE did provide, feel free to open an RFE on that specific feature. It will be triaged and acted upon accordingly.
Things like multi monitor support and other features clearly related to a remote desktop environment will only be available via 3rd pariy products, but not within RHEL anymore.

Hope that clarifies why this got closed.
Cheers,
Martin

 
cid:jira-generated-image-avatar-ca8265e9-18ad-4562-9b99-6460e2a28a7f	Martin Tessun on 2023/11/22 5:25 AM
 
Hi Steven,

because Red Hat will not invest in Client tooling for this anymore. SPICE has been dropped and will not be replaced. In order to run VDI like setups, you will need to have 3rd party tooling. For normal management activities VNC is available.
If you are missing specific features that only SPICE did provide, feel free to open an RFE on that specific feature. It will be triaged and acted upon accordingly.
Things like multi monitor support and other features clearly related to a remote desktop environment will only be available via 3rd pariy products, but not within RHEL anymore.

Hope that clarifies why this got closed.
Cheers,
Martin

=========================================================================


What is surprising is that RH is PUSHING customers TO things like VMware workstation which as that point why use RHEL and just use Rocky Linux 9 with the COR repo to put SPICE back OR just use ANY Linus OS like Rocky and go with VMware workstation.

Since IBM it seems RH has started loosing touch with customers and doing a lot more profit centered things like this.  If they would just make a Samba/WinbindD to IDM proxy for example you can ditch AD and use IDM as a single central auth source!  OR if they just put ALL the IDM/SSO/Cert products under a single Sat6-like "Red Hat ID Management" entitlement that you pay for per connected client that allowed you to use all the ID Mgmt/SSO tools like Directory server, etc. that wold allow anyone to get rid of AS as well.

PLUS I hear you can install OpenRadius and use that to get Cisco gear to auth against IDM which I am going to try out soon.

All,

2 new cases have been opened for bringing back USB redirection and mounting a Linux directory in the guest file system.  Given that RH is no longer working on client tooling spice as a whole will not be brought back so the only things that can be done is individual RFE cases for the features we need that were lost.  This is the start of that.


Please DO VOTE for these 2 Jiras and add yourself as a watcher so RH knows how many people need this:



Here are the links.  Keep in mind that though they appear to be public for view.  At some point it may get marked private, but for now they are public.

https://issues.redhat.com/browse/RHEL-17665 - USB passthrough
https://issues.redhat.com/browse/RHEL-17666 - remote filesystems

Easy sound output to client is missing too.

What was nice about virt-manager is that you could pass all of that stuff through SSH and have access to USB redirection, audio, remote filesystem, etc.  With virt-manager and it's easy ssh tunneling, you could manage lots of other system with it too using a GUI.  It really is/was a nice solution for simpler IT/Dev setups.  It seems to me like any alternative to spice has a lot to measure up to.  Virt-manager worked for windows, linux, etc VMs.  It just worked.

Hi all,

I have also rebuilt the Fedora's QEMU stack with SPICE and PipeWire enabled for devel purposes.

https://copr.fedorainfracloud.org/coprs/ligenix/enterprise-qemu-wider/

Cheers,
Jean-Marc

I have been using oVirt for about ten years, mostly on Spice features, and also proxy, to give somewhat secure access to VM's console on outside networks, to private networks, beside the USB redirection and all Spice features.
If h.264 is "licencesed", just using another protocolo would do. 
But deprecating, first, and supporting only VGA (not QXL) and VNC ...........makes me think of another VM manager. 
Really, what's happening here ?
oVirt, and RHEVM used to be a very good solution, but if you leave like it is as of now, what a pity it would be to left it.

It's only a recongiztion of "I don't want to think of a solution for our customers, but for only for us to 'simplify' our work.
If this is the kind of solutions now in RedHat.....it's time to think for others.

This is unfortunately the typical Red Hat MO.  Ovirt and anything Spice did is DEAD.  Spice was just something that needed to go away because it is not a part of the latest colored butterfly ADD RedHat saw and is now chasing and fixated on.  This happened to Satellite 6, bnow overt/RHV, and I sincerely believe Ansible could even be next.  Sat6 is a bread and butter staple and how maintenance gets done BUT thankd to RH with the WORST case of ADD a corperation can have things like big fix an tiamium have taken over and filled that need all be it BADLY.  Ovirt/RHv started it's fall as soon as OpenShift came into view starting with Spice and not ovirt itself for OpenShift Virtulization.

I STILL see a BIG lag in timely updates and no uptake of selinux and RH is off chasing butterflies like openshift and even PCP which is DPOOMED to fail when for security reasons ANY server is NOT akllowed at all to run X or any additional services so maybe that new PCP butterfly will be the start of the fall of ansible?

Before you say that can NEVER happen look at Satellite 6 and not Ovirt - Bread and butter and not pretty butterflies and rainbows anymore - where are they now.