does virtualbox work on leap 15.2 rt kernel?

I get the “kernel driver not installed (rc=-1908)” when trying to start a Virtualbox VM in the rt kernel. Performing the suggested /sbin/vboxconfig doesn’t work either:

cat /var/log/virtualbox.log
=== Building ‘vboxdrv’ module ===
make[1]: Entering directory ‘/usr/src/kernel-modules/virtualbox/src/vboxdrv’
/usr/src/kernel-modules/virtualbox/src/vboxdrv/Makefile-header.gmk:193: *** Error: unable to find the headers of the Linux kernel to build against (KERN_DIR=/lib/modules/5.3.18-lp152.3.2-rt/build). Specify KERN_VER=<version> (currently 5.3.18-lp152.3.2-rt) and run Make again. Stop.
make[1]: Leaving directory ‘/usr/src/kernel-modules/virtualbox/src/vboxdrv’
make: *** [Makefile:59: vboxdrv] Error 2

I noticed I had a 3.5-rt kernel, but that just hung when trying to log in, so rebooted the 3.2-rt kernel I had been using all along.

Other info:

uname -a
Linux localhost.localdomain 5.3.18-lp152.3.2-rt #1 SMP PREEMPT_RT Mon May 18 10:32:23 UTC 2020 (b1281f3) x86_64 x86_64 x86_64 GNU/Linux

sudo zypper se -si virtualbox vbox kernel
Loading repository data…
Reading installed packages…

