Cómo hace Ubuntu para virtualizar: KVM, namespaces y cgroups

Publicado el 2026-09-12 por frfrand

Las tres piezas que trae el kernel de Linux y que sostienen casi toda la infraestructura moderna. Qué hace cada una, cómo se combinan y qué comandos te dejan verlas funcionando.

Cuando alguien dice "Ubuntu puede virtualizar", suena a que trae una aplicación para eso. No es así: las capacidades están en el kernel de Linux, y son tres piezas distintas que resuelven problemas distintos.

Entenderlas explica cómo funcionan Docker, LXC, Kubernetes y prácticamente todo el alojamiento moderno, porque todos se apoyan en las mismas tres.

KVM: el kernel como hipervisor

KVM (Kernel-based Virtual Machine) está en el kernel de Linux desde 2007. Convierte al propio Linux en un hipervisor de tipo 1.

La idea es elegante: en vez de escribir un hipervisor desde cero, aprovecha que el kernel ya sabe planificar procesos, gestionar memoria y hablar con dispositivos. Una máquina virtual pasa a ser, para Linux, un proceso más al que se le asignan recursos.

El código de la máquina virtual se ejecuta directamente en el procesador real, usando las extensiones de virtualización del hardware. KVM sólo interviene en las operaciones privilegiadas.

Comprobar si tu máquina puede:

grep -c -E "vmx|svm" /proc/cpuinfo

Si devuelve un número mayor que cero, el procesador tiene las extensiones. vmx es Intel, svm es AMD.

KVM suele venir acompañado de QEMU, que emula los dispositivos (discos, red, vídeo), y de libvirt, que es la capa de administración que usan las herramientas de más alto nivel.

Namespaces: qué puede ver un proceso

Un namespace limita la visión que un proceso tiene del sistema. Hay varios tipos, cada uno para un aspecto:

• PID: qué procesos ve. Adentro de su namespace, el primero es el PID 1 y no ve nada de afuera.
• NET: sus propias interfaces de red, su tabla de rutas, sus reglas de firewall.
• MNT: su propio árbol de directorios montados.
• UTS: su propio nombre de host.
• USER: correspondencias de identificadores, de modo que root adentro no sea root afuera.

Cuando estás adentro de un contenedor y hacés "ps aux" y sólo ves dos procesos, eso es un namespace de PID en acción. Los otros mil procesos del anfitrión siguen existiendo: simplemente no son visibles.

Se pueden ver los namespaces de un proceso:

ls -l /proc/self/ns/

cgroups: cuánto puede consumir

Los namespaces aíslan lo que se ve; los cgroups limitan lo que se usa.

Con cgroups se define cuánta CPU, cuánta memoria, cuánto ancho de banda de disco puede consumir un grupo de procesos. Es lo que evita que un contenedor se lleve toda la máquina.

Y es también lo que hace systemd por debajo: cada servicio del sistema corre en su propio cgroup, y por eso se pueden poner límites de memoria por servicio.

systemctl set-property miapp.service MemoryMax=512M

La versión 2 de cgroups, que es la que usan las distribuciones modernas, unificó la jerarquía y hace que este control sea mucho más coherente.

Cómo se combinan

Docker y LXC usan namespaces y cgroups: aíslan y limitan, pero comparten el kernel del anfitrión.

KVM es otra cosa: crea una máquina con su propio kernel.

Un proveedor de nube suele combinar los dos: KVM para separar clientes, y adentro de cada máquina, contenedores para separar aplicaciones.

Lo interesante es que nada de esto requiere software adicional. Está en el kernel que ya tenés instalado. Docker, LXC y Kubernetes son interfaces cómodas sobre funciones que Linux trae de fábrica.

Y por eso un comando tan simple como este:

systemd-detect-virt

te dice en qué tipo de entorno estás corriendo: kvm, lxc, docker, o none si es hardware real.