Actualizar los nodos de un clúster Proxmox VE puede convertirse en una operación delicada cuando hay máquinas virtuales en ejecución, ventanas de mantenimiento limitadas y varios servidores que deben reiniciarse uno a uno. ProxPatch, un proyecto open source de gyptazy, automatiza ese proceso: revisa el estado del clúster, mueve las máquinas virtuales, aplica las actualizaciones, reinicia los nodos cuando es necesario y continúa con el siguiente servidor.

Las claves de ProxPatch en 20 segundos

• Automatiza las actualizaciones rolling de nodos Proxmox VE.
• Migra las máquinas virtuales antes de intervenir en cada servidor.
• Usa herramientas nativas como pvesh, qm y SSH.
• Requiere al menos tres nodos, quorum estable y almacenamiento compartido.
• El proyecto sigue en una fase temprana y recomienda pruebas antes de usarlo.

La propuesta se centra en una tarea muy concreta de administración: mantener actualizados los nodos de un clúster reduciendo la intervención manual y evitando interrupciones innecesarias. ProxPatch no pretende sustituir las funciones de alta disponibilidad de Proxmox VE ni convertirse en una plataforma completa para gestionar todo el ciclo de vida de la infraestructura.

De drenar un nodo a comprobar su vuelta al servicio

El funcionamiento de ProxPatch sigue el mismo procedimiento que tendría que ejecutar un administrador de sistemas de forma manual. La herramienta inspecciona el estado del clúster y, cuando corresponde intervenir en un nodo, coordina la migración de las máquinas virtuales que están ejecutándose sobre él.

Una vez que el nodo queda preparado para el mantenimiento, ProxPatch aplica las actualizaciones mediante SSH. Después determina si es necesario reiniciar el servidor y, si lo es, controla el proceso hasta comprobar que vuelve a estar operativo. Solo entonces continúa con el siguiente nodo.

La diferencia está en que estas operaciones quedan integradas en un flujo automatizado. El objetivo declarado por el proyecto es priorizar la seguridad sobre la velocidad, mantener el clúster operativo y hacer que el proceso sea observable y fácil de revisar.

La herramienta utiliza elementos habituales de Proxmox VE, entre ellos pvesh, qm y SSH, en lugar de depender de una plataforma externa de orquestación. El repositorio también indica que no necesita bases de datos externas ni tokens de API. Sí requiere jq en el equipo desde el que se ejecuta para procesar las respuestas JSON.

Ese diseño reduce la cantidad de piezas que hay que introducir en la infraestructura. También hace que el comportamiento de ProxPatch resulte relativamente sencillo de seguir para un administrador familiarizado con Proxmox y las herramientas de línea de comandos.

El clúster debe estar preparado para la migración

La automatización no elimina los requisitos técnicos que permiten realizar un mantenimiento rolling. La documentación de ProxPatch establece un mínimo de tres nodos y exige que el clúster mantenga el quorum durante el proceso.

También recomienda almacenamiento compartido, como Ceph o NFS, para permitir la migración en vivo de las máquinas virtuales. A esto se suma el acceso SSH a los nodos, con autenticación mediante claves como opción recomendada.

Estas condiciones son relevantes porque ProxPatch necesita disponer de un lugar al que trasladar las cargas antes de actualizar un servidor. Si el resto del clúster no tiene capacidad suficiente, si una máquina virtual no puede migrarse o si el almacenamiento no permite ese procedimiento, la automatización no puede solucionar por sí sola el problema.

La instalación está pensada para ejecutarse desde un único nodo del clúster. El proyecto advierte expresamente de que el servicio proxpatch no debe activarse simultáneamente en varios nodos. La herramienta puede instalarse desde el repositorio Debian de gyptazy y también ofrece paquetes Debian directamente.

La configuración inicial pretende ser reducida. En muchos casos no hace falta crear un fichero adicional, aunque existe /etc/proxpatch/config.yaml para modificar determinados parámetros. Una vez instalado, el proceso puede ejecutarse mediante el servicio systemd proporcionado por el proyecto.

La documentación señala compatibilidad con Proxmox VE 8.x y 9.x. El uso de la herramienta queda así ligado a una infraestructura que cumpla las condiciones necesarias para mantener el quorum y realizar las migraciones.

ProxPatch nació separado de ProxLB

El proyecto está relacionado con ProxLB, otra herramienta de gyptazy orientada al balanceo de máquinas virtuales dentro de clústeres Proxmox. La idea inicial era incorporar el parcheo rolling a ese proyecto, pero el autor explica que la ausencia de determinados endpoints de la API de Proxmox para gestionar actualizaciones y reinicios de nodos llevó a desarrollar ProxPatch como una herramienta independiente.

El resultado es un proyecto especializado en una sola operación. ProxPatch puede utilizarse junto a ProxLB, pero no depende de él. Esa separación también evita convertir una herramienta de balanceo en una plataforma más amplia de mantenimiento de nodos.

Para los administradores, esta distinción importa porque ProxPatch no pretende sustituir otras prácticas de operación. Los backups, la monitorización, las pruebas previas, la gestión de configuración y los procedimientos para recuperar un nodo que no vuelva correctamente tras un reinicio siguen siendo responsabilidad del entorno.

El propio repositorio introduce además una cautela relevante: el software se encuentra en una fase temprana de desarrollo y debe considerarse experimental. El autor recomienda probar todas sus funciones en laboratorios aislados o entornos de staging antes de utilizarlo en otros escenarios.

Esa advertencia adquiere especial importancia por el tipo de tareas que automatiza. Un fallo durante una migración, un nodo que no recupera el servicio después de un reinicio, una actualización de kernel o una máquina virtual con requisitos especiales pueden convertir una operación rutinaria en una incidencia.

Por eso, el interés de ProxPatch está menos en eliminar la intervención del administrador que en convertir un procedimiento repetitivo en un flujo definido. Si la infraestructura cumple los requisitos, la herramienta puede encargarse de una secuencia que de otro modo exige comprobar el estado del clúster, migrar cargas, actualizar, reiniciar y validar cada nodo de forma manual.

La propuesta también refleja una necesidad habitual en las plataformas de virtualización: las funciones básicas de una infraestructura pueden estar disponibles, mientras que determinadas tareas operativas necesitan herramientas adicionales. En este caso, ProxPatch cubre específicamente la actualización rolling de los nodos y deja fuera otras funciones para mantener el alcance del proyecto reducido.

Su evolución dependerá de la madurez del código, de las pruebas que acumule y de cómo responda ante situaciones menos habituales que las de un clúster perfectamente preparado. Para una herramienta que interviene directamente sobre servidores, máquinas virtuales y reinicios, esas pruebas son tan importantes como la automatización del procedimiento normal.

Preguntas frecuentes

¿Qué es ProxPatch?
ProxPatch es una herramienta open source para automatizar actualizaciones rolling en clústeres Proxmox VE. Migra las máquinas virtuales, aplica los parches y reinicia los nodos cuando es necesario.

¿ProxPatch evita el tiempo de inactividad?
Su diseño busca mantener las cargas en funcionamiento mediante migración en vivo, pero depende de que el clúster tenga quorum, capacidad disponible y almacenamiento compatible con esa migración.

¿Cuántos nodos necesita ProxPatch?
La documentación establece un mínimo de tres nodos y exige que el clúster mantenga el quorum durante el proceso de actualización.

¿ProxPatch está preparado para producción?
El repositorio lo considera un proyecto en una fase temprana y experimental. El autor recomienda probarlo en laboratorios o entornos de staging antes de utilizarlo en otros entornos.