S | Name | Type | Version | Arch | Repository
—±---------------------------------±--------±-------------------------------------±-------±-------------------------
i+ | devel_kernel | pattern | 20170319-lp152.6.3 | x86_64 | Main Repository
i+ | kernel-default | package | 5.3.18-lp152.66.2 | x86_64 | openSUSE:Leap:15.2:Update
i+ | kernel-default | package | 5.3.18-lp152.66.2 | x86_64 | Main Update Repository
i+ | kernel-default | package | 5.3.18-lp152.63.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | kernel-default | package | 5.3.18-lp152.63.1 | x86_64 | Main Update Repository
i+ | kernel-default-devel | package | 5.3.18-lp152.66.2 | x86_64 | openSUSE:Leap:15.2:Update
i+ | kernel-default-devel | package | 5.3.18-lp152.66.2 | x86_64 | Main Update Repository
i+ | kernel-default-devel | package | 5.3.18-lp152.63.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | kernel-default-devel | package | 5.3.18-lp152.63.1 | x86_64 | Main Update Repository
i | kernel-devel | package | 5.3.18-lp152.66.2 | noarch | openSUSE:Leap:15.2:Update
i | kernel-devel | package | 5.3.18-lp152.66.2 | noarch | Main Update Repository
i | kernel-devel | package | 5.3.18-lp152.63.1 | noarch | openSUSE:Leap:15.2:Update
i | kernel-devel | package | 5.3.18-lp152.63.1 | noarch | Main Update Repository
i+ | kernel-devel-rt | package | 5.3.18-lp152.3.5.1 | noarch | openSUSE:Leap:15.2:Update
i+ | kernel-devel-rt | package | 5.3.18-lp152.3.5.1 | noarch | Main Update Repository
i+ | kernel-firmware | package | 20200107-lp152.2.6.1 | noarch | openSUSE:Leap:15.2:Update
i+ | kernel-firmware | package | 20200107-lp152.2.6.1 | noarch | Main Update Repository
i+ | kernel-macros | package | 5.3.18-lp152.66.2 | noarch | openSUSE:Leap:15.2:Update
i+ | kernel-macros | package | 5.3.18-lp152.66.2 | noarch | Main Update Repository
i | kernel-preempt | package | 5.3.18-lp152.66.2 | x86_64 | openSUSE:Leap:15.2:Update
i | kernel-preempt | package | 5.3.18-lp152.66.2 | x86_64 | Main Update Repository
i | kernel-preempt-devel | package | 5.3.18-lp152.66.2 | x86_64 | openSUSE:Leap:15.2:Update
i | kernel-preempt-devel | package | 5.3.18-lp152.66.2 | x86_64 | Main Update Repository
i | kernel-preempt-devel | package | 5.3.18-lp152.63.1 | x86_64 | openSUSE:Leap:15.2:Update
i | kernel-preempt-devel | package | 5.3.18-lp152.63.1 | x86_64 | Main Update Repository
i+ | kernel-rt | package | 5.3.18-lp152.3.5.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | kernel-rt | package | 5.3.18-lp152.3.5.1 | x86_64 | Main Update Repository
i+ | kernel-rt | package | 5.3.18-lp152.3.2.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | kernel-rt | package | 5.3.18-lp152.3.2.1 | x86_64 | Main Update Repository
i | kernel-rt-devel | package | 5.3.18-lp152.3.5.1 | x86_64 | openSUSE:Leap:15.2:Update
i | kernel-rt-devel | package | 5.3.18-lp152.3.5.1 | x86_64 | Main Update Repository
i | kernel-source | package | 5.3.18-lp152.66.2 | noarch | openSUSE:Leap:15.2:Update
i | kernel-source | package | 5.3.18-lp152.66.2 | noarch | Main Update Repository
i | kernel-source | package | 5.3.18-lp152.63.1 | noarch | openSUSE:Leap:15.2:Update
i | kernel-source | package | 5.3.18-lp152.63.1 | noarch | Main Update Repository
i+ | kernel-source-rt | package | 5.3.18-lp152.3.5.1 | noarch | openSUSE:Leap:15.2:Update
i+ | kernel-source-rt | package | 5.3.18-lp152.3.5.1 | noarch | Main Update Repository
i | kernel-syms | package | 5.3.18-lp152.66.2 | x86_64 | openSUSE:Leap:15.2:Update
i | kernel-syms | package | 5.3.18-lp152.66.2 | x86_64 | Main Update Repository
i | kernel-syms | package | 5.3.18-lp152.63.1 | x86_64 | openSUSE:Leap:15.2:Update
i | kernel-syms | package | 5.3.18-lp152.63.1 | x86_64 | Main Update Repository
i+ | nfs-kernel-server | package | 2.1.1-lp152.9.6.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | nfs-kernel-server | package | 2.1.1-lp152.9.6.1 | x86_64 | Main Update Repository
i+ | patterns-devel-base-devel_kernel | package | 20170319-lp152.6.3 | x86_64 | Main Repository
i+ | purge-kernels-service | package | 0-lp152.4.1 | noarch | Main Repository
i | python3-virtualbox | package | 6.1.18-lp152.2.14.1 | x86_64 | openSUSE:Leap:15.2:Update
i | python3-virtualbox | package | 6.1.18-lp152.2.14.1 | x86_64 | Main Update Repository
i+ | virtualbox | package | 6.1.18-lp152.2.14.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | virtualbox | package | 6.1.18-lp152.2.14.1 | x86_64 | Main Update Repository
i+ | virtualbox-devel | package | 6.1.18-lp152.2.14.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | virtualbox-devel | package | 6.1.18-lp152.2.14.1 | x86_64 | Main Update Repository
i+ | virtualbox-guest-tools | package | 6.1.18-lp152.2.14.1 | x86_64 | openSUSE:Leap:15.2:Update
i+ | virtualbox-guest-tools | package | 6.1.18-lp152.2.14.1 | x86_64 | Main Update Repository
i+ | virtualbox-host-source | package | 6.1.18-lp152.2.14.1 | noarch | openSUSE:Leap:15.2:Update
i+ | virtualbox-host-source | package | 6.1.18-lp152.2.14.1 | noarch | Main Update Repository
i | virtualbox-kmp-default | package | 6.1.18_k5.3.18_lp152.63-lp152.2.14.1 | x86_64 | openSUSE:Leap:15.2:Update
i | virtualbox-kmp-default | package | 6.1.18_k5.3.18_lp152.63-lp152.2.14.1 | x86_64 | Main Update Repository
i | virtualbox-kmp-preempt | package | 6.1.18_k5.3.18_lp152.63-lp152.2.14.1 | x86_64 | openSUSE:Leap:15.2:Update
i | virtualbox-kmp-preempt | package | 6.1.18_k5.3.18_lp152.63-lp152.2.14.1 | x86_64 | Main Update Repository
i | virtualbox-qt | package | 6.1.18-lp152.2.14.1 | x86_64 | openSUSE:Leap:15.2:Update
i | virtualbox-qt | package | 6.1.18-lp152.2.14.1 | x86_64 | Main Update Repository

Even without the realtime kernel - I could not get any preempt kernel to work with VirtualBox.
This is what works.

I assume there is a non-preempt rt kernel.

llrainey@LLR1:~> uname -a
Linux LLR1 5.3.18-lp152.66-default #1 SMP Tue Mar 2 13:18:19 UTC 2021 (73933a3) x86_64 x86_64 x86_64 GNU/Linux
llrainey@LLR1:~> zypper se -si virtual
Loading repository data...
Reading installed packages...

