[Bug]: Running VMs all hit Guru Meditation -4004 (VERR_VMX_INVALID_VMXON_PTR) when a KVM guest starts on the Linux host #948

Version

7.2.6 (Ubuntu package: 7.2.6_Ubuntu r172322)

Host OS Type

Linux

Host OS name + version

Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic

Host Architecture

x86 (Intel Core i5-13400, 13th gen, 10 cores / 16 threads, VT-x with EPT/VPID)

Guest OS Type

Windows (also seen with other guests)

Guest Architecture

x86

Guest OS name + version

Windows Server 2019 (Windows2019_64) and others. Three guests were running and all three crashed at once.

Component

VMM / HM (VT-x)

What happened?

Three VirtualBox VMs were running headless. A different program then started a QEMU/KVM guest (qemu-system-x86_64 ... -accel kvm). In the same second, all three VirtualBox VMs went into Guru Meditation:

05:13:35.205505 HM: HCPhysVmxEnableError         = 0x0000000c768fd000
05:13:35.206226 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'
05:13:35.206249 Console: Machine state changed to 'Stuck'
05:13:35.206675 !!         VCPU0: Guru Meditation -4004 (VERR_VMX_INVALID_VMXON_PTR)
05:13:35.259159 emR3Debug: rc=VERR_VMX_INVALID_VMXON_PTR

The crashed VMs could not be resumed and had to be powered off.

While the KVM guest was still running, starting a VirtualBox VM failed cleanly:

HM: VMX setup failed with rc=VERR_VMX_VMXON_FAILED!
VMSetError: .../src/VBox/VMM/VMMR3/target-x86/HMR3-x86.cpp(1833) int hmR3InitFinalizeR0Intel(PVM); rc=VERR_VMX_VMXON_FAILED

That clean failure is fine. The bug is that VMs that are already running get killed instead of either keeping VT-x or failing gracefully.

Relevant host details:

• kvm is loaded with enable_virt_at_load=N. KVM only turns on VMX when its first guest starts and turns it off again when its last guest exits. VirtualBox therefore loads and starts fine with kvm_intel present, then breaks later when a KVM guest appears.
• vboxdrv cannot use KVM's VT-x enable/disable on this kernel, so VirtualBox uses its own VMXON:

  vboxdrv: Found extra KVM hardware-virtualization symbols
  vboxdrv: Failed to find KVM hardware-virtualization symbols
  

  VBox.log: HM: VT-x/AMD-V init method: Local, HM: VT-x/AMD-V enable method: VirtualBox
• The same kernel log also shows kvm_amd: CPU N isn't AMD or Hygon on this Intel host, which may be related to [Bug]: vboxdrv triggers kvm_amd probe on Intel systems #629.
• Nested hardware virtualization is off for the guests (NestedHWVirt = 0).

How can we reproduce this?

1. Linux host with kernel 7.0 (likely 6.12 or later), with kvm and kvm_intel loaded and kvm.enable_virt_at_load=0. Confirm with cat /sys/module/kvm/parameters/enable_virt_at_load, which should print N.
2. Start one or more VirtualBox VMs. They start normally.
3. Start any KVM guest, e.g. qemu-system-x86_64 -accel kvm -m 512 -nographic.
4. Every running VirtualBox VM immediately hits Guru Meditation -4004 (VERR_VMX_INVALID_VMXON_PTR).

Expected behaviour

Ideally VirtualBox and KVM share VT-x through the kernel's virtualization enable API, the same way they work together when vboxdrv finds KVM's symbols. Failing that, running VMs should not be destroyed. One of these would be acceptable:

• VirtualBox keeps VT-x and the KVM guest fails to start.
• VirtualBox detects the lost VMXON region and gives a clear error saying another hypervisor (KVM) took VT-x, instead of an unexplained Guru Meditation.

Workaround

Blacklist kvm_intel (blacklist kvm_intel + install kvm_intel /bin/false in /etc/modprobe.d), or make sure no KVM guests run on the host.

Related

• Old Trac ticket #18977: all VMs go to Guru Meditation when a KVM (virt-manager) VM is powered on.
• [Bug]: VirtualBox 7.2.0 gives guru meditation immediately after launching freshly imported OVA #139: in 7.2.2 the error was made clearer when KVM is in use at VM start, but running VMs are still killed.
• [Bug]: vboxdrv triggers kvm_amd probe on Intel systems #629: vboxdrv triggers kvm_amd probe on Intel systems.
• Consider integrating support for native OS hypervisors (e.g. KVM on Linux) #2: request to run VirtualBox on top of KVM.

Did you upload all of your necessary log files, screenshots, etc.?

Attaching VBox.log from one crashed VM (the other two show the same error at the same timestamp), plus the vboxdrv/kvm kernel log lines.