¿Puede su VPS ejecutar microVM de Firecracker?

¿Puede su VPS ejecutar microVM de Firecracker?

Su VPS puede ejecutar microVM de Firecracker sólo si le proporciona /dev/kvm. Firecracker es un VMM (monitor de máquinas virtuales) basado en KVM (máquina virtual basada en el kernel), la capa de virtualización integrada en Linux. KVM necesita las instrucciones de virtualización de la CPU. En un VPS, sólo dispone de esas instrucciones cuando el proveedor las expone a su sistema invitado, y la mayoría de los planes no lo hacen.

Por tanto, la primera pregunta no es qué herramienta de microVM debe instalar. Es si la máquina por la que ya paga puede alojar una microVM. Es una cuestión del servicio de hosting y puede responderla en aproximadamente un minuto.

Compruebe /dev/kvm antes de instalar nada

Ejecute estos tres comandos directamente en el VPS.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

Un sistema que puede alojar microVM responde así:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

La primera línea muestra el nodo de dispositivo KVM, cuyo propietario es el grupo kvm. La segunda línea indica que esta máquina es, a su vez, un guest que se ejecuta bajo KVM. Esto es normal y esperado en un VPS. La tercera línea cuenta los núcleos de CPU que indican la marca de virtualización de hardware: vmx en Intel y svm en AMD. Un valor superior a cero dentro de un guest significa que el hipervisor le expone virtualización anidada.

A continuación, compruebe que su usuario puede abrir el dispositivo. Esta es la prueba del documento de inicio de Firecracker:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

FAIL mientras el nodo existe indica un problema de permisos, no de hardware. Conceda acceso a su propio usuario mediante sudo setfacl -m u:${USER}:rw /dev/kvm, o agréguese al grupo con sudo usermod -aG kvm ${USER} y vuelva a iniciar sesión.

Ubuntu también incluye una comprobación que resume todo esto en dos líneas de salida:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

Un host operativo muestra INFO: /dev/kvm exists y después KVM acceleration can be used. Un host que no puede hacerlo muestra INFO: Your CPU does not support KVM extensions y después KVM acceleration can NOT be used. En una máquina física puede aparecer INFO: KVM (vmx) is disabled by your BIOS, que se puede corregir en el firmware. En un VPS, ese mensaje es poco frecuente porque no está accediendo a un firmware real.

¿Qué significa cada respuesta sobre /dev/kvm?

El nodo existe y el número de flags es mayor que cero. Tiene virtualización de hardware, por lo que Firecracker funcionará. Pase a la sección de dimensionamiento, porque la restricción restante es la memoria, no las funciones de la CPU.

No hay nodo, systemd-detect-virt muestra kvm o qemu y el número de flags es 0. Su VPS es una máquina virtual cuyo host no expone la virtualización al invitado. Nada de lo que instale dentro del invitado puede cambiar esto, porque el flag es una propiedad de la CPU virtual que el hipervisor creó para usted. sudo modprobe kvm_intel falla con modprobe: ERROR: could not insert 'kvm_intel': Operation not supported y sudo dmesg | grep -i kvm registra la falta de compatibilidad de hardware. Este es el caso habitual en los planes VPS compartidos. Pregunte al proveedor si el plan admite virtualización anidada. Si la respuesta es no, necesita otro tipo de hosting, no otro comando.

systemd-detect-virt muestra lxc, lxc-libvirt o openvz. Su plan utiliza virtualización basada en contenedores, por lo que comparte el kernel del host. /dev/kvm nunca aparecerá, porque no tiene un kernel propio en el que cargar un módulo. Ningún paquete puede solucionar esto.

Los flags están disponibles, pero el nodo no existe. El módulo simplemente no está cargado. Ejecute sudo modprobe kvm_intel (o kvm_amd en AMD) y vuelva a comprobar ls -l /dev/kvm. Si aparece el nodo, escriba el nombre del módulo en /etc/modules-load.d/kvm.conf para que vuelva a cargarse después de un reinicio.

Utiliza arm64. vmx y svm son nombres de x86, por lo que el recuento de grep es 0 en cualquier máquina arm64, funcione o no. En arm64, confíe en el nodo de dispositivo y en la prueba de lectura y escritura.

Por qué usar una microVM en lugar de un contenedor para el trabajo de un agente

Un contenedor es un proceso que se ejecuta en tu kernel y está aislado mediante namespaces y cgroups. Sólo hay un kernel y es el del host, por lo que un escape a nivel del kernel llega al host. Una microVM arranca su propio kernel dentro de un límite de virtualización de hardware y se comunica con un modelo pequeño de dispositivos emulados, en lugar de usar toda la superficie de llamadas al sistema del host. Firecracker mantiene ese modelo deliberadamente pequeño. Ese es el objetivo del diseño: menos dispositivos emulados significan menos vías de escape.

