El mensaje parece más grave de lo que es: una máquina virtual de VirtualBox no arranca y muestra algo parecido a esto:

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

La frase sugiere que hay que recompilar el kernel, pero normalmente conviene investigar antes de tocarlo. En un host Linux, KVM puede haber cargado sus módulos y habilitado la virtualización por hardware antes de que VirtualBox intente utilizarla. El resultado es una competición por el control de AMD-V.

Este artículo explica cómo distinguir ese escenario, qué cambia entre AMD e Intel y cómo elegir una solución temporal, persistente o alternativa.

La respuesta corta: instalar dos hipervisores no es el problema

VirtualBox y KVM pueden estar instalados en el mismo Linux. Lo delicado es ejecutar máquinas virtuales de productos que intentan controlar a la vez la virtualización por hardware del procesador.

VirtualBox necesita acceder a la extensión que el procesador ofrece para ejecutar código invitado con eficiencia. En un equipo AMD esa extensión se conoce como AMD-V y en el lenguaje de Linux suele aparecer asociada a SVM (Secure Virtual Machine). En un equipo Intel se llama VT-x y la tecnología se describe mediante VMX.

KVM es el hipervisor integrado en el kernel de Linux. Sus módulos habituales son:

  • kvm, el componente común.
  • kvm_amd, el componente específico para procesadores AMD.
  • kvm_intel, el componente específico para procesadores Intel.

QEMU, libvirt y herramientas como virt-manager pueden usar la interfaz de KVM expuesta mediante /dev/kvm. VirtualBox utiliza su propio motor y sus propios módulos, entre ellos vboxdrv, pero necesita el mismo recurso físico del CPU.

Por eso VERR_SVM_IN_USE no significa necesariamente que VirtualBox esté mal instalado. Significa que, desde el punto de vista de VirtualBox, AMD-V ya está en uso. En Intel suele aparecer un mensaje equivalente relacionado con VMX, como VERR_VMX_IN_USE; no hay que convertir el diagnóstico AMD en una regla literal para todos los equipos.

AMD-V no es AMD64, y KVM no es una opción gráfica de VirtualBox

Hay dos confusiones frecuentes que hacen perder tiempo.

AMD64 describe una arquitectura de instrucciones de 64 bits que también se usa en procesadores Intel. AMD-V describe una extensión de virtualización del procesador. Un equipo puede ser x86_64 sin que la extensión esté habilitada en el firmware o sin que el host virtualizado la exponga.

Además, VirtualBox puede ofrecer KVM como proveedor de paravirtualización para que un sistema Linux invitado conozca una interfaz conveniente. Esa opción no convierte a VirtualBox en el hipervisor KVM ni explica por sí sola VERR_SVM_IN_USE. El conflicto de este artículo está en el host Linux y en quién controla la extensión de virtualización del CPU.

Por qué el kernel importa

Durante años, comprobar que kvm_amd o kvm_intel estaba cargado no bastaba para explicar exactamente cuándo se ocupaba la virtualización. El comportamiento del kernel cambió en la serie 6.12 y motivó reportes de VirtualBox: KVM puede habilitar la virtualización al cargar el módulo, incluso antes de crear la primera máquina virtual.

El parámetro del kernel que controla ese comportamiento es kvm.enable_virt_at_load. La documentación del kernel distingue dos modos:

  • activado: KVM habilita la virtualización cuando se carga y la deshabilita al descargar el módulo, si es un módulo cargable;
  • desactivado: KVM la habilita y deshabilita bajo demanda, al pasar de cero a una VM y de una VM a cero.

Desactivar este comportamiento no desinstala KVM ni permite ejecutar dos VMs de hipervisores competidores sin coordinación. Solo cambia el momento en el que KVM adquiere el recurso. Si VirtualBox arranca primero, KVM tendrá que esperar; si una VM KVM arranca primero, VirtualBox seguirá sin poder tomar el control.

La versión de VirtualBox también importa. El changelog de la rama 7.2 indica que VirtualBox usa APIs de KVM en kernels 6.16.0 y posteriores para adquirir y liberar VT-x. Es una mejora especialmente relevante para hosts Intel, no una garantía equivalente para AMD-V ni una promesa de que cualquier distribución, kernel o paquete resuelva el problema. La combinación exacta debe comprobarse antes de convertir una solución temporal en configuración permanente.

Diagnóstico antes de descargar módulos

La primera intervención debe ser observar el host. No desactives SVM/AMD-V o VT-x en el firmware y no fuerces la descarga de módulos mientras haya VMs activas.

1. Identifica el kernel, VirtualBox y la extensión del CPU

Ejecuta estas comprobaciones en el host, no dentro de la VM:

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

lscpu suele mostrar AMD-V en AMD o VT-x en Intel. Las banderas svm y vmx son otra pista de lo que expone el CPU al kernel. Si ninguna aparece, puede que la virtualización esté desactivada en UEFI/BIOS, que el equipo sea a su vez una VM sin virtualización anidada o que la arquitectura no sea la esperada. Ese caso no se arregla descargando KVM.

Anota también la distribución y el paquete exacto de VirtualBox. Un error observado con VirtualBox 7.1 y kernel 6.14 no demuestra que ocurra igual con VirtualBox 7.2 y kernel 6.16, ni al revés.

2. Comprueba los módulos de KVM y /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

En un AMD es normal ver kvm_amd y kvm; en un Intel, kvm_intel y kvm. La presencia de /dev/kvm indica que el dispositivo de la interfaz está disponible, pero no demuestra por sí sola que haya una VM ejecutándose.

El archivo de sysfs puede mostrar Y, N, 1 o 0 según el kernel y la forma en que exponga el parámetro. No lo interpretes como una prueba aislada: combínalo con el kernel, los módulos y los registros.

3. Busca procesos que estén usando KVM

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

Si aparece QEMU u otro proceso con un descriptor abierto en /dev/kvm, hay una VM KVM en uso o una herramienta que mantiene el dispositivo abierto. Detén esa carga mediante su procedimiento normal antes de intentar liberar los módulos.

Que fuser no muestre ningún proceso no descarta el conflicto: en los kernels afectados, KVM puede haber habilitado la virtualización al cargar el módulo, aunque todavía no haya una VM con /dev/kvm abierto.

4. Revisa los mensajes del kernel y el registro de VirtualBox

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

La salida depende de la distribución y de los permisos del registro. Busca cuándo se cargó KVM, qué módulo específico se inicializó y si VirtualBox registra AMD-V, SVM, VT-x o VMX cerca del fallo. No publiques el registro completo sin revisar rutas, nombres de usuario, UUID y otros datos del host.

Una lectura razonable del diagnóstico sería la siguiente:

Observación Qué sugiere Siguiente paso
kvm_amd/kvm_intel cargado y una VM QEMU activa KVM está usando el recurso ahora Detener la VM de forma ordenada y probar de nuevo
Módulos cargados, sin proceso en /dev/kvm, kernel 6.12+ KVM puede haber tomado la virtualización al cargarse Probar la descarga normal o kvm.enable_virt_at_load=0
No hay módulos KVM, pero el error persiste Puede haber otro hipervisor, una VM anidada o un problema de versión Revisar procesos, firmware, logs y compatibilidad
Error VERR_VMX_IN_USE con kvm_intel Es el equivalente aproximado en Intel Repetir el análisis con VT-x/VMX, sin usar comandos AMD

La tabla orienta; no sustituye la reproducción en el host concreto.

Soluciones según el escenario

Solución temporal: descargar KVM antes de iniciar VirtualBox

Esta es una prueba reversible para un host AMD sin VMs KVM activas:

sudo modprobe -r kvm_amd
sudo modprobe -r kvm

En Intel, cambia el módulo específico:

sudo modprobe -r kvm_intel
sudo modprobe -r kvm

Si un comando responde que el módulo está en uso, no lo fuerces. Localiza la VM o el servicio que lo mantiene ocupado y detenlo con su procedimiento normal. La descarga puede afectar a QEMU, libvirt y otras herramientas de virtualización; no es un ajuste inocuo para un servidor que aloja VMs.

Cuando quieras volver a usar KVM, puedes cargar los módulos de nuevo:

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

El nombre del módulo específico debe corresponder al fabricante del CPU. Si el módulo está integrado en el kernel o una distribución gestiona su carga de otra manera, modprobe -r puede no ser aplicable.

Si VirtualBox arranca después de descargar KVM, la prueba apoya la hipótesis de una disputa por la virtualización, pero no demuestra que todas las versiones del kernel presenten el mismo defecto.

Solución persistente: retrasar la adquisición de virtualización de KVM

El kernel documenta el parámetro:

kvm.enable_virt_at_load=0

Para probarlo sin convertirlo todavía en una decisión permanente, algunas entradas de GRUB permiten editar temporalmente la línea que empieza por linux durante el arranque. Añade el parámetro, inicia esa entrada y comprueba después:

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

Si el resultado es adecuado, la persistencia depende de la distribución. En Debian y Ubuntu se suele editar /etc/default/grub, añadir el parámetro dentro de GRUB_CMDLINE_LINUX_DEFAULT y regenerar la configuración:

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

En Fedora, RHEL y derivados que disponen de grubby, la forma habitual es distinta:

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

No mezcles instrucciones de gestores de arranque de distribuciones distintas. Guarda una entrada de recuperación y consulta la documentación de tu sistema antes de modificar el arranque.

Para revertir el ejemplo de grubby:

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

En GRUB, elimina solo el parámetro de /etc/default/grub, vuelve a ejecutar sudo update-grub y reinicia.

Esta configuración no desinstala KVM. KVM seguirá pudiendo habilitar la virtualización cuando se cree la primera VM, por lo que no se deben ejecutar a la vez una VM KVM y una VM VirtualBox esperando que el parámetro coordine ambos hipervisores. El propio kernel documenta que retrasar la activación puede evitar interferencias con hipervisores externos, a cambio de posible latencia al crear la primera VM KVM.

