ProxLB, el proyecto de código abierto desarrollado para distribuir y rebalancear máquinas virtuales y contenedores entre los nodos de un clúster Proxmox VE, ha publicado su versión 2.3.0. La actualización incorpora nuevas opciones para excluir determinadas cargas, cambios en el comportamiento de su solver CP-SAT y correcciones relacionadas con el uso de etiquetas para fijar máquinas virtuales a nodos concretos.

Las claves de ProxLB 2.3 en 30 segundos

• ProxLB 2.3.0 fue publicado el 31 de agosto de 2026 como una actualización centrada en pequeños cambios y correcciones.
• Permite excluir máquinas virtuales y contenedores por nombre mediante ignore_guests.
• Añade control sobre el comportamiento del solver CP-SAT cuando no encuentra una solución viable.
• Corrige problemas de node pinning provocados por la conversión de etiquetas de Proxmox a minúsculas.
• ProxLB sigue ofreciendo un planificador externo y configurable para clústeres Proxmox VE.

La actualización no cambia la filosofía del proyecto, pero llega en un momento interesante para los administradores de Proxmox. El propio hipervisor ha avanzado en sus capacidades nativas de distribución dinámica de cargas, mientras herramientas externas como ProxLB buscan cubrir escenarios que necesitan políticas de colocación más específicas.

Desarrollado bajo el paraguas de credativ, ProxLB se define como un planificador de recursos y balanceador avanzado para clústeres Proxmox. Puede analizar CPU, memoria y almacenamiento local para decidir cómo distribuir las cargas y admite máquinas virtuales y contenedores. También contempla afinidad, antiafinidad, fijación a nodos y operaciones de mantenimiento.

Su funcionamiento se apoya en la API de Proxmox, por lo que no necesita utilizar SSH para realizar su trabajo. Puede ejecutarse como operación puntual, servicio en segundo plano o integrarse parcialmente en la interfaz web de Proxmox.

Qué cambia en ProxLB 2.3.0

Una de las novedades más prácticas es la incorporación de la opción ignore_guests. Hasta ahora ProxLB ya permitía excluir cargas mediante etiquetas, pero la nueva versión añade la posibilidad de indicar directamente qué máquinas virtuales o contenedores deben ignorarse por su nombre.

Puede parecer un cambio menor, pero en clústeres con muchas cargas existen sistemas que un administrador puede querer mantener fuera de cualquier política automática de migración. Puede ocurrir por requisitos de aplicaciones, dependencias con hardware, licencias o simplemente porque una determinada máquina requiere un tratamiento manual.

La segunda novedad afecta al solver CP-SAT, basado opcionalmente en Google OR-Tools.

ProxLB dispone de este mecanismo para calcular asignaciones de máquinas entre nodos mediante un modelo de optimización. El solver puede funcionar en modo shadow, donde calcula una propuesta sin modificar las migraciones realizadas por ProxLB, o en modo activo, donde pasa a dirigirlas.

La versión 2.3.0 incorpora solver.fallback_to_greedy, una opción relacionada con el comportamiento que debe seguir el sistema cuando el solver CP-SAT no consigue encontrar un plan viable en modo activo.

Esto permite controlar si ProxLB debe recurrir al algoritmo de balanceo greedy en esa situación.

También se ha modificado internamente el tratamiento de los conjuntos de datos RRD (Round Robin Database), sustituyendo la tupla utilizada anteriormente para devolver valores medios y máximos por un contenedor genérico denominado RrdDatasets.

Una pequeña corrección que afecta al node pinning

Entre las correcciones de ProxLB 2.3.0 hay una especialmente curiosa porque tiene su origen en el tratamiento de las etiquetas dentro de Proxmox VE.

ProxLB permite fijar una máquina virtual o un contenedor a determinados nodos del clúster mediante etiquetas. Una carga puede recibir, por ejemplo, una etiqueta asociada al nodo sobre el que debe ejecutarse.

Esta posibilidad puede utilizarse cuando existen requisitos de licenciamiento ligados a determinados servidores o cuando un nodo dispone de hardware específico que no está presente en el resto del clúster.

El problema es que la API de Proxmox convierte las cadenas utilizadas como etiquetas a minúsculas. ProxLB podía encontrarse entonces comparando esa información con nombres de nodos que conservaban mayúsculas y minúsculas.

La versión 2.3.0 corrige el comportamiento normalizando los nombres durante la comparación y devolviendo posteriormente el nombre original del nodo cuando genera la relación entre cargas y servidores.

