Actualizar un clúster Proxmox VE parece una tarea rutinaria hasta que hay que hacerlo nodo por nodo, con máquinas virtuales en producción, ventanas de mantenimiento ajustadas y el riesgo de dejar un host a medio reiniciar. ProxPatch nace precisamente para automatizar ese trabajo repetitivo: drenar un nodo, migrar las máquinas virtuales, aplicar parches, reiniciar si hace falta y repetir el proceso con el siguiente servidor del clúster.
La herramienta, desarrollada por gyptazy, se presenta como un orquestador ligero de actualizaciones rolling para Proxmox VE. Su objetivo no es sustituir a una solución de alta disponibilidad ni convertirse en una plataforma completa de ciclo de vida. Hace una sola cosa: mantener actualizados los nodos de un clúster Proxmox con el menor impacto posible sobre las cargas en ejecución.
La idea encaja con una realidad cada vez más visible en entornos virtualizados: la seguridad ya no depende solo de tener backups o buena segmentación. También depende de aplicar parches a tiempo. En plataformas basadas en Proxmox VE, donde muchas empresas y proveedores están migrando desde VMware o desplegando nubes privadas sobre infraestructura bare-metal, automatizar la actualización de nodos puede reducir errores humanos y mejorar la disciplina operativa.
Una tarea sencilla de explicar, pero delicada de ejecutar
El flujo de ProxPatch sigue una lógica conocida por cualquier administrador de sistemas. Primero inspecciona el estado del clúster mediante herramientas nativas de Proxmox. Después identifica qué nodos tienen actualizaciones pendientes, mueve las máquinas virtuales fuera del host que se va a intervenir, aplica los parches por SSH, comprueba si es necesario reiniciar y espera a que el nodo vuelva a estar operativo antes de pasar al siguiente.
Ese proceso, hecho a mano, exige atención constante. El administrador debe comprobar el quorum, revisar la salud del clúster, asegurarse de que hay capacidad suficiente en otros nodos, migrar las cargas, lanzar las actualizaciones, decidir si el reinicio es obligatorio y verificar que todo ha vuelto a la normalidad. En un laboratorio pequeño puede ser manejable. En un clúster de varias decenas de nodos, se convierte en una operación propensa a despistes.
ProxPatch intenta hacer ese recorrido de forma predecible y auditable. La herramienta registra cada paso con marcas de tiempo y evita continuar si detecta que el clúster está degradado o que el quorum puede verse comprometido. Su filosofía prioriza la seguridad sobre la velocidad: no se trata de actualizar lo antes posible, sino de hacerlo sin romper la disponibilidad del entorno.
La herramienta utiliza componentes ya presentes en muchos despliegues Proxmox, como pvesh, qm y SSH. Según su documentación, no necesita bases de datos externas ni frameworks de orquestación. Aun así, hay que matizar la idea de “cero dependencias”: el repositorio de GitHub indica que requiere jq en la máquina desde la que se ejecuta para procesar JSON, además de acceso SSH a los nodos del clúster.
Pensado para clústeres con migración en vivo
ProxPatch tiene sentido cuando el clúster puede mover cargas de un nodo a otro sin detenerlas. Por eso su documentación recomienda un mínimo de tres nodos, quorum estable y almacenamiento compartido, como Ceph o NFS, para permitir migración en vivo. También se aconseja acceso SSH con claves, sin contraseña, entre el nodo donde se ejecuta ProxPatch y el resto de servidores.
Este punto es importante porque la herramienta no hace magia. Si un clúster no tiene capacidad suficiente para absorber las máquinas virtuales de un nodo durante el mantenimiento, si el almacenamiento no permite migración en vivo o si la red está mal diseñada, la automatización no resolverá esos problemas de base. ProxPatch puede ordenar el proceso, pero la arquitectura del clúster debe estar preparada.
La instalación se realiza desde el repositorio Debian de gyptazy. La documentación indica compatibilidad con Debian bookworm y trixie, así como con entornos Proxmox VE 8.x y 9.x. El paquete debe instalarse y ejecutarse en un único nodo del clúster, una advertencia relevante: no se debe activar el servicio proxpatch en varios nodos a la vez, porque la herramienta está pensada para actuar como un único orquestador.
Su configuración busca ser mínima. En muchos casos puede funcionar sin fichero de configuración adicional, aunque permite ajustes mediante /etc/proxpatch/config.yaml. El uso básico consiste en habilitar y arrancar el servicio systemd, a partir de lo cual comienza el proceso de actualización rolling.
Relación con ProxLB y una filosofía muy concreta
ProxPatch nació como una idea vinculada a ProxLB, otro proyecto de gyptazy orientado al balanceo de cargas en clústeres Proxmox. ProxLB actúa como una especie de planificador de recursos para distribuir máquinas virtuales entre nodos, cubriendo una carencia que algunos administradores echan en falta frente a plataformas de virtualización más tradicionales.
Según el autor, la falta de ciertos endpoints en la API de Proxmox para gestionar parcheo rolling y reinicios de nodos hizo más razonable crear una herramienta separada en lugar de introducir soluciones de compromiso dentro de ProxLB. El resultado es un proyecto más pequeño, centrado y fácil de auditar. ProxPatch puede trabajar junto a ProxLB, pero no depende de él.
Ese enfoque minimalista tiene ventajas y límites. La ventaja es que el administrador puede entender qué hace la herramienta sin enfrentarse a una plataforma pesada. El límite es que ProxPatch no pretende gestionar todo el ciclo de vida del clúster, ni reemplazar prácticas como backups, monitorización, pruebas previas, gestión de configuración, documentación de cambios o planes de rollback.
También conviene recordar que el propio repositorio de GitHub incluye un aviso claro: el proyecto se encuentra en una fase temprana y debe considerarse experimental. El autor recomienda no utilizarlo en producción sin pruebas exhaustivas en laboratorios o entornos de staging. Es una advertencia razonable para cualquier herramienta que automatiza operaciones tan sensibles como migraciones, actualizaciones y reinicios de nodos.
La aparición de ProxPatch refleja un síntoma más amplio del ecosistema Proxmox. A medida que más organizaciones lo adoptan para virtualización empresarial, cloud privado, entornos de laboratorio avanzados o alternativas a VMware, crece la necesidad de herramientas operativas que reduzcan tareas manuales. Proxmox VE ofrece una base sólida, pero muchas funciones de automatización avanzada dependen de la comunidad, scripts, APIs o proyectos externos.
En ese contexto, ProxPatch puede ocupar un hueco útil. No transforma Proxmox en una plataforma cerrada ni intenta ocultar su funcionamiento. Al contrario, apuesta por una automatización visible, basada en herramientas nativas y con una función muy concreta. Para administradores que ya hacen actualizaciones rolling de forma manual, puede convertirse en una forma de estandarizar el procedimiento y reducir variaciones entre intervenciones.
El valor real dependerá de su madurez, de cómo evolucione el proyecto y de la confianza que consiga dentro de la comunidad. En entornos críticos, cualquier herramienta de este tipo debe probarse con escenarios reales: nodos sin capacidad suficiente, migraciones fallidas, hosts que no vuelven tras el reinicio, actualizaciones de kernel, cargas con dependencias especiales y clústeres con Ceph. La automatización solo es fiable cuando también sabe detenerse a tiempo.
ProxPatch no elimina la responsabilidad del administrador. Pero sí apunta a una dirección necesaria: si Proxmox VE quiere seguir ganando terreno en entornos profesionales, las tareas repetitivas y delicadas deben ser cada vez más predecibles, auditables y fáciles de repetir. Parchar nodos sin dejar máquinas virtuales fuera de servicio es una de ellas.
Preguntas frecuentes
¿Qué es ProxPatch?
ProxPatch es una herramienta open source para automatizar actualizaciones rolling en clústeres Proxmox VE. Migra máquinas virtuales, aplica parches y reinicia nodos cuando es necesario.
¿ProxPatch evita totalmente el downtime?
Su objetivo es mantener las cargas en ejecución mediante migración en vivo, pero depende de que el clúster esté bien diseñado, tenga quorum, capacidad disponible y almacenamiento compartido.
¿Se puede usar ProxPatch en producción?
El proyecto se presenta como experimental y su propio repositorio recomienda probarlo antes en laboratorio o staging. En producción debe evaluarse con mucho cuidado.
¿Qué requisitos tiene ProxPatch?
Requiere un clúster Proxmox VE, preferiblemente con al menos tres nodos, quorum estable, almacenamiento compartido para migración en vivo, acceso SSH a los nodos y jq para procesar JSON.