Esta diferencia es importante para un agente de programación, porque nadie ha revisado previamente el código que ejecuta el agente. Instala paquetes, ejecuta scripts de compilación y reintenta las operaciones a la velocidad de la máquina cuando algo falla. Un kernel separado significa que un paso incorrecto daña una máquina que puedes eliminar, y nada más.

El requisito se deduce directamente del mecanismo. El aislamiento mediante hardware necesita virtualización de hardware, y es posible que tu plan de VPS no la proporcione. Un contenedor no necesita nada de eso. Por eso los contenedores funcionan en todos los planes que se han comercializado.

Por tanto, cuando falta /dev/kvm, el VM desechable para agentes de programación basada en contenedores sigue siendo la opción adecuada, y constituye un control real, no un sustituto de menor calidad. Un contenedor desechable, en un host que no almacena credenciales importantes, restaurado desde una snapshot cada vez que se comporta de forma incorrecta, evita la mayoría de los problemas que ocurren realmente. Lo mismo se aplica a la configuración más sencilla descrita en ejecutar un agente de programación en un VPS. Usa una microVM cuando un agente vaya a ejecutarse sin supervisión durante horas, contra código que todavía no has revisado, y cuando puedas disponer del host para ese fin.

Qué necesita un host agente de microVM

Nehemiah es un ejemplo actual de esta clase: un daemon con licencia Apache-2.0 que proporciona a una IA una máquina Linux real bajo demanda, con una microVM de Firecracker por máquina. Su README indica el requisito sin ambigüedades: «un equipo Linux con /dev/kvm» y, más concretamente, «Ubuntu 24.04, x86_64 o arm64, con /dev/kvm (bare-metal o una VM con virtualización anidada) a la que pueda acceder mediante SSH como root».

La configuración documentada consiste en ejecutar un comando dirigido a ese equipo:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

infra/setup.sh ejecuta una comprobación previa mediante SSH y se detiene de inmediato si el equipo no cumple los requisitos. Sus dos rechazos de hardware son:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

La primera cadena es el punto central de este artículo. El instalador formula la misma pregunta que acaba de hacer con ls -l /dev/kvm y, en la mayoría de los planes VPS, obtiene la misma respuesta decepcionante.

Después de la comprobación previa, se instala el sistema completo: Firecracker y su jailer, una toolchain de Go, un kernel invitado y un sistema de archivos raíz, una imagen invitada de Python, una imagen de escritorio opcional con un navegador y dos unidades de systemd llamadas nehemiahd.service y boring-net.service. Después, el daemon responde en el puerto 8080 y una comprobación de estado fallida muestra /healthz didn't return ok. SKIP_DESKTOP=1 omite la imagen de escritorio, cuya compilación tarda aproximadamente 8 minutos según el README.

Lee las advertencias antes de pegar ese comando

Necesita acceso SSH como root en un host nuevo. El instalador escribe paquetes del sistema, unidades de systemd y configuración de red como root. Ejecútalo en una máquina que estés dispuesto a reconstruir desde cero, no en el servidor que ya aloja tu sitio.

El daemon se enlaza a 0.0.0.0:8080 de forma predeterminada. Cualquiera que alcance ese puerto puede crear máquinas, y esas máquinas consumen la clave del modelo que entregaste al instalador. Configura NEHEMIAH_TOKEN para exigir autenticación, o configura BIND_LOCALHOST=1 para que el daemon se enlace sólo a 127.0.0.1 y accede a él mediante un túnel con ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. La clave requiere el mismo cuidado que cualquier otro secreto del sistema, como se explica en mantener los secretos fuera de los agentes de IA.

Cada máquina es un equipo con acceso a Internet y agentes preinstalados. El README enumera claude, codex, cursor y pi dentro del guest, junto a node, python y git. El proyecto indica que los guest están detrás de un firewall de salida, y el límite de aislamiento es real. El guest sigue teniendo acceso a la red por diseño, porque un agente de programación que no puede descargar un paquete resulta inútil. Planifica teniendo esto en cuenta en lugar de asumir que existe un aislamiento físico de la red.

No existe ninguna release etiquetada. A fecha de 10 August 2026, el repositorio no tiene ninguna etiqueta, por lo que clonar main te proporciona lo que se haya incorporado esa misma mañana. Fija un commit y lee el script antes de ejecutarlo como root en tu servidor:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

El repositorio se creó a finales de June 2026, así que considéralo software reciente. Vuelve a leer infra/setup.sh después de cada actualización que descargues, porque lo que estás aprobando es el acceso como root a una máquina, no una actualización menor de la versión de una biblioteca.

Compruebe que KVM funciona antes de culpar al instalador

Si la configuración falla y quiere saber si la causa es KVM, pruebe Firecracker por separado. Estos son los pasos de descarga del proyecto original:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

La versión mostrada confirma que el binario corresponde a su arquitectura y se ejecuta. No confirma que tenga acceso a KVM, por lo que debe combinarla con la prueba de lectura y escritura en /dev/kvm descrita anteriormente. Ambas pruebas permiten distinguir un problema del proveedor de alojamiento de un problema de empaquetado. Así evita depurar un instalador que funcionaba correctamente.

¿Cuánto servidor necesitan varias microVM?

Cada microVM contiene un kernel invitado real y la memoria que se le asigne. Esa memoria queda reservada mientras la máquina está en ejecución. Por tanto, dimensione el host según el tamaño de cada invitado y el número de invitados que quiera ejecutar simultáneamente. Las cifras siguientes son cálculos aritméticos, no mediciones. Un invitado sin interfaz gráfica usa 1 GB. Un invitado de escritorio con un navegador usa 2 GB. El host reserva 2 GB fijos para sí mismo, el daemon y las compilaciones de imágenes.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

Una máquina sin interfaz gráfica necesita aproximadamente 3 GB, que un VPS de tamaño medio puede proporcionar si ofrece KVM. Cuatro máquinas necesitan 6 GB. Ejecute 8 máquinas de escritorio y el mismo cálculo requiere 18 GB antes de contar un solo gigabyte de disco.

El disco es el recurso que nadie suele planificar. El host almacena un kernel invitado, un sistema de archivos raíz base, una imagen por variante de invitado y una instantánea por máquina en ejecución. La imagen de escritorio con un navegador es la más grande. El README no indica ninguna cifra de disco, así que supervise df -h / durante la primera compilación en lugar de confiar en una estimación.

Por eso, la respuesta sincera a «¿qué VPS ejecuta Firecracker?» suele ser «una clase de máquina diferente». El hardware dedicado proporciona los indicadores de CPU sin que intervenga un hipervisor. Ese es el aspecto que debe tener en cuenta al elegir entre un VPS y un servidor dedicado. Algunos proveedores exponen virtualización anidada en sus planes virtuales. La virtualización anidada en un VPS explica cómo confirmarlo antes de pagar. Si el hardware ya es suyo, Proxmox frente a un VPS convencional plantea la misma cuestión desde el punto de vista del hipervisor.

El servidor también es la mitad barata. Cada máquina que entrega a un agente consume tokens del modelo mientras está en ejecución. Por tanto, una microVM inactiva consume memoria, mientras que una microVM ocupada consume memoria y genera gasto de API. Un plan de 1 GB no puede alojar el host. Un plan capaz de alojar el host tampoco pagará la clave.

FAQ

¿Cómo compruebo si mi VPS puede ejecutar Firecracker?

Ejecute ls -l /dev/kvm, systemd-detect-virt y grep -cE '\b(vmx|svm)\b' /proc/cpuinfo en el VPS. Un nodo de dispositivo perteneciente al grupo kvm, junto con un recuento de indicadores superior a cero, significa que Firecracker puede ejecutarse. Si falta el nodo y el recuento es 0, el hipervisor no está exponiendo la virtualización, y sudo kvm-ok del paquete cpu-checker lo confirma mediante KVM acceleration can NOT be used. En arm64, ignore el recuento, porque vmx y svm son nombres de x86.

¿Puedo activar la virtualización anidada desde mi VPS?

No. El host activa la virtualización anidada en el módulo del kernel del propio hipervisor, y usted la recibe como un indicador de CPU en el procesador virtual asignado. Dentro del guest, sudo modprobe kvm_intel devuelve modprobe: ERROR: could not insert 'kvm_intel': Operation not supported porque la CPU virtual no tiene VMX disponible. Sus opciones son contratar un proveedor que ofrezca virtualización anidada en el plan, o usar una máquina cuyo hipervisor administre usted.

¿Basta un contenedor para aislar un agente de programación?

A menudo, sí. Un contenedor comparte el kernel, por lo que una fuga a nivel del kernel llega al host, pero un contenedor desechable en una máquina que no almacena credenciales importantes elimina la mayor parte del riesgo real. Elija una microVM cuando un agente se ejecute sin supervisión durante periodos prolongados con código no revisado, y cuando pueda proporcionarle un host con /dev/kvm. Cuando no sea posible, un contenedor que destruya después de cada tarea es mejor que una microVM que nunca consigue arrancar.

¿Cuánta RAM necesita el host de un agente en una microVM?

Empiece por el tamaño del guest. Un guest sin interfaz gráfica de 1 GB, con una reserva de 2 GB para el host, necesita unos 3 GB en total, y 8 guests de escritorio de 2 GB cada uno necesitan unos 18 GB. El disco se calcula por separado y es fácil subestimarlo, porque el host conserva un kernel, sistemas de archivos raíz, una imagen por cada variante de guest y una instantánea por cada máquina en ejecución.