En el rack de cualquier empresa mediana hay un servidor encendido las veinticuatro horas que apenas usa una parte de lo que tiene dentro. Al lado hay otro igual, comprado tres años después, en las mismas condiciones. La virtualización de servidores existe justamente para eso: para que un solo equipo físico haga el trabajo de varios y para que nadie vuelva a comprar hierro nuevo cada vez que aparece una aplicación.
Este artículo está escrito como material de consulta y sirve en dos niveles. Si usted no trabaja en sistemas, empiece por el principio: verá qué es la virtualización de servidores, para qué sirve y qué gana la empresa. Si ya administra infraestructura, salte a las tablas. Encontrará la comparación entre hipervisores, los requisitos reales del procesador, las cifras de dimensionamiento y los comandos que se usan a diario.
Qué es la virtualización de servidores
La virtualización de servidores es la técnica que permite dividir un equipo físico en varios servidores independientes, cada uno con su propio sistema operativo. En primer lugar, ese equipo físico se llama anfitrión. Luego, cada servidor que vive dentro se llama máquina virtual. Finalmente, la capa de software que reparte el hardware entre todos ellos se llama hipervisor.
El documento que mejor lo describe es la guía NIST SP 800-125, del instituto de normas de Estados Unidos. Allí se define el hipervisor como la pieza que «controla el flujo de instrucciones entre los sistemas operativos invitados y el hardware físico», y que además «puede repartir los recursos del sistema y aislar los sistemas invitados, de modo que cada uno acceda solo a los suyos».
Ahora bien, la parte que casi nadie explica es la segunda mitad de esa frase. Un servidor virtualizado no solo comparte hardware: queda encapsulado. Es decir, el servidor entero —disco, configuración, memoria— se convierte en un conjunto de archivos. Y unos archivos se copian, se mueven a otro anfitrión y se levantan otra vez. Un servidor físico, en cambio, no se mueve a ninguna parte.
De ahí salen las tres propiedades que definen a cualquier plataforma de virtualización de servidores:
- Reparto. Un mismo procesador, una misma memoria y un mismo disco se dividen entre varias máquinas virtuales según lo que cada una necesite.
- Aislamiento. Si un servidor virtual se cuelga o se infecta, los demás siguen funcionando. Por lo tanto, un problema deja de arrastrar a toda la sala.
- Encapsulamiento. Cada máquina virtual es portátil. Así que se respalda, se clona y se traslada como si fuera un archivo más.
Para qué sirve la virtualización de servidores en una empresa
En una compañía mediana la virtualización rara vez se nombra en un comité. Sin embargo, sostiene decisiones de dinero que sí se discuten. Estos son los usos más frecuentes:
- Consolidar servidores viejos. Seis equipos con cinco años encima caben en uno solo. Por lo tanto, bajan el consumo eléctrico, el espacio del rack y los contratos de soporte de hardware.
- Separar aplicaciones que se estorban. El sistema contable, el servidor de archivos y la base de datos dejan de convivir en un mismo Windows. En cambio, cada uno recibe su propia máquina virtual.
- Levantar entornos de prueba. Un clon de producción se crea en minutos, se rompe a propósito y se borra. Así que nadie prueba una actualización sobre el servidor real.
- Acortar la recuperación tras una falla. Si el anfitrión muere, las máquinas virtuales se encienden en otro anfitrión. Además, no hace falta reinstalar nada.
- Aprovechar hardware que ya se pagó. Un servidor moderno tiene mucha más capacidad de la que consume una sola aplicación. Por ejemplo, el equipo de la fotografía de este artículo reúne 256 núcleos y 768 GB de memoria en dos zócalos.
- Preparar el camino a la nube. Una máquina virtual migra a un proveedor externo con mucho menos trabajo que un servidor físico.
El propio NIST resume el motivo principal sin rodeos: la razón más común para adoptar la virtualización es «la eficiencia operativa», porque las organizaciones «pueden usar su hardware existente de forma más eficiente al poner más carga en cada computador».
Cómo funciona la virtualización de servidores por dentro
Toda la virtualización de servidores se apoya en tres piezas. Conviene tener claros los nombres, porque son los que aparecen en cualquier cotización y en cualquier consola.
| Pieza | Qué es | Cómo se ve en la práctica |
|---|---|---|
| Anfitrión (host) | El servidor físico que aporta procesador, memoria, disco y red. | Es decir, el equipo del rack, con sus dos fuentes y sus discos al frente. |
| Hipervisor | El software que reparte ese hardware y aísla a los invitados. | Por ejemplo, la consola web o el gestor donde se ve la lista de servidores. |
| Máquina virtual (guest) | Un servidor completo con su sistema operativo propio. | Una fila en esa lista, con sus vCPU, su RAM y su disco. |
| Disco virtual | El archivo que contiene el disco duro completo del invitado. | Por ejemplo, un fichero .vhdx, .qcow2 o .vmdk en el almacenamiento. |
| Conmutador virtual | El switch por software que conecta las máquinas virtuales entre sí y con la red. | Una tarjeta de red que el invitado ve como si fuera física. |
| Plantilla (template) | Una máquina virtual base, ya configurada, que sirve de molde. | El punto de partida de cada servidor nuevo. |
En realidad, el invitado no sabe que está virtualizado. Ve un procesador, una tarjeta de red y un disco, y trabaja con ellos con normalidad. Mientras tanto, el hipervisor decide en cada instante a quién le toca el turno del procesador real. En resumen, esa traducción constante es todo el truco.
Hipervisor tipo 1 y tipo 2: cuál va en cada sitio
Ahora bien, hay dos formas de montar un hipervisor, y la diferencia decide el rendimiento, la seguridad y el precio. La industria las llama hipervisor tipo 1 y tipo 2. El NIST prefiere otros nombres, más descriptivos: virtualización bare metal —o nativa— y virtualización alojada.
| Aspecto | Tipo 1 · bare metal | Tipo 2 · alojado |
|---|---|---|
| Dónde corre | Directamente sobre el hardware, sin sistema operativo debajo. | Encima de un Windows, un Linux o un macOS ya instalado. |
| Rendimiento | Alto. Además, no hay una capa intermedia que estorbe. | Menor. En cambio, el sistema anfitrión se lleva su parte. |
| Superficie de ataque | Pequeña. De hecho, el hipervisor es mucho más simple que un sistema completo. | Mayor. Además, hereda todas las vulnerabilidades del sistema de abajo. |
| Encendido | Así que arranca solo con el servidor. | Depende de que alguien inicie sesión y abra el programa. |
| Ejemplos | VMware ESXi, Microsoft Hyper-V, Proxmox VE, KVM. | VirtualBox, VMware Workstation, Hyper-V en Windows 11. |
| Dónde se usa | Servidores de producción, sin excepción. | Portátiles de desarrollo, laboratorios y pruebas puntuales. |
Por qué en producción solo se usa el tipo 1
El NIST lo plantea como una decisión operativa y de seguridad a la vez: «añadir un hipervisor encima de un sistema operativo anfitrión agrega más complejidad y más vulnerabilidades al anfitrión». Dicho de otro modo, cada actualización del Windows de abajo pasa a ser un riesgo para los diez servidores de arriba. Por eso ningún servidor serio se virtualiza sobre un sistema de escritorio.
Virtualización de hardware: qué debe traer el procesador
Ningún hipervisor moderno funciona por software puro. Todos se apoyan en la virtualización de hardware, un conjunto de instrucciones que el procesador trae de fábrica y que hay que activar en la BIOS o en la UEFI. Sin ellas, la consola devuelve un error y no arranca ni una máquina virtual.
| Requisito | En Intel | En AMD | Para qué hace falta |
|---|---|---|---|
| Virtualización asistida | Intel VT-x | AMD-V | Ejecutar instrucciones privilegiadas del invitado sin emularlas. |
| Traducción de segundo nivel (SLAT) | EPT | NPT / RVI | Traducir la memoria del invitado sin penalizar el rendimiento. |
| Prevención de ejecución de datos | Bit XD | Bit NX | Impedir que se ejecute código en zonas de solo datos. |
| Asignación directa de dispositivos | Intel VT-d | AMD I/O MMU | Entregar una tarjeta física completa a un invitado. |
La documentación de requisitos de Hyper-V lo deja por escrito: hace falta «un procesador de 64 bits con traducción de direcciones de segundo nivel (SLAT)», más las extensiones de monitor de máquina virtual, al menos 4 GB de memoria y la virtualización activada en la BIOS o la UEFI. El proyecto KVM pide lo mismo por el lado de Linux: «hardware x86 que contenga extensiones de virtualización (Intel VT o AMD-V)».
De hecho, comprobarlo toma menos de un minuto. En Windows basta con systeminfo y revisar la sección «Requisitos de Hyper-V». En Linux, cualquiera de estas dos órdenes responde:
| Qué se quiere saber | En Windows | En Linux |
|---|---|---|
| Si el procesador soporta virtualización | systeminfo | lscpu | grep -i virtual |
| Cuántos núcleos la traen activada | wmic cpu get name,numberofcores | grep -c -E '(vmx|svm)' /proc/cpuinfo |
| Si el módulo del hipervisor está cargado | Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V | lsmod | grep kvm |
Un apunte que ahorra una llamada al proveedor. Si grep -c -E '(vmx|svm)' /proc/cpuinfo devuelve 0 en un servidor que sí debería soportarlo, el procesador no es el problema. La opción está desactivada en la UEFI y se arregla con un reinicio.
Los tipos de virtualización que existen además de la de servidores
La palabra se usa para cosas distintas y esa confusión cuesta reuniones enteras. Esta tabla separa las cinco que se encuentran en el mercado.
| Tipo | Qué se divide | Para qué se usa |
|---|---|---|
| De servidores | Un equipo físico, en varios servidores completos. | Consolidar el datacenter. Es el objeto de este artículo. |
| De escritorios (VDI) | Los puestos de trabajo, que pasan a correr en el servidor. | Entregar el escritorio del usuario desde el centro de datos. |
| De almacenamiento | Varios discos y cabinas, en un solo espacio lógico. | Presentar un único volumen a partir de hardware distinto. |
| De red | Una red física, en varias redes lógicas independientes. | Separar tráfico por VLAN y aislar entornos entre sí. |
| De aplicaciones | El programa, que se separa del sistema donde corre. | Ejecutar aplicaciones incompatibles sin instalarlas. |
La virtualización de red merece un apunte aparte, porque se apoya en la red de área local y en la segmentación por VLAN. Sin ese trabajo previo, las máquinas virtuales de un mismo anfitrión terminan viéndose entre sí sin ningún control.
Plataformas de virtualización de servidores que se ven en Colombia
En general, cuatro nombres cubren casi todo lo instalado en las empresas del país. Ninguno es malo. Sin embargo, cada uno resuelve un escenario distinto y cuesta un dinero distinto.
| Plataforma | Tipo | Modelo | Cuándo tiene sentido |
|---|---|---|---|
| VMware ESXi | 1 | Comercial, por suscripción | Parques grandes con procedimientos ya escritos alrededor de esa consola. |
| Microsoft Hyper-V | 1 | Incluido en Windows Server | Empresas cuyo parque ya es Windows y cuyas licencias ya están compradas. |
| Proxmox VE | 1 | Código abierto, soporte opcional | Presupuestos ajustados que igual necesitan clúster y respaldo integrados. |
| KVM | 1 | Parte del núcleo de Linux | Equipos con manejo de Linux. Es la base sobre la que corren otras. |
Un dato que sorprende a mucha gente: KVM no es un producto aparte. Está dentro del núcleo de Linux «desde la versión 2.6.20», publicada en 2007. Es decir, cualquier servidor Linux medianamente actual ya trae un hipervisor tipo 1 instalado. Por eso Proxmox VE y buena parte de la nube pública se apoyan en él.
Ventajas de la virtualización de servidores
Las ventajas de la virtualización de servidores se notan en tres frentes: la factura, la operación y el riesgo. Estas son las que se pueden medir.
- Menos equipos que comprar y mantener. Un anfitrión reemplaza a varios servidores. Por lo tanto, bajan la inversión inicial, el consumo y el mantenimiento.
- Puesta en marcha en minutos. Un servidor nuevo sale de una plantilla. En cambio, un servidor físico depende de una compra, un flete y una instalación.
- Recuperación mucho más rápida. Una máquina virtual se restaura completa, con su sistema y sus programas dentro.
- Movimiento sin apagar. La migración en vivo traslada un servidor virtual a otro anfitrión mientras trabaja. Así que el mantenimiento del hardware deja de exigir una ventana nocturna.
- Aislamiento de fallas. Una aplicación que consume toda la memoria afecta a su máquina virtual, no a las demás.
- Pruebas sin riesgo. Un clon permite ensayar una actualización antes de tocar producción.
- Mejor respuesta ante un incidente. El NIST señala que un servidor comprometido «puede revertirse a un estado sin infección rápidamente», mientras el estado completo se guarda para analizarlo después.
Diseñar, montar y administrar esa capa es parte de infraestructura y datacenter. Eso incluye los servidores dedicados, las máquinas virtuales, el almacenamiento y las migraciones entre entornos.
Las desventajas, que también existen
Ningún proveedor serio vende la virtualización como una decisión sin costo. Estos son los cuatro problemas reales, y conviene conocerlos antes y no después.
- Todos los huevos en la misma canasta. Si el anfitrión falla, caen todos sus invitados a la vez. Por eso un anfitrión solo, sin un segundo equipo detrás, concentra el riesgo en lugar de repartirlo.
- Un riesgo de seguridad nuevo. El NIST advierte que «puede haber riesgos de seguridad sustanciales al consolidar múltiples servicios dentro de un mismo hipervisor», porque un servicio crítico deja de estar en un equipo endurecido solo para él.
- Máquinas virtuales que nadie apaga. Crear un servidor es tan fácil que se crean de más. Al cabo de dos años hay veinte encendidos y nadie sabe qué hacen cuatro de ellos.
- Licenciamiento que se dispara. Algunos fabricantes cobran por núcleo físico del anfitrión, no por máquina virtual. Así que un servidor grande puede salir más caro en licencias que en hardware.
Contenedores y máquinas virtuales: no compiten por lo mismo
Es la comparación más repetida y casi siempre está mal planteada. La discusión entre contenedores y máquinas virtuales no es cuál gana, sino qué se está aislando en cada caso.
| Aspecto | Máquina virtual | Contenedor |
|---|---|---|
| Qué incluye | Un sistema operativo completo. | Solo la aplicación y sus dependencias. |
| Sobre qué corre | Sobre el hipervisor. | Sobre el núcleo del sistema anfitrión, que comparte. |
| Tamaño típico | Decenas de gigabytes. | Decenas o cientos de megabytes. |
| Arranque | Minutos. | Segundos. |
| Aislamiento | Fuerte: cada invitado tiene su propio núcleo. | Más débil: si cae el núcleo compartido, caen todos. |
| Sistemas distintos | Sí. Windows y Linux conviven en el mismo anfitrión. | No. El contenedor hereda el núcleo de abajo. |
| Para qué sirve mejor | Servidores completos y aplicaciones heredadas. | Aplicaciones nuevas, divididas en piezas pequeñas. |
En la práctica conviven. De hecho, lo habitual es levantar una máquina virtual y correr los contenedores dentro de ella. Así se conserva el aislamiento fuerte del hipervisor y se gana la velocidad del contenedor.
Cómo se dimensiona un anfitrión: CPU, memoria y disco
Aquí es donde la mayoría de proyectos se equivoca. Un anfitrión mal dimensionado no falla el primer día: falla el día que entra la carga de fin de mes. Estas son las reglas de campo que se aplican al planear, y conviene tomarlas como punto de partida, no como norma.
| Recurso | Se puede repartir de más | Criterio práctico |
|---|---|---|
| Procesador (vCPU) | Sí, y bastante | Entre 3 y 5 vCPU por núcleo físico en cargas de oficina. Mucho menos si hay bases de datos. |
| Memoria RAM | Casi nunca | Sume la RAM de todos los invitados y deje libre lo que consume el hipervisor. |
| Disco | Sí, con vigilancia | El aprovisionamiento fino permite prometer más de lo que hay. Si se llena, se detienen todos los invitados. |
| Red | Sí | Separe la administración, el respaldo y el tráfico de los invitados en interfaces distintas. |
La memoria es la restricción que de verdad manda. Un procesador ocupado hace esperar a la máquina virtual; una memoria agotada la tumba. Además, hoy pesa en el presupuesto más que nunca: el precio de la memoria RAM subió con fuerza y arrastró al de los servidores completos.
Y una regla que evita el error más caro de todos: nunca dimensione el clúster al límite. Si tiene tres anfitriones, planee para que las máquinas virtuales de los tres quepan en dos. Ese margen es lo que convierte una avería de hardware en un incidente menor.
Comandos para consultar y administrar máquinas virtuales
Casi toda la administración diaria se hace por consola web. Sin embargo, cuando la consola no responde, quedan estas órdenes. Están agrupadas por lo que uno quiere averiguar.
| Qué se quiere hacer | Hyper-V (PowerShell) | KVM / libvirt |
|---|---|---|
| Listar las máquinas virtuales | Get-VM | virsh list --all |
| Encender una | Start-VM -Name SRV01 | virsh start SRV01 |
| Apagarla de forma ordenada | Stop-VM -Name SRV01 | virsh shutdown SRV01 |
| Forzar el apagado | Stop-VM -Name SRV01 -TurnOff | virsh destroy SRV01 |
| Ver cuánta memoria tiene asignada | Get-VMMemory -VMName SRV01 | virsh dominfo SRV01 |
| Cambiar los procesadores virtuales | Set-VMProcessor -VMName SRV01 -Count 4 | virsh setvcpus SRV01 4 --config |
| Ver los discos virtuales | Get-VMHardDiskDrive -VMName SRV01 | virsh domblklist SRV01 |
| Crear un punto de control | Checkpoint-VM -Name SRV01 | virsh snapshot-create-as SRV01 |
| Ver el estado del anfitrión | Get-VMHost | virsh nodeinfo |
| Ver cuánto consume cada invitado | Measure-VM -VMName SRV01 | virt-top |
En Proxmox VE las órdenes son más cortas todavía: qm list enumera las máquinas virtuales, qm start 101 enciende la número 101, qm config 101 muestra su configuración completa y pvesm status informa del almacenamiento. Si el lado de Linux le resulta menos familiar, en este blog publicamos una guía con los comandos básicos de Linux agrupados por tarea.
Un snapshot no es una copia de seguridad
Es el malentendido más caro de toda la virtualización de servidores y aparece siempre en el peor momento. Un punto de control guarda el estado de la máquina virtual para poder volver atrás. Sin embargo, vive en el mismo almacenamiento que la máquina original. Por lo tanto, si el almacenamiento se pierde, se pierden los dos.
El NIST añade un riesgo que casi nadie considera: los snapshots «contienen el contenido de la memoria RAM en el momento en que se tomaron, y esto puede incluir información sensible que ni siquiera estaba guardada en el disco». Es decir, una contraseña en memoria queda escrita en un archivo que después se copia sin cuidado.
Hay un segundo efecto, este de operación pura: la misma guía advierte que «cuanto más tiempo se almacena una imagen sin ejecutarla, más vulnerabilidades es probable que contenga cuando se cargue de nuevo». Una plantilla creada hace un año y medio no es un punto de partida seguro. Es una deuda.
La regla, entonces, es sencilla. Los puntos de control sirven para deshacer un cambio en cuestión de horas. Las copias de verdad viven fuera del anfitrión y se prueban restaurándolas. Ese trabajo pertenece a continuidad operativa y respaldo, y no lo cubre la virtualización por sí sola.
Cuándo la virtualización de servidores deja de ser una ventaja
Una plataforma virtual bien montada envejece mal si nadie la mira. Estas cinco preguntas revelan el estado real en una sola reunión:
- ¿Cuántas máquinas virtuales hay encendidas y qué hace cada una? Si la respuesta tarda, sobran servidores pagando licencia y consumiendo memoria.
- ¿Cuánta memoria libre queda en cada anfitrión? Por debajo del veinte por ciento ya no cabe mover nada en una emergencia.
- ¿Cuándo se restauró una máquina virtual por última vez? Si nunca, el respaldo es una hipótesis.
- ¿Qué versión tiene el hipervisor? Es la capa que sostiene todo lo demás y también recibe parches críticos.
- ¿Quién recibe la alerta cuando un anfitrión se queda sin espacio? Sin respuesta, la falla se descubre cuando los usuarios llaman.
Esa última pregunta es la que más se descuida. Un anfitrión sin vigilancia avisa de sus problemas apagando invitados, y para entonces ya es tarde. Por eso el monitoreo de infraestructura de TI y la virtualización se contratan juntos: uno reparte los recursos y el otro avisa cuando se acaban.
Ahora bien, la decisión de fondo ya no es si virtualizar. Es dónde correr cada cosa, porque el equilibrio entre el servidor propio y el alquilado cambió: los centros de datos crecen a un ritmo que la energía disponible no siempre acompaña, y eso mueve los precios de los dos lados.
KHARONTE diseña, monta y administra la virtualización de servidores completa dentro de infraestructura y datacenter: servidores dedicados, máquinas virtuales, almacenamiento y migraciones entre entornos, con la operación del día a día a cargo de la mesa de servicio.