Es un buen ejemplo de esos errores que pueden pasar desapercibidos durante bastante tiempo: el problema no estaba realmente en la política de colocación, sino en cómo dos componentes interpretaban una misma cadena de texto.

ProxLB frente al balanceo nativo de Proxmox

La utilidad de ProxLB también ha cambiado con la evolución de Proxmox VE.

El proyecto reconoce actualmente la existencia del Dynamic Load Balancing (DLB) introducido en Proxmox VE 9.2, que proporciona una solución integrada para distribuir automáticamente cargas gestionadas por High Availability (HA) entre los nodos del clúster.

Esto significa que ProxLB ya no ocupa exactamente el mismo espacio que cuando Proxmox carecía de un mecanismo nativo comparable.

La diferencia está principalmente en el alcance.

El DLB de Proxmox está integrado directamente con su infraestructura de HA y su planificador de recursos. ProxLB funciona como una capa externa con mayor capacidad de personalización y puede actuar también sobre cargas que no pertenecen al sistema HA.

Además, ProxLB contempla CPU, memoria, disco local, recursos asignados, sobreaprovisionamiento y métricas PSI (Pressure Stall Information), junto con políticas de afinidad, antiafinidad y fijación de cargas a determinados nodos.

El proyecto puede asimismo determinar cuál sería el mejor nodo para colocar una nueva máquina, una función que puede utilizarse posteriormente desde herramientas de automatización.

No significa que ProxLB sea automáticamente preferible al balanceador incorporado en Proxmox. Una funcionalidad nativa reduce componentes externos y simplifica mantenimiento y actualizaciones. ProxLB tiene sentido principalmente cuando las políticas necesarias exceden las posibilidades del mecanismo integrado o cuando se trabaja con versiones anteriores de Proxmox VE.

Hay otra precaución relevante. La documentación del proyecto advierte actualmente de posibles conflictos al combinar determinados grupos HA de Proxmox con la lógica de colocación propia de ProxLB, por lo que recomienda revisar cuidadosamente esta interacción antes de utilizar ambos mecanismos conjuntamente.

Automatizar también el mantenimiento del clúster

El balanceo no es la única función disponible.

ProxLB dispone de un modo de mantenimiento que permite marcar nodos para que dejen de recibir nuevas cargas y trasladar las existentes hacia otros servidores. El sistema tiene en cuenta los recursos disponibles y sus reglas de afinidad o antiafinidad antes de efectuar las migraciones.

También puede programarse el mantenimiento para determinadas ventanas temporales.

Para administradores con varios nodos esto permite automatizar parte del proceso previo a reinicios, actualizaciones del sistema o intervenciones sobre hardware.

ProxLB 2.3.0 puede actualizarse mediante el repositorio Debian del proyecto, paquetes .deb o imágenes de contenedor. El software continúa siendo abierto y su código, documentación, incidencias y desarrollo se mantienen públicamente.

La aparición del balanceo dinámico nativo en Proxmox VE 9.2 no elimina necesariamente el interés de herramientas como ProxLB. Más bien está definiendo dos niveles diferentes: una opción integrada para los escenarios estándar y herramientas externas para administradores que necesitan más control sobre dónde, cuándo y bajo qué condiciones se mueve cada carga del clúster.

Preguntas frecuentes

¿Qué es ProxLB para Proxmox?

ProxLB es un planificador y balanceador de cargas de código abierto para clústeres Proxmox VE. Analiza los recursos disponibles y puede redistribuir máquinas virtuales y contenedores entre diferentes nodos.

¿Qué novedades incluye ProxLB 2.3.0?

La versión añade la exclusión de cargas por nombre mediante ignore_guests, una opción para controlar el fallback del solver CP-SAT y varias correcciones, entre ellas un problema con las mayúsculas y minúsculas en las etiquetas utilizadas para fijar cargas a nodos.

¿ProxLB sigue siendo útil con el Dynamic Load Balancing de Proxmox VE 9.2?

Depende del escenario. El DLB ofrece integración nativa con Proxmox HA, mientras ProxLB mantiene opciones adicionales de personalización y puede trabajar con cargas que no forman parte del sistema HA.

¿ProxLB necesita instalarse en todos los nodos Proxmox?

No. ProxLB funciona mediante la API de Proxmox y puede ejecutarse desde un sistema con acceso a ella. El proyecto admite instalación mediante paquetes Debian, contenedores o directamente desde su código fuente.