S  | Name                   | Type    | Version                              | Arch   | Repository
---+------------------------+---------+--------------------------------------+--------+--------------------------
i+ | virtualbox             | package | 6.1.18-lp152.2.14.1                  | x86_64 | openSUSE-Leap-15.2-Update
i  | virtualbox-kmp-default | package | 6.1.18_k5.3.18_lp152.63-lp152.2.14.1 | x86_64 | openSUSE-Leap-15.2-Update
i  | virtualbox-qt          | package | 6.1.18-lp152.2.14.1                  | x86_64 | openSUSE-Leap-15.2-Update
llrainey@LLR1:~> zypper se -si kernel
Loading repository data...
Reading installed packages...

S  | Name                  | Type    | Version              | Arch   | Repository
---+-----------------------+---------+----------------------+--------+--------------------------
i+ | kernel-default        | package | 5.3.18-lp152.66.2    | x86_64 | openSUSE-Leap-15.2-Update
i  | kernel-firmware       | package | 20200107-lp152.2.6.1 | noarch | openSUSE-Leap-15.2-Update
i  | purge-kernels-service | package | 0-lp152.4.1          | noarch | openSUSE-Leap-15.2-Oss
llrainey@LLR1:~> 

The error that’s thrown clearly suggests that the required kernel headers aren’t installed or aren’t matched correctly to the currently running kernel and has nothing to do with whether compiling can be successful with matching kernel headers.
Your package listing of relevant packages are confusing, partly because you have a LEAP update repo and a Main update repo… Ordinarily you should have only one Update repo for the OSS and possibly a non-OSS. Although packages from the two repos appear to have the same package names, there is plenty of possible confusion and duplication.

Recommend…
If you don’t want to run a special kernel on different physical machines, for what you probably want you should probably run within a virtual environment, and attempt to do nested paging which is to run a virtual machine within a virtual machine so that you can limit and if necessary remove kernels you’re not running to simplify what is happening.

As for the ideas of RTOS and pre-emptive scheduling/multitasking and hypervisor virtualization,
Those are interesting and AFAIK little explored environments. There’s practically nothing I found with some simple Internet searches.
Both put extreme pressure(far more than usual) on the operating system’s ability to perform multiple and simultaneous processes and tasks under load.
So, my initial instinct is that both may not be good ideas for the HostOS but are likely perfectly acceptable providing single purpose services in a Guest.
Whether something is a good idea or not probably doesn’t have to do with actually trying to set up the environment and testing, though…
I would expect that if you installed only the selected kernel and its kernel headers in an isolated environment you’d have good chances to compile the necessary kernel modules… There might be something I’m not aware of that could block compiling but AFAIK there shouldn’t be any contention.

TSU

If my previous comment wasn’t clear,
it’s that your system likely is running the 3.2-rt kernel but has the 3.5-rt kernel headers installed (actually according to your package listings, it appears you have kernel headers for both kernels installed).

Possible solutions…
Run “zypper up” to attempt to bring your kernel and kernel headers in alignment.
Specify kernel paths to kernel and kernel headers explicitly.
Remove unnecessary kernels and kernel headers (uninstall).

TSU

Yes, apparently my zypper is confused, but not sure how to correct it. Since 3.5-rt isn’t booting, need to figure out how to remove it and whatever zypper is using to think I need it. The headers for 3.2-rt kernel apparently aren’t found anymore, or since 3.5-rt there, may think I’m doing something wrong by downgrading the headers.

For some reason every time I tried to install the kernel-rt-devel package it was installing a version for 3.5 when I’m running 3.2, so something’s up with how zypper chooses based on version.

Cleaned up my enabled repos as suggested.

Anyway, went direct to the repo url and found the 3.2 version, downloaded it, and installed. Finally a build directory showed up in /lib/modules/5.3.18-lp152.3.2-rt directory. Ran the /sbin/vboxconfig and it built but couldn’t load the modules as it would taint the system.

Modified /etc/modprobe.d/10-unsupported-modules.conf to allow, reran /sbin/vboxconfig and it worked. I could start my virtualbox vm again.

Next, rebooted, but it hung. Rebooted again in recovery mode and see it’s complaining about the tainted modules. Edited the startup line in grub adding “single” to the end, modified the file to not allow it, rebooted, and finally was able to log in again.

For grins, tried to start the virtualbox VM again, and it worked, so am confused (since disallowed again), but glad it did.

Anyway, I think I’m back in business, thanks for the suggestions.

Recommend updating your system, that normally resolves inconsistencies in your system including bringing your devel files back in alignment with the base package (in your case the kernel version). Sometimes it doesn’t work, but it’s your best try.

zypper up

Is also why I suggested unless there is a special reason to run on physical hardware, what you’re describing can often be at least tested initially and often Production can run in a virtualized environment which gives you much stronger control over variables and isolation. A physical machine builds up cruft over time, and can cause problems.

TSU