The message looks more serious than it usually is: a VirtualBox virtual machine refuses to start and displays something like this:

VirtualBox can't enable the AMD-V extension.
Please disable the KVM kernel extension, recompile your kernel and reboot
(VERR_SVM_IN_USE).

The wording suggests that the kernel must be rebuilt, but it is better to investigate before changing it. On a Linux host, KVM may have loaded its modules and enabled hardware virtualization before VirtualBox tries to use it. The result is a contest for control of AMD-V.

This article explains how to distinguish that scenario, what changes between AMD and Intel, and how to choose a temporary, persistent, or alternative fix. The commands are examples; their output should be treated as illustrative until they are validated on a specific distribution and version combination.

The short answer: installing two hypervisors is not the problem

VirtualBox and KVM can be installed on the same Linux system. The delicate part is running virtual machines from products that try to control the host processor’s hardware virtualization at the same time.

VirtualBox needs access to the processor extension that makes guest execution efficient. On AMD systems this extension is known as AMD-V and is commonly associated with SVM (Secure Virtual Machine) in Linux terminology. On Intel systems it is called VT-x, and the technology is described through VMX.

KVM is the hypervisor integrated into the Linux kernel. Its usual modules are:

  • kvm, the common component.
  • kvm_amd, the AMD-specific component.
  • kvm_intel, the Intel-specific component.

QEMU, libvirt, and tools such as virt-manager can use KVM through the interface exposed as /dev/kvm. VirtualBox uses its own engine and modules, including vboxdrv, but it still needs the same physical CPU resource.

That is why VERR_SVM_IN_USE does not necessarily mean that VirtualBox is installed incorrectly. From VirtualBox’s point of view, AMD-V is already in use. On Intel, an equivalent VMX-related message such as VERR_VMX_IN_USE may appear; the AMD diagnosis should not be copied literally to every machine.

AMD-V is not AMD64, and KVM is not a VirtualBox GUI setting

Two common misunderstandings can send the investigation in the wrong direction.

AMD64 describes a 64-bit instruction-set architecture that is also used by Intel processors. AMD-V describes a processor virtualization extension. A machine can be x86_64 while the extension is disabled in firmware or not exposed by an outer virtual machine.

VirtualBox can also offer KVM as a paravirtualization provider so that a Linux guest can use a convenient interface. That setting does not turn VirtualBox into the KVM hypervisor and does not, by itself, explain VERR_SVM_IN_USE. This article is about the Linux host and which component controls the CPU virtualization extension.

Why the kernel version matters

For years, seeing kvm_amd or kvm_intel loaded was not enough to tell exactly when hardware virtualization had been claimed. Kernel behavior changed in the 6.12 series and led to VirtualBox reports: KVM can enable virtualization when its module is loaded, even before the first virtual machine is created.

The kernel parameter controlling that behavior is kvm.enable_virt_at_load. The kernel documentation describes two modes:

  • enabled: KVM enables hardware virtualization when it loads and disables it when it unloads, if it was built as a loadable module;
  • disabled: KVM enables and disables virtualization on demand, as the number of VMs changes from zero to one and from one to zero.

Disabling this behavior does not uninstall KVM or make it safe to run two competing hypervisors without coordination. It only changes when KVM acquires the resource. If VirtualBox starts first, KVM must wait; if a KVM VM starts first, VirtualBox still cannot take control.

The VirtualBox version also matters. The 7.2 changelog says that VirtualBox uses KVM APIs on Linux kernels 6.16.0 and newer to acquire and release VT-x. This is especially relevant to Intel hosts, not an equivalent guarantee for AMD-V and not a promise that every distribution, kernel, or package combination is resolved. Check the exact combination before turning a temporary workaround into a permanent setting.

Diagnose before unloading anything

The first intervention should be observation. Do not disable SVM/AMD-V or VT-x in firmware, and do not force module removal while VMs are active.

1. Identify the kernel, VirtualBox, and CPU extension

Run these checks on the host, not inside the guest:

uname -r
VBoxManage --version
LC_ALL=C lscpu | grep -E 'Architecture|Virtualization'
grep -m1 -oE 'svm|vmx' /proc/cpuinfo || true

lscpu usually shows AMD-V on AMD or VT-x on Intel. The svm and vmx flags are another indication of what the kernel can see. If neither appears, virtualization may be disabled in UEFI/BIOS, the machine may itself be a VM without nested virtualization, or the architecture may not be what you expected. Unloading KVM will not fix that case.

Also record the distribution and the exact VirtualBox package version. A failure reported with VirtualBox 7.1 and kernel 6.14 does not prove that the same thing happens with VirtualBox 7.2 and kernel 6.16, or the other way around.

2. Check KVM modules and /dev/kvm

lsmod | grep -E '^(kvm(_amd|_intel)?)[[:space:]]' || true
ls -l /dev/kvm 2>/dev/null || true
cat /sys/module/kvm/parameters/enable_virt_at_load 2>/dev/null || true

On AMD, it is normal to see kvm_amd and kvm; on Intel, kvm_intel and kvm. The presence of /dev/kvm means that the interface device is available, but does not by itself prove that a VM is running.

The sysfs file may show Y, N, 1, or 0 depending on the kernel and how it exposes the parameter. Do not treat it as an isolated proof; combine it with the kernel version, modules, and logs.

3. Look for processes using KVM

sudo fuser -v /dev/kvm
ps -ef | grep -E '[q]emu|[l]ibvirt|[v]irt-manager'

If QEMU or another process has an open descriptor for /dev/kvm, a KVM VM or management tool is currently using the device. Stop that workload through its normal procedure before trying to release the modules.

If fuser shows no process, the conflict is not ruled out: on affected kernels, KVM may have enabled virtualization when its module loaded even though no VM has an open /dev/kvm descriptor yet.

4. Review kernel messages and the VirtualBox log

sudo journalctl -k -b --no-pager | grep -iE 'kvm|vbox|svm|vmx'

The output depends on the distribution and log permissions. Look for when KVM loaded, which vendor module initialized, and whether VirtualBox records AMD-V, SVM, VT-x, or VMX near the failure. Do not publish the complete log without removing paths, usernames, UUIDs, and other host details.

A reasonable interpretation of the diagnosis would be:

Observation What it suggests Next step
kvm_amd/kvm_intel is loaded and a QEMU VM is active KVM is using the resource now Stop the VM cleanly and try again
Modules are loaded, no process uses /dev/kvm, kernel 6.12+ KVM may have claimed virtualization when it loaded Try normal module removal or kvm.enable_virt_at_load=0
No KVM modules, but the error remains Another hypervisor, nested virtualization, or a version issue may be involved Review processes, firmware, logs, and compatibility
VERR_VMX_IN_USE with kvm_intel Approximate Intel equivalent Repeat the analysis with VT-x/VMX, not AMD commands

The table is a guide, not a replacement for reproducing the behavior on the actual host.

Choose a solution for the scenario

Temporary fix: unload KVM before starting VirtualBox

This is a reversible test for an AMD host with no active KVM VMs:

sudo modprobe -r kvm_amd
sudo modprobe -r kvm

On Intel, replace the vendor-specific module:

sudo modprobe -r kvm_intel
sudo modprobe -r kvm

If a command reports that the module is in use, do not force it. Find the VM or service holding it and stop it through the normal procedure. Unloading modules may affect QEMU, libvirt, and other virtualization tools; it is not a harmless change on a server hosting VMs.

When you want to use KVM again, you can load the modules:

sudo modprobe kvm
sudo modprobe kvm_amd       # AMD
# sudo modprobe kvm_intel   # Intel

The vendor-specific module must match the CPU manufacturer. If the module is built into the kernel or the distribution manages loading differently, modprobe -r may not apply.

If VirtualBox starts after KVM is unloaded, the test supports the hypothesis of a virtualization ownership conflict, but it does not prove that every kernel version has the same defect.

Persistent fix: delay KVM’s virtualization acquisition

The kernel documents this parameter:

kvm.enable_virt_at_load=0

To test it without making a permanent decision, some GRUB entries let you edit the line beginning with linux during boot. Add the parameter, boot that entry, and then check:

cat /proc/cmdline
cat /sys/module/kvm/parameters/enable_virt_at_load 2>/dev/null || true

If the result is appropriate, persistence depends on the distribution. On Debian and Ubuntu, the usual approach is to edit /etc/default/grub, add the parameter inside GRUB_CMDLINE_LINUX_DEFAULT, and regenerate the configuration:

sudoedit /etc/default/grub
sudo update-grub
sudo reboot

On Fedora, RHEL, and derivatives that provide grubby, the usual command is different:

sudo grubby --update-kernel=ALL --args="kvm.enable_virt_at_load=0"
sudo reboot

Do not mix bootloader instructions from different distributions. Keep a recovery entry and consult your system documentation before changing the boot configuration.

To revert the grubby example:

sudo grubby --update-kernel=ALL --remove-args="kvm.enable_virt_at_load=0"

With GRUB, remove only the parameter from /etc/default/grub, run sudo update-grub again, and reboot.

This setting does not uninstall KVM. KVM can still enable virtualization when the first VM is created, so do not run a KVM VM and a VirtualBox VM at the same time expecting the parameter to coordinate both hypervisors. The kernel documentation says that delaying activation can avoid interference with out-of-tree hypervisors, at the cost of possible latency when the first KVM VM is created.

Some distributions apply the same setting through an /etc/modprobe.d/ file, for example with options kvm enable_virt_at_load=0. Do not add a second configuration without reviewing what is already present, and do not assume it will work if KVM is built into the kernel or loaded from an initramfs.

Update VirtualBox or choose a compatible kernel

Before keeping a workaround, compare:

VBoxManage --version
uname -r

The 7.2 branch documents the use of KVM APIs on Linux kernels 6.16.0 and newer to acquire and release VT-x. Version 7.2.22 was listed on the download page consulted for this proposal, but that VT-x-oriented entry does not automatically make every Intel or AMD combination compatible.

A reasonable choice is usually to:

  • update VirtualBox if the failure appeared after a kernel update and the installed version predates the relevant fix;
  • install security updates for the kernel and check whether the distribution provides a compatible VirtualBox package;
  • temporarily boot a known, maintained, compatible kernel while validating the VirtualBox update, rather than making an old kernel the permanent solution.

Do not recommend a kernel or VirtualBox version without stating the distribution, package patches, and CPU vendor.

Alternative: use KVM as the main hypervisor

If the host is Linux and most VMs already fit QEMU/libvirt, switching from VirtualBox to KVM can remove the competition instead of postponing it. This is an architecture decision, not a one-command repair.

The change may involve:

  • importing or converting virtual disks and checking format compatibility;
  • recreating the virtual network, firmware, and CPU/memory settings;
  • replacing VirtualBox snapshots and management procedures;
  • no longer using Guest Additions and configuring the new hypervisor’s tools.

Back up the virtual disk and test with a copy. Do not delete the original VM until boot, networking, and guest data have been verified.

Advanced setting: hwvirtexclusive off

VirtualBox documents a global property that changes exclusive use of VT-x/AMD-V:

VBoxManage getproperty hwvirtexclusive
VBoxManage setproperty hwvirtexclusive off

The value is stored in VirtualBox’s global configuration, and off can have performance implications. To restore the default behavior:

VBoxManage setproperty hwvirtexclusive on

This is not the first fix for VERR_SVM_IN_USE. The manual describes it as an option for sharing the extension with other hypervisors, but it also warns not to run VMs from competing hypervisors at the same time because the result can be instability or even a host crash. Use it only with a test VM, known versions, and a clear rollback path.

What not to do

  • Do not disable SVM/AMD-V or VT-x in UEFI/BIOS as the first response. That removes hardware acceleration from VirtualBox and KVM and may prevent 64-bit or multiprocessor VMs.
  • Do not use rmmod -f to release KVM. Forcing a module still used by a VM can make the host unstable.
  • Do not confuse vboxdrv with kvm_amd or kvm_intel. The first belongs to VirtualBox; the other modules are parts of KVM.
  • Do not assume the guest is the cause just because every guest fails. If the error occurs before the guest starts, the clue is on the host.
  • Do not treat a GitHub report as a guarantee. Issues help identify regressions and affected combinations, but a distribution’s kernel may use a different configuration.

How to verify the fix

After applying a solution, test a VM without critical data:

VBoxManage startvm "VM_NAME" --type gui

Consider the problem resolved only if:

  1. VirtualBox gets past the phase where VERR_SVM_IN_USE appeared.
  2. The guest boots and remains stable during a short test.
  3. The VirtualBox log no longer shows the same AMD-V/VT-x acquisition failure.
  4. If KVM is needed afterwards, its modules can be restored and a test VM can start without leaving services broken.

Seeing kvm loaded afterwards does not automatically mean the test failed: the module can be available without an active VM, and with enable_virt_at_load=0 acquisition happens on demand. The important point is to relate module state to the moment when each hypervisor starts.

If the error remains

Collect only the necessary information and record which fix was tested:

uname -r
VBoxManage --version
LC_ALL=C lscpu | grep -E 'Architecture|Virtualization'
lsmod | grep -E '^(kvm(_amd|_intel)?)[[:space:]]' || true
cat /proc/cmdline
sudo journalctl -k -b --no-pager | grep -iE 'kvm|vbox|svm|vmx'

Add the distribution, CPU model, whether the host is physical or itself a VM, the exact VirtualBox version, and the literal error. With that information you can consult a changelog or a specific issue without turning an AMD case into a universal explanation.

Sources and further reading