Qué es la virtualización, explicada desde cero
Publicado el 2026-09-12 por frfrand
Cómo una máquina física se convierte en varias independientes, qué hace un hipervisor, la diferencia real entre una VM y un contenedor, y por qué todo el cómputo en la nube depende de esto.
Un servidor físico moderno tiene decenas de núcleos y cientos de gigabytes de memoria. Dedicarlo entero a una aplicación chica es un desperdicio enorme.
La virtualización resuelve eso: convierte una máquina física en varias máquinas independientes, cada una con su sistema operativo, sus usuarios y sus procesos, sin que se vean entre sí.
Qué hace un hipervisor
El hipervisor es la pieza que reparte. Se sienta entre el hardware y las máquinas virtuales, y les da a cada una la ilusión de tener su propio procesador, su memoria y sus discos.
Hay dos tipos, y la distinción importa:
Tipo 1, o bare metal. Corre directamente sobre el hardware, sin sistema operativo debajo. KVM (que es parte del kernel de Linux), Xen, VMware ESXi, Hyper-V. Es lo que usan todos los proveedores de nube.
Tipo 2. Corre como un programa dentro de un sistema operativo normal. VirtualBox, VMware Workstation. Cómodo para probar en tu máquina, con más sobrecarga.
Por qué no es lento
La pregunta natural es cómo puede una máquina virtual acercarse al rendimiento de una física si hay una capa en el medio.
La respuesta es que casi todo el código de la máquina virtual se ejecuta directamente en el procesador real, sin traducción. Los procesadores modernos traen instrucciones específicas para esto (VT-x en Intel, AMD-V en AMD) que permiten al hipervisor ceder el control y recuperarlo sólo cuando hace falta.
El hipervisor sólo interviene en las operaciones privilegiadas: acceso a dispositivos, gestión de memoria, interrupciones. Para todo lo demás, la máquina virtual usa el procesador de verdad.
Por eso la sobrecarga de CPU es de pocos puntos porcentuales. Donde sí se nota es en la entrada y salida, aunque también ahí hay soluciones (virtio, y pasar dispositivos directamente).
Contenedores: la otra forma
Un contenedor no virtualiza el hardware: comparte el kernel del sistema anfitrión y aísla lo demás.
Concretamente, usa dos funciones del kernel de Linux:
- Namespaces: el proceso ve sólo sus propios procesos, su red, su sistema de archivos. Lo que existe afuera, para él, no existe.
- cgroups: límites de cuánta CPU, memoria y entrada/salida puede consumir.
La consecuencia práctica: un contenedor arranca en un segundo y pesa megabytes, porque no tiene que iniciar un sistema operativo entero. Una máquina virtual tarda decenas de segundos y ocupa gigabytes.
Cuándo cada uno
La diferencia que más importa es de aislamiento. Una máquina virtual tiene su propio kernel; un contenedor comparte el del anfitrión. Si aparece una vulnerabilidad de escape en el kernel, el contenedor está mucho más cerca del sistema real.
Por eso:
- Clientes distintos, o cargas en las que no confiás → máquinas virtuales.
- Varios servicios de la misma aplicación, que ya confían entre sí → contenedores.
Y se combinan todo el tiempo: los proveedores de nube te dan una máquina virtual, y vos corrés contenedores adentro. Es exactamente el esquema de ArduMaker: cada cliente tiene su VPS aislado, y adentro puede levantar Docker desde el panel.
Lo que hizo posible
Vale dimensionarlo: sin virtualización no existiría la nube tal como la conocemos.
Poder crear un servidor en treinta segundos, destruirlo cuando no lo necesitás, pagarlo por hora, clonarlo, moverlo a otra máquina física sin apagarlo. Todo eso son propiedades de una máquina virtual, imposibles con hierro dedicado.
La instantánea es otro ejemplo: guardar el estado completo de una máquina (memoria incluida) y volver a él. Es virtualmente gratis con una VM y no tiene equivalente físico.