Algunas distribuciones aplican el mismo ajuste mediante un archivo de /etc/modprobe.d/, por ejemplo con una línea options kvm enable_virt_at_load=0. No añadas una segunda configuración sin revisar la que ya exista ni asumas que funcionará si KVM está integrado en el kernel o se carga desde un initramfs.

Actualizar VirtualBox o elegir un kernel compatible

Antes de mantener un workaround, compara:

VBoxManage --version
uname -r

La rama 7.2 documenta el uso de APIs KVM en kernels 6.16.0 y posteriores para adquirir y liberar VT-x. La versión 7.2.22 figura en la página de descargas consultada para esta propuesta, pero esa entrada —orientada a VT-x— no convierte automáticamente todas las combinaciones Intel o AMD en compatibles.

La elección razonable suele ser:

  • actualizar VirtualBox si el fallo apareció tras una actualización del kernel y la versión instalada es anterior a la corrección relevante;
  • instalar las actualizaciones de seguridad del kernel y comprobar si la distribución ofrece un paquete de VirtualBox compatible;
  • arrancar temporalmente un kernel conocido, mantenido y compatible mientras se valida la actualización de VirtualBox, sin convertir un kernel antiguo en la solución permanente.

No conviene recomendar un número de kernel o de VirtualBox sin indicar la distribución, los parches del paquete y el fabricante del CPU.

Alternativa: usar KVM como hipervisor principal

Si el host es Linux y la mayoría de las VMs ya encajan en QEMU/libvirt, cambiar de VirtualBox a KVM puede eliminar la competición en vez de posponerla. Es una decisión de arquitectura, no un comando de reparación.

El cambio puede implicar:

  • importar o convertir discos y revisar si el formato es compatible;
  • recrear la red, el firmware virtual y el número de CPU/memoria;
  • sustituir snapshots y procedimientos de gestión de VirtualBox;
  • dejar de usar Guest Additions y configurar las herramientas del nuevo hipervisor.

Haz una copia de seguridad del disco virtual y prueba con una copia. No borres la VM original hasta verificar el arranque, la red y los datos dentro del invitado.

Ajuste avanzado: hwvirtexclusive off

VirtualBox documenta una propiedad global que cambia el uso exclusivo de VT-x/AMD-V:

VBoxManage getproperty hwvirtexclusive
VBoxManage setproperty hwvirtexclusive off

El valor se guarda en la configuración global de VirtualBox y la opción off puede tener consecuencias de rendimiento. Para restaurar el comportamiento predeterminado:

VBoxManage setproperty hwvirtexclusive on

No es la primera solución para VERR_SVM_IN_USE. El manual la describe como una opción para compartir la extensión con otros hipervisores, pero también advierte que no se deben ejecutar VMs de hipervisores competidores al mismo tiempo porque pueden producir inestabilidad o incluso bloquear el host. Úsala solo en una VM de laboratorio, con versiones conocidas y una ruta clara de reversión.

Qué no hacer

  • No desactives SVM/AMD-V o VT-x en UEFI/BIOS como primera respuesta. Eso quita la aceleración por hardware a VirtualBox y KVM y puede impedir VMs de 64 bits o con varios procesadores.
  • No uses rmmod -f para liberar KVM. Forzar un módulo que todavía usa una VM puede dejar el host inestable.
  • No confundas vboxdrv con kvm_amd o kvm_intel. El primero pertenece a VirtualBox; los segundos son partes de KVM.
  • No concluyas que el problema es del guest solo porque cualquier sistema invitado falla. Si el error ocurre antes de que arranque el guest, la pista está en el host.
  • No presentes un reporte de GitHub como una garantía. Los issues ayudan a identificar regresiones y combinaciones afectadas, pero el kernel de la distribución puede llevar otra configuración.

Cómo comprobar que la solución funcionó

Después de aplicar una solución, prueba una VM que no tenga datos críticos:

VBoxManage startvm "NOMBRE_DE_LA_VM" --type gui

Considera resuelto el problema solo si:

  1. VirtualBox supera la fase en la que aparecía VERR_SVM_IN_USE.
  2. El invitado arranca y permanece estable durante una prueba breve.
  3. El registro de VirtualBox ya no muestra el mismo fallo de adquisición de AMD-V/VT-x.
  4. Si necesitas KVM después, puedes restaurar sus módulos y crear una VM de prueba sin dejar servicios rotos.

Que kvm aparezca cargado después no significa automáticamente que la prueba haya fallado: el módulo puede estar disponible sin tener una VM activa, y con enable_virt_at_load=0 la adquisición se produce bajo demanda. Lo importante es relacionar el estado de los módulos con el momento en que cada hipervisor arranca.

Si el error persiste

Recopila únicamente la información necesaria y anota qué solución se probó:

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'

Añade la distribución, el modelo del CPU, si el host es físico o una VM, la versión exacta de VirtualBox y el error literal. Con esos datos se puede consultar el changelog o un issue específico sin convertir un caso de AMD en una explicación universal.

Fuentes y lecturas