[Req]: Please set `kvm.enable_virt_at_load=0` in /etc/modprobe.d

[ArrayBolt3]

Component

Host Installer

What problem are you facing?

Due to a performance optimization in Linux 6.12 and higher, KVM now takes exclusive control of the system's virtualization features when the KVM kernel modules are loaded, and does not release them even if all KVM virtual machines are powered down. This means that VirtualBox is effectively broken on all Linux distributions that use a 6.12 or higher kernel. Un-breaking it requires setting kvm.enable_virt_at_load=0 in the kernel via either the command line or a modprobe config, which makes it much more difficult for a user to get VirtualBox working.

How can we fix this?

Any user who installs VirtualBox on their system will fall into one of two categories:

• Either A, they don't care about having KVM virtual machines sometimes load slightly slower, and just want to be able to use VirtualBox provided they have no KVM VMs running. Almost all users probably fall into this group.
• Or B, they do care about having KVM virtual machines start as quickly as possible in all scenarios, and prefer to simply manually unload the kvm_XXX and kvm kernel drivers before using VirtualBox. I'm not sure any users fall into this group, but it's theoretically possible.

To satisfy both groups of users, VirtualBox's Linux packages can ship a file under /etc/modprobe.d that will set options kvm enable_virt_at_load=0, allowing VirtualBox and KVM to coexist the same way they coexisted previously. This will make VirtualBox just work for the first group of users.

To satisfy the second group of users, this configuration file should be marked as a "conffile". Under Debian-based distros, simply installing the file anywhere under /etc is enough for it to be marked as a conffile, while under RPM-based distros the config file should be marked as %config(noreplace) (I believe, though I haven't tested this). This will allow users to modify delete the configuration file, without RPM reverting it the next time VirtualBox is updated. Thus, for the users who want to have VirtualBox broken by default and want to manually fix it as necessary, they can delete the configuration file and be done.

What alternatives or workarounds exist?

• Unload the kvm_XXX and kvm kernel modules before using VirtualBox,
• or set options kvm enable_virt_at_load=0 in /etc/modprobe.d,
• or set kvm.enable_virt_at_load=0 on the kernel command line.

All of these work, but they are a pain to configure, and some users with less technical skill may accidentally break their system while attempting to do one of these things manually.

Anything else we should know?

Debian's VirtualBox package already ships a file at /usr/lib/modprobe.d/virtualbox-dkms.conf which sets options kvm enable_virt_at_load=0. This doesn't really provide much room for the second hypothetical group of users (who want a broken VBox by default), but it works.

[ramshven]

Linux kernel 6.16.0 adds a couple of kernel functions kvm_enable_virtualization and kvm_disable_virtualization which VirtualBox will try to use for acquiring/release VT-x. This will allow VirtualBox to run VMs as before. Of course, running both KVM and VirtualBox VMs at a same time is a no-go, but at least this should let VirtualBox acquire/release VT-x without failing with VERR_VMX_IN_VMX_ROOT_MODE guru meditation. This does not require modifying any files on disk and this would be our preferred way of dealing with this situation for these newer kernels.

This change should be available in the next maintenance release of VirtualBox.

Regarding kernels older than 6.16.0 and that has this problem, the current behavior is VirtualBox failing to start VMs with the VERR_VMX_IN_VMX_ROOT_MODE guru meditaiton. We are considering what other options we can do in the mean time.

[galitsyn-oracle]

Hello,

Thank you for reporting the issue. We just released VirtualBox 7.2.2. This issue should be fixed in this version. Could please give it a try? Packages are available at https://www.virtualbox.org/wiki/Downloads.