A simple vista, un contenedor y una máquina virtual hacen lo mismo: ejecutar programas separados dentro de un único equipo. La diferencia está en lo que arrastra cada uno: la máquina virtual lleva un sistema operativo completo con su propio núcleo, y el contenedor es un proceso aislado que se apoya en el núcleo del anfitrión. De ahí salen el resto de contrastes: qué sistemas puede ejecutar, cuántos recursos pide y qué frontera de seguridad ofrece.
Lo explicamos con la documentación de Docker, la de Microsoft sobre contenedores y máquinas virtuales, las páginas de manual de Linux y la de KVM, consultadas el 3 de noviembre de 2026. Aquí va la comparación técnica; para qué sirve esa herramienta en un servidor de casa está en Qué es Docker y qué problema resuelve en el self-hosting.
Qué virtualiza cada uno
Una máquina virtual imita un ordenador entero. La portada de KVM, una solución de virtualización completa para Linux, lo cuenta sin rodeos: cada máquina virtual tiene hardware virtualizado privado, «una tarjeta de red, un disco, un adaptador gráfico», y sobre él pueden correr imágenes de Linux o de Windows sin modificar.
Encima de ese hardware de mentira va todo lo demás. La página que explica qué es un contenedor describe la máquina virtual como un sistema operativo entero, «con su propio núcleo, sus controladores de hardware, sus programas y sus aplicaciones».
El contenedor trabaja a otra altura. Esa misma página lo define como «un proceso aislado con todos los archivos que necesita para funcionar». El resumen de contenedores en Windows añade qué ve ese proceso: «una vista aislada y, en algunos casos, virtualizada del sistema». Puede acceder a una versión virtualizada del sistema de archivos y del registro, pero los cambios solo afectan al contenedor y se descartan cuando se para.
La idea, en una frase: la máquina virtual virtualiza el hardware y el contenedor, el acceso al sistema operativo. Lo dice casi así la página de modos de aislamiento de esa misma casa: los contenedores de Windows «virtualizan el acceso» a varios espacios de nombres del sistema operativo.
El núcleo compartido y lo que implica
Lo que un contenedor comparte con el anfitrión es el núcleo, al que el resumen de Windows llama «las tuberías enterradas del sistema operativo». Compartirlo no da barra libre: el contenedor no recibe un acceso sin límites.
El núcleo tampoco lo da todo. La mayoría de las interfaces y los servicios que necesita una aplicación vienen de archivos de sistema, las bibliotecas, que funcionan por encima del núcleo en modo usuario. Como el contenedor está aislado del modo usuario del anfitrión, necesita su propia copia de esos archivos, y van empaquetados en lo que se conoce como imagen base. Por eso la máquina virtual ejecuta un sistema operativo completo, núcleo incluido, y el contenedor solo la parte de modo usuario, ajustada a los servicios que pida la aplicación.
La primera consecuencia es qué se puede ejecutar. La comparativa de contenedores y máquinas virtuales lo resume así: la máquina virtual corre «prácticamente cualquier sistema operativo», y el contenedor, «la misma versión del sistema operativo que el anfitrión».
La segunda se ve en cuanto se mezclan sistemas. La guía de contenedores Linux en Windows es directa: como los contenedores comparten el núcleo con su anfitrión, ejecutar contenedores Linux directamente en Windows no es una opción, y ahí es donde entra la virtualización. Docker Desktop para Windows admite tres motores para ello: WSL 2, que es el predeterminado, Hyper-V y Docker VMM (en beta), un hipervisor optimizado para contenedores. Del primero hablamos en Qué es WSL y qué permite hacer dentro de Windows.
Cómo aísla una máquina virtual: el hipervisor
El glosario de la arquitectura de Hyper-V define el hipervisor como «una capa de software que se sitúa entre el hardware y uno o varios sistemas operativos». Su trabajo principal es proporcionar entornos de ejecución aislados, a los que llama particiones, y controlar y arbitrar el acceso al hardware.
En esa arquitectura hay una partición raíz, que ejecuta Windows, tiene acceso directo a los dispositivos y crea las particiones hijas donde se alojan los sistemas invitados. Esas hijas no tocan el hardware: reciben una vista virtual de los recursos, en forma de dispositivos virtuales, y sus peticiones se redirigen a la partición raíz. Tampoco acceden al procesador físico ni atienden sus interrupciones: ven un procesador virtual y funcionan en una región de memoria virtual privada para cada partición.
Todo esto se apoya en el procesador. Hyper-V pide virtualización asistida por hardware, como Intel VT o AMD-V, y KVM pide lo mismo. La lista de preguntas frecuentes de KVM explica que son extensiones del juego de instrucciones que dan asistencia por hardware a los monitores de máquinas virtuales y permiten ejecutar «máquinas virtuales totalmente aisladas a velocidad nativa de hardware, para algunas cargas de trabajo».
KVM es un módulo cargable del núcleo, kvm.ko, más otro específico del procesador, kvm-intel.ko o kvm-amd.ko. Para crear la máquina virtual usa un programa QEMU ligeramente modificado, y una vez en marcha esa máquina es un proceso normal. La propia lista las separa en una línea: «QEMU usa emulación; KVM usa extensiones del procesador».
Cómo aísla un contenedor: espacios de nombres y grupos de control
En Linux, el contenedor no tiene un hipervisor debajo, sino dos funciones del núcleo. La primera son los espacios de nombres. Su página de manual explica que un espacio de nombres envuelve un recurso global del sistema en una abstracción que hace creer a los procesos de dentro que tienen su propia instancia aislada de ese recurso. Los cambios se ven dentro y son invisibles para los demás procesos, y el manual lo remata: «Un uso de los espacios de nombres es implementar contenedores».
Su tabla enumera lo que aísla cada tipo: los identificadores de proceso, los puntos de montaje, los dispositivos y puertos de red, los identificadores de usuario y de grupo, el nombre del equipo, la comunicación entre procesos, y algunos relojes. La guía de seguridad del motor de contenedores cuenta el efecto práctico: al arrancar un contenedor se crea un conjunto de espacios de nombres y de grupos de control para él, y los primeros dan «la primera y más directa forma de aislamiento». Los procesos de un contenedor no pueden ver, y menos aún alterar, los de otro contenedor o los del anfitrión, y cada uno recibe su propia pila de red.
La segunda función son los grupos de control (cgroups). Su manual los define como una función del núcleo que organiza los procesos en grupos jerárquicos cuyo uso de distintos tipos de recursos se puede limitar y supervisar; por ejemplo, el tiempo de procesador y la memoria disponibles. La guía de seguridad marca bien la frontera entre los dos: los grupos de control hacen que cada contenedor reciba su parte justa de memoria, procesador y disco, y que uno solo no pueda tumbar el sistema agotando un recurso, pero no intervienen en impedir que un contenedor acceda a los datos y procesos de otro. Dicho en corto: los espacios de nombres deciden qué ve el contenedor, y los grupos de control, cuánto gasta.
Windows sigue un esquema parecido. En su aislamiento de procesos, varios contenedores corren a la vez sobre un anfitrión con tecnologías de espacios de nombres y de control de recursos, y comparten el núcleo con él y entre ellos, «aproximadamente igual que como funcionan los contenedores Linux». Lo que se aísla por contenedor es el sistema de archivos, el registro, los puertos de red y el espacio de identificadores de procesos e hilos, entre otros.
Arranque, consumo y densidad
La comparativa dice que la máquina virtual, al ejecutar el sistema completo con su núcleo, requiere «más recursos del sistema (procesador, memoria y almacenamiento)», y que el contenedor usa menos. La página de qué es un contenedor lo plantea desde el uso: levantar una máquina virtual solo para aislar una aplicación «supone mucha sobrecarga», mientras que varios contenedores comparten un núcleo y permiten ejecutar más aplicaciones con menos infraestructura.
Sobre el arranque y la densidad, el resumen de Windows afirma que los contenedores arrancan y se paran rápido, lo que los hace aptos para aplicaciones que deben adaptarse deprisa a la demanda, y que su ligereza ayuda a aumentar la densidad y el aprovechamiento de la infraestructura. La presentación general de Docker va en la misma línea: lo define como una alternativa «viable y económica» a las máquinas virtuales basadas en hipervisor, pensada para entornos de alta densidad y para despliegues pequeños y medianos.
QEMU presume de ejecutar máquinas virtuales de KVM y Xen «con un rendimiento casi nativo». Son afirmaciones de cada proyecto sobre su propia tecnología.
La red y las actualizaciones siguen la misma lógica. La máquina virtual usa adaptadores de red virtuales; el contenedor, una vista aislada de un adaptador virtual, con algo menos de virtualización, ya que el cortafuegos del anfitrión se comparte con él, y usando menos recursos. Y para poner al día el sistema, las actualizaciones se instalan en cada máquina virtual, mientras que el contenedor se reconstruye sobre la imagen base nueva y se vuelve a desplegar.
Seguridad: qué frontera hay en cada caso
La comparativa es clara. La máquina virtual ofrece «aislamiento completo respecto al sistema operativo anfitrión y a otras máquinas virtuales», útil cuando una frontera de seguridad fuerte es crítica, como al alojar aplicaciones de empresas competidoras en un mismo servidor. El contenedor suele dar un aislamiento ligero, sin una frontera tan fuerte como la de una máquina virtual.
Entre los dos hay un punto intermedio. Con el aislamiento Hyper-V, cada contenedor se ejecuta dentro de una máquina virtual muy optimizada y, en la práctica, tiene su propio núcleo, y esa máquina aporta aislamiento a nivel de hardware respecto a los demás contenedores y al anfitrión. Los contenedores se crean, se gestionan y funcionan igual en los dos modos y usan las mismas imágenes; además, este permite ejecutar versiones anteriores del mismo sistema operativo.
La frontera del contenedor, además, se puede agujerear a propósito. Asignar archivos o volúmenes del anfitrión, puertos o la visibilidad de sus dispositivos son operaciones que el usuario debe pedir de forma deliberada, porque pueden comprometer la seguridad del contenedor.
La guía de seguridad del motor sostiene que los contenedores son «bastante seguros» por defecto, sobre todo si los procesos de dentro se ejecutan sin privilegios, y señala el punto delicado: el servicio que los gestiona necesita privilegios de administrador salvo en el modo Rootless. Según esa guía, solo deberían controlarlo usuarios de confianza, porque permite compartir una carpeta con el contenedor sin limitar sus derechos, hasta el punto de que la raíz del anfitrión quede montada dentro y se pueda alterar sin restricción. Y añade que nada impide tampoco compartir el sistema de archivos raíz con una máquina virtual. Los espacios de nombres de usuario, que asignan el administrador del contenedor a un usuario sin privilegios fuera de él, ayudan a mitigar el riesgo de que algo se escape; están disponibles, pero no se activan por defecto.
Cuándo encaja cada uno
Sus documentaciones no los presentan como rivales. La comparativa los llama tecnologías complementarias y recuerda que muchos despliegues de contenedores usan máquinas virtuales como sistema anfitrión, sobre todo en la nube. La página de qué es un contenedor pone el ejemplo: en un entorno de nube las máquinas suelen ser virtuales, y una con un motor de contenedores puede ejecutar varias aplicaciones en lugar de una, lo que mejora el aprovechamiento de los recursos.
La máquina virtual aparece en esas páginas cuando la frontera de seguridad es crítica o cuando hace falta otro sistema operativo. El contenedor aparece cuando se quiere aislar un entorno para que la aplicación reciba siempre las versiones de bibliotecas indicadas, sin conflictos de dependencias, o cuando se trata de hacer más con menos recursos.
Las diferencias principales, con lo que publica la comparativa:
| Aspecto | Máquina virtual | Contenedor |
|---|---|---|
| Sistema | Completo, con su núcleo | Solo la parte de modo usuario |
| Aislamiento | Completo frente al anfitrión y otras máquinas | Ligero; frontera menos fuerte |
| Invitado | Casi cualquier sistema operativo | La misma versión que el anfitrión |
| Recursos | Más procesador, memoria y almacenamiento | Menos recursos del sistema |
| Red | Adaptadores de red virtuales | Vista aislada de un adaptador virtual |
| Actualizar | Instalar en cada máquina | Reconstruir la imagen y volver a desplegar |
Te puede interesar
Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.
| Imagen | Producto | Características | Comprar |
|---|---|---|---|
 |
GL.iNet GL-MT3000 Beryl AX, router de viaje | Wi-Fi 6 de doble banda · WAN de 2,5 G · OpenVPN y WireGuard · OpenWrt · DNS sobre HTTPS y sobre TLS | Ver precio en Amazon |
 |
Beelink ME Mini, NAS de escritorio | Intel N95 (4 núcleos / 4 hilos) · 12 GB LPDDR5 · 6 ranuras M.2 NVMe de hasta 4 TB cada una · doble LAN de 2,5 Gbps | Ver precio en Amazon |
 |
Curso intensivo de Python, tercera edición | libro · tercera edición | Ver precio en Amazon |
 |
Raspberry Pi 5 | Broadcom BCM2712 · CPU Arm Cortex-A76 de 4 núcleos a 2,4 GHz · Wi-Fi de doble banda y Bluetooth 5.0 · Gigabit Ethernet con PoE+ (requiere HAT aparte) | Ver precio en Amazon |
