Proxmox VE 9.2 incorporó balanceo dinámico de carga con el Cluster Resource Scheduler, y por ahí fuera se ha resumido como que el cluster por fin se equilibra solo. Proxmox nunca prometió eso: sus propias notas de versión dicen dos veces "HA-managed guests", y el manual lo cierra del todo — "Currently, these migrations are issued only for HA resources and executed sequentially". Lo que no está escrito en ninguno de los dos sitios es lo que cuesta meter una VM en ese club, y ahí es donde aparece un watchdog y un nodo dispuesto a reiniciarse en sesenta segundos.
Operamos clústeres de Proxmox VE con almacenamiento Ceph en producción, repartidos en varios datacenters. Sobre el balanceador dinámico no te vamos a dar una estadística de cuántas migraciones nos ha ahorrado, porque sería inventada. Lo que sigue es otra cosa: lo que dice exactamente la documentación de la 9.2, qué valores trae de fábrica, y el criterio con el que decidimos encenderlo o dejarlo apagado en cada cluster.
Tres modos, y el que traes puesto no sirve para esto
El CRS es quien elige en qué nodo va cada recurso HA. Tiene tres modos, configurables en Datacenter → Options → Cluster Resource Scheduling:
- 1
basic— cuenta cuántos invitados activos hay en cada nodo. Nada más. Es el valor por defecto. - 2
static— usa las cuotas de CPU y memoria configuradas en los invitados activos. Lo que pone en el fichero de la VM, no lo que consume. - 3
dynamic— suma a lo anterior el uso medio real de CPU y memoria. Es el modo que la 9.2 estrenó y el que le da sentido al balanceador.
Aquí está el primer malentendido: el balanceador automático no se activa solo al actualizar. Exige estar en static o en dynamic, y además encender un interruptor propio, ha-auto-rebalance, que viene a 0. Si actualizaste a la 9.2 y no tocaste nada, sigues en basic y con el balanceo apagado. La noticia de "Proxmox ya equilibra el cluster" describe una capacidad, no algo que te vayas a encontrar funcionando.
La aritmética por defecto: 30 %, tres rondas, 10 %
El balanceador no mueve nada en cuanto un nodo va más cargado que otro. Tiene que superar tres filtros encadenados, y los tres tienen número. El desequilibrio del cluster se deriva de la desviación típica y la media de las cargas de los nodos, normalizado a un rango de 0 a 100 %:
| Parámetro | Por defecto | Qué decide |
|---|---|---|
ha-auto-rebalance | 0 | Apagado de fábrica. |
ha-auto-rebalance-threshold | 30 | Desequilibrio en % que hay que superar para empezar a contar. |
ha-auto-rebalance-hold-duration | 3 | Rondas consecutivas por encima del umbral. Cada ronda dura unos 10 s. |
ha-auto-rebalance-margin | 10 | Mejora mínima RELATIVA, en %, para que la migración elegida merezca la pena. |
ha-auto-rebalance-method | bruteforce | Cómo se puntúan las migraciones candidatas. La alternativa es topsis. |
auto-rebalance (por recurso) | 1 | Cada recurso HA entra en el reparto salvo que lo saques tú. |
Traducido: con los valores de fábrica, el cluster tiene que estar desequilibrado por encima del 30 % durante unos 30 segundos seguidos, y encima la migración que el CRS elija tiene que prometer una mejora de al menos el 10 %. Eso es deliberado: un balanceador que reaccionara al primer pico estaría moviendo máquinas toda la noche mientras corren los backups. El efecto práctico merece decirse en voz alta, porque es contraintuitivo: el balanceador está hecho para no arreglar tus picos cortos. Si tu problema es que de 2 a 4 de la madrugada un nodo se pone a tope, esto no es la herramienta.
El alcance: solo lo que hayas declarado
La frase de la documentación no admite interpretación: las migraciones de reequilibrio "are issued only for HA resources and executed sequentially". Dos cosas en una línea. La primera, que una VM que no sea recurso HA es invisible para el balanceador por mucho que esté devorando el nodo. La segunda, que las migraciones van de una en una: un cluster muy desnivelado no se arregla en un suspiro, se va arreglando. Y el propio manual deja abierta la puerta de salida: "It is planned that load balancing will also include non-HA resources in the future". Planeado. Hoy no.
Hay un detalle fino que conviene conocer antes de que te sorprenda: las migraciones de reequilibrio respetan las reglas de afinidad, y si desactivas auto-rebalance en un recurso, cualquier otro recurso con afinidad positiva hacia él también queda fuera del reparto. Es coherente —si dos máquinas tienen que vivir juntas, no puedes mover una sola— pero significa que excluir una VM puede excluir, sin que lo pidas, a todo su grupo. Si llevas tiempo peleándote con las reglas de afinidad de la rama 9, ya escribimos sobre cómo el cluster cuenta los invitados cuando aplica anti-afinidad.
El precio de entrar en el reparto: 60 segundos
Aquí es donde esto deja de ser una conversación sobre rendimiento. Para que el balanceador pueda mover una VM, esa VM tiene que ser recurso HA. Y la pila de HA de Proxmox se sostiene sobre un watchdog: mientras un nodo tenga servicios HA activos, su LRM mantiene el watchdog abierto y lo va reseteando. Cuando ese nodo deja de estar en el quórum del cluster, el LRM espera a que se forme uno nuevo y, mientras no lo haya, no puede resetear el watchdog. La documentación cierra la frase sin rodeos: eso "will trigger a reboot after the watchdog has timed out (this happens after 60 seconds)".
El reverso de esa regla está en el mismo manual y casi nadie lo cita: "If no service is configured for more than 15 minutes, the CRM automatically returns to the idle state and closes the watchdog completely". O sea: un cluster sin ningún recurso HA declarado acaba cerrando el watchdog y no se auto-reinicia. Ese nodo, ante un corte de red, se degrada y espera. El tuyo, en cuanto ese nodo tenga servicios HA activos, se reinicia. Conviene quedarse con la acotación exacta, porque no vale para todos los nodos por igual: el manual avisa de que un nodo con CRM activo pero con el LRM ocioso no dispara el auto-fencing, ya que el LRM solo sostiene su watchdog mientras tiene su agent lock. El reloj corre en el nodo donde de verdad están corriendo los servicios HA, no en el cluster entero.
Y ahora la conclusión que no está escrita en ningún manual, porque es nuestra y se deduce de juntar las dos piezas: el alcance del balanceador es más pequeño que el radio de su daño. Mueve únicamente las VMs que hayas declarado HA, pero el reinicio que trae consigo se lleva por delante todo lo que haya en ese nodo, declarado o no. Las VMs HA se recuperan en otro nodo; las que no declaraste vuelven cuando el nodo vuelva. Dicho de otro modo: al encender el balanceo estás firmando que prefieres que un nodo aislado se reinicie antes que siga sirviendo en soledad. Hay clusters donde esa firma es obviamente correcta y clusters donde no, pero la firma se da en la columna de la resiliencia y se cobra en ella, aunque se firme desde el panel de rendimiento.
Lo que no va a mover aunque lo declares
Un reequilibrio es una migración, y una migración necesita que el destino pueda ejecutar esa VM. El manual lista los requisitos de la pila HA sin adornos: al menos tres nodos, almacenamiento compartido y redundancia de hardware. Y, para que el HA Manager considere elegible cualquier nodo, pide que el invitado:
- ✓use opciones compatibles con todos los nodos del cluster;
- ✓use solo almacenamiento compartido accesible desde todos los nodos;
- ✓use solo interfaces de red que existan en todos los nodos;
- ✓use solo passthroughs de dispositivo presentes en todos los nodos.
Lee esa lista pensando en tu parque real y verás el problema: la máquina que de verdad te desnivela el cluster suele ser precisamente la que incumple alguno de los cuatro puntos. La que tiene el disco en almacenamiento local porque "es que necesita IOPS". La que lleva una tarjeta en passthrough. La que cuelga de un bridge que solo existe en dos de los cinco nodos. El manual da salida a esos casos, y conviene no exagerar la condena: si una dependencia solo está en un subconjunto de nodos, se restringe el recurso a ese subconjunto con una regla estricta de afinidad de nodo, y el HA Manager limita a esos nodos la colocación, la recuperación y la migración. Es decir, esa VM sí se reequilibra, pero solo entre los dos nodos donde puede vivir. El balanceador reparte bien el conjunto de máquinas que ya eran fáciles de mover, y el trabajo aburrido de poner el almacenamiento compartido en condiciones sigue siendo donde se gana. Si lo tuyo es Ceph, conviene tener claro antes qué aguanta de verdad un cluster de tres nodos, y si vienes de más atrás, por qué el HA de Proxmox no evita la caída, la acorta.
La novedad de la 9.2 que más nos importa no es el balanceador
En la misma versión llegaron dos órdenes del CRM, disarm-ha y arm-ha, que desarman la pila de HA en todo el cluster. Sirven para hacer mantenimiento planificado, como tocar la red del cluster, "without triggering any node fencing events", y el estado de los recursos HA se preserva durante la ventana para que vuelvan a su sitio al acabar. Se invoca eligiendo modo de recurso: ha-manager crm-command disarm-ha freeze o ignore, y arm-ha al terminar. A nosotros nos resulta más útil que el balanceo, porque cualquiera que haya tenido que mover un switch con un cluster HA encima conoce la cuenta atrás de "como esto tarde más de un minuto, se me reinician los nodos".
Con su letra pequeña, que el manual marca como importante: mientras la pila está desarmada "no automatic recovery, failover, or fencing takes place" y un fallo de nodo en esa ventana no lo detecta ni lo gestiona HA. Así que la ventana se abre corta, con el cluster sano, y se cierra en cuanto acabas.
Cuándo no lo encenderíamos
No por desconfianza de la herramienta, sino porque en estos casos no resolvería el problema que el cliente tiene delante:
- —Cluster de tres nodos al límite de capacidad. Si los tres van justos, el hueco que necesitas libre no es el que iguala la media: es el que te permite absorber la caída de un nodo entero. Reequilibrar para quedarte sin ese hueco es optimizar el día bueno a costa del malo.
- —Corosync compartiendo cable con otra cosa. Si la red del cluster convive con la replicación o con el tráfico de las VMs, los cortes de quórum dejan de ser teóricos; y ahora cada corte de quórum tiene un reloj de 60 segundos al lado. Primero la red, después el balanceo.
- —Cuando la carga desigual tiene nombre y apellidos. Si lo que desnivela el cluster es una única VM concreta y conocida, moverla una vez con la cabeza es mejor que montar un sistema que la mueva sola cada vez que pase del umbral. Automatizar una decisión que solo se toma dos veces al año la esconde en vez de resolverla.
Las seis preguntas antes de darle al interruptor
Todas se responden con un sí, un no o un número. Si alguna no la sabes, esa es la tarea de esta semana, no el balanceador:
- 1.¿Cuántas VMs de este nodo no son recursos HA? Ese es el daño colateral del día que se reinicie.
- 2.¿Corosync tiene su propia red, separada del almacenamiento y de las VMs? Sí o no.
- 3.De las VMs que vas a declarar HA, ¿cuántas tienen disco local, passthrough o un bridge que no existe en todos los nodos? Esas no se van a mover.
- 4.Si cae un nodo entero, ¿caben sus VMs en los que quedan? Si la respuesta es "justo", el reequilibrio te va a comer ese margen.
- 5.¿Tu desequilibrio real supera el 30 % durante más de medio minuto seguido, o son picos de diez segundos? Míralo antes, no después.
- 6.¿Está
disarm-haescrito en vuestro procedimiento de mantenimiento de red, o se confía en que nadie tarde más de un minuto?
El balanceo dinámico de la 9.2 es una buena pieza y hace lo que dice. Nuestro criterio para encenderlo cabe en una línea: cuando la red del cluster está donde tiene que estar y sobra margen para perder un nodo entero. Y lo dejamos apagado, sin ninguna vergüenza, cuando no.
En everyWAN diseñamos y operamos infraestructura y cloud sobre Proxmox VE con almacenamiento distribuido Ceph en producción. No vendemos licencias de nadie, así que cuando decimos que una función no te hace falta, no estamos dejando de facturar nada.
Fuentes (verificadas el 06-11-2026): secciones Cluster Resource Scheduling, CRS Load Balancer, Requirements, Resources y Cluster Resource Manager (de donde salen las citas del watchdog, los 60 segundos y los 15 minutos) del manual de administración de Proxmox VE, versión 9.2.13 (última actualización del documento: 24-sep-2026) — pve-docs: HA Manager; valores por defecto de crs (el valor por recurso auto-rebalance está en la sección Resources del manual, no aquí) — datacenter.cfg(5); novedades y fecha de Proxmox VE 9.2 (21-may-2026), incluidos el balanceo dinámico y disarm-ha/arm-ha — Roadmap de Proxmox VE. Las citas en inglés están tomadas literalmente de esas páginas. La lectura sobre el radio de daño del reinicio es nuestra, no de la documentación, y se deduce de que el watchdog actúa sobre el nodo y no sobre el recurso.
¿Vas a declarar HA media docena de VMs y no tienes claro qué cambia en el nodo?
Revisamos el diseño del cluster, la red de Corosync y el margen real que te queda para perder un nodo. Con números tuyos, no con los de un folleto.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN