VMware on Silverblue/Kinoite

Yes, GNOME Boxes and virt-manager are available on Fedora atomic desktops.
And even virtualbox is easier to add.

But… Windows VMs graphics [basic things like translucency, etc…] only work with VMware, so do many other conveniences.

Similar post on reddit for reference

Kernel modules
https://rpmfusion.org/Packaging/KernelModules/Kmods2

https://rpmfusion.org/Packaging/KernelModules/Akmods

The above links have instructions to ship a kernel module pre-compiled or source.

Following such standards [or/and akmods], is it possible to ship VMware kernel modules for immutable distros?
Either just for specific fedora kernels or a dkms-like all-kernel approach, for all kernels. I know that this has already been done for nvidia, etc…

And how is the depmoding managed? IDK
But IK that nvidia is used in a similar way.

Also, the modules need to be patched to work with newer kernels, something which needs to be done in the package itself for immutable distros [You can’t compile the modules except at the package, or pre-compiled].
The patches

Plz… some help… I will help to provide the compiled binary files, as well as a specfile to the best of my capabilities.

[The kernel part needs to be rpm’d, to simplify VMware installation and usage on atomic desktops. I am talking of those newcommers from windows etc… who will not know how to run the commandline.
However, the userspace part can easily be installed into /usr/local (in kinoite /var/usrlocal), but it is still not what an average basic person would want to do. Plz discuss and provide opinions and suggestions on packaging the userspace part, whether alongwith or separately the kernel modules (solving version mismatches), or not at all.]

Userspace applications
The vmware install script installs a mini-distribution into /usr/lib/vmware, and some binaries hooked into it, in the system’s /usr/bin.

It is possible to change the install prefix by passing --eulas-agreed --custom to the install script [I choose /usr/local], but then it asks for a suitable /etc/rc?.d folder, failing to accept any folder I pass it. [passing it empty works, but IDK what goes on]

[Am not writing about manual installation since nothing is there to discuss]

However in Kinoite, if it is rpm’d, it needn’t [infact shouldn’t] install to /usr/local, but just /usr. But /opt/vmware is also an option, if you think that the mess is not to be put in /usr.

To be rpm’d with or without the modules [1 package or separate]?

Also, if the rpm, plz suggest on what to do for the CEIP [which sends a small amount of anonymous data]? Select no, sure, but plz tell if you think otherwise.

VMware in Toolbox
Yes, the userspace applications can be installed. Will they run fine? [In /usr/lib/vmware it has it’s own versions of many common libs like pango, glib, libX11 etc… which fail with the dynamic linker error on gentoo, will soon update with what happens in toolbox]

What about the kernel modules? Can you load them through a toolbox? Mostly not. But if they are packaged as per the 1st section of this post, programs in toolbox will mostly work.

OR should they just be packaged into an rpm?
OR flatpak [mostly not possible]?

If RPM, mostly it will end up in RPMFusion.

Plz give suggestions and opinions, as well as experiences.
The important part is the kernel modules, rest can be done later, or just ignored for now.

NOTE: The building, testing etc… will be done in a toolbox before applying on the system.

No it is not done that way.
The akmod-nvidia package requires building a kernel module for each specific kernel version.

Providing a kmod-nvidia package is done for RHEL and Centos, but those are stable LTS kernels and do not see updates on a frequent and regular basis. Fedora instead builds a new kernel module for each kernel when it is installed.

$ dnf list --installed kmod-nvidia-*
Installed packages
kmod-nvidia-6.12.9-200.fc41.x86_64.x86_64       3:565.77-1.fc41 @commandline
kmod-nvidia-open-6.12.10-200.fc41.x86_64.x86_64 3:565.77-2.fc41 @commandline
kmod-nvidia-open-6.12.11-200.fc41.x86_64.x86_64 3:565.77-2.fc41 @commandline
kmod-nvidia-open-6.12.9-200.fc41.x86_64.x86_64  3:565.77-2.fc41 @commandline

I suspect that since VMWare is proprietary your goal may be out of reach. The differences in each kernel version would make this a difficult task and probably would require a similar approach to what is done with nvidia – build a new module locally for each kernel.

On the atomic desktops it is quite possible to install the nvidia drivers and locally compile the modules by following the guide at rpmfusion

You might be able to use a rootful container. I run dockerd in a rootful container (sudo podman build) derived from fedora:41 using quadlet.

Plz let me know on how exactly this works.
BTW,
Most Kinoite users will use the default kernel, and I can ship pre-built modules upto a few versions of the default kernel, for the average user.
However, if akmod is easy enough for the average user of SB/Kinoite, then even VMware would be easy. Plz link me the documents describing akmod[-nvidia]

VMware is infact proprietary, but the module sources are packed in a tarball somewhere under /usr/lib/vmware. They only depend on linux-headers [at build-time].
I have compiled them in gentoo linux [some other distro].

Fine, thay way. But plz, it should be neatly wrapped in a way the average user could do, by just pasting 2-5 commands into the terminal, or not even that. If nvidia is possible, then mostly surely this.

No, nested containers always were possible. This is about loading externally compiled kernel modules from within a container [rootful is fine]. [Compiled later for a precompiled kernel]

Unrelated but related post, running VMware (userspace part) in toolbox/distrobox:

Sorry, some setbacks. Will soon be back with a specfile and an rpm.

The specfile is fine and ready; But the modules fail to compile for some reason. Trying to re-install vmware via script in a toolbox, will update soon/

Due to various quirks and issues, I am unable to prepare a package at all. Sorry

Will be back soon with a breakthrough.

For the daring who are ready to hack into their readonly rootfs;
[Untested; Breaks immutability guarantee by making rootfs mutable]
[Don’t blame me or fedora if system breaks; You can recover much easier than non-ostree systems, but still requires running obscure ostree commands]
[I haven’t tried, so haven’t many; If you have you may want to describe your experience]
[WARNING: Breaks immutability guarantee by making rootfs r/w mutable like traditional systems.]
run ostree admin pin 0 to pin your current rootfs deployment. [NEEDED for rollback; VERY important]

rpm-ostree usroverlay which actually is a wrapper ostree admin unlock, allows you to unlock the /usr for manual editing, where you can add/change random files into it.

Options like --transient and --hotfix further may help you do what you want.
Again, do this only if you know what you are doing; this is for developers who develop low-level components like rpm-ostree itself, who know what they are doing.

It may be fine on other OSes, but Kinoite is meant to be miles ahead in stability, and you pull it back to a breakable and unstable base-OS, like traditional OSes. Highly discouraged.

[Rollback is out of the scope of this post; It is readily available on various webpages; A few commands at most] [Again, avoid this unless you know what you are doing]

Broadcom’s VMware download page no longer has VMware installer for download, for windows or linux. VMware seems to be silently discontinued.

Sorry, this renders all effort useless.
I wouldn’t like to work on packaging a product which isn’t officially available, which would cause even more confusion.
It anyways wouldn’t be compatible, as even the patched kmods have started to segfault (and painc the host kernel). No new patches so far.

Don’t think you might patch yourself… the userspace part is closed-source, and you don’t know how it interacts with vmmon and vmnet. [Via /dev/vmmon and /dev/vmnet{0,1,8,etc.} character devices. But the interface…]

Sorry.

If VMware is again available, or if that was a temporary website issue on broadcom’s side, please reply here and let me know.