"¿Cuántas máquinas virtuales caben en este servidor?" Es la pregunta que todos hacen y está mal planteada. Físicamente "caben" muchas —hasta que el rendimiento se cae para todas al mismo tiempo—. La pregunta útil es otra: cuántas antes de que empiece a doler.
El cuello de botella casi nunca es el que crees
La intuición dice contar vCPUs: "tengo 32 núcleos, pongo tantas VMs". Pero el recurso que se agota primero rara vez es la CPU. Suele ser uno de estos dos:
- RAM: como se sobreasigna con poco margen (a diferencia de la CPU), es común quedarse sin memoria antes que sin ciclos. Y sin RAM, el sistema recurre al disco (swap) y todo se arrastra.
- IOPS del almacenamiento: muchas VMs compartiendo el mismo disco compiten por operaciones por segundo. Es el cuello de botella más subestimado —y el que ya explicamos al dimensionar CPU, RAM y disco—.
Saber cuál de estos se agota primero en tu servidor es lo que define la densidad real, no una fórmula general.
Las señales de que te pasaste
El servidor no avisa con un mensaje; avisa con síntomas que hay que saber leer. El más revelador es el "CPU steal": si supera unos pocos puntos porcentuales de forma sostenida, tus VMs están haciendo fila por el procesador. Súmale latencia general que sube, tiempos de respuesta erráticos y colas de disco que crecen. Cuando aparecen, ya estás sobrepoblado, y lo sienten todas las VMs —no solo la última que agregaste—. Por eso conviene monitorear estas métricas y no esperar a la queja.
Por qué la respuesta honesta es "depende"
Un servidor puede alojar cómodamente muchas VMs pequeñas y de bajo consumo, o muy pocas si son pesadas en memoria o disco. Dos servidores idénticos soportan densidades muy distintas según lo que corran encima. Quien te da un número redondo sin ver tus cargas está adivinando. La densidad se descubre observando el consumo real, con margen para los picos —y respetando que el hardware también sostiene la alta disponibilidad: si un nodo debe poder absorber las VMs de otro que cayó, no puedes llenarlo al tope—.
La regla del margen: N+1
Hay un límite que nada tiene que ver con el rendimiento y que mucha gente ignora: si tu servidor forma parte de un clúster de alta disponibilidad, no puedes llenarlo. La regla es N+1: el clúster debe poder perder un nodo y que los demás absorban sus VMs. Si tienes tres nodos al 90% de capacidad y uno cae, los otros dos no tienen dónde meter esa carga —y el failover que pagaste no sirve—. En un clúster HA, la densidad máxima por nodo baja a propósito, para dejar el colchón que hace posible la recuperación. Llenar al tope y tener HA son objetivos que se contradicen.
La pregunta que conviene hacerse
La pregunta no es "¿cuántas VMs caben?", sino ¿qué recurso se va a agotar primero en mi servidor, y cuánto margen tengo antes de que todas las VMs lo sientan? Es parte de lo que vigilamos y dimensionamos en nuestros servidores de alto rendimiento.
Preguntas frecuentes
help ¿Cuántas máquinas virtuales puedo poner en un servidor?
No hay número fijo: depende del consumo real de cada VM y de qué recurso se agota primero. La pregunta útil no es cuántas caben, sino cuántas antes de que el rendimiento se degrade para todas. Además, si el servidor forma parte de un clúster de alta disponibilidad, hay que dejar margen para absorber las VMs de un nodo caído.
help ¿Cuál es el cuello de botella al aumentar la densidad de VMs?
Rara vez es el número de vCPUs. Con más frecuencia es la RAM (que se sobreasigna con poco margen) o los IOPS del almacenamiento (muchas VMs compitiendo por el mismo disco). Identificar cuál se agota primero es la clave para saber cuántas VMs soporta realmente un servidor.
help ¿Qué señales indican que hay demasiadas VMs en un host?
El "CPU steal" sostenido por encima de unos pocos puntos porcentuales (las VMs esperando turno de CPU), la latencia general que sube, tiempos de respuesta erráticos y colas de disco crecientes. Cuando aparecen, el servidor ya está sobrepoblado y lo sienten todas las VMs, no solo la última que se agregó.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →