En cualquier clúster de Proxmox VE, la migración en caliente (live migration) es una de esas funciones que, cuando todo va bien, parece magia: una máquina virtual salta de un nodo a otro con apenas impacto para el usuario. El problema es que, cuando falla, no suele hacerlo “a medias”: lo hace con mensajes crípticos, prisas, y la incómoda sensación de que el clúster está más “mezclado” de lo que se quería admitir.
En la práctica, uno de los detonantes más comunes de esas migraciones fallidas es un requisito que se subestima a menudo: la compatibilidad de CPU entre nodos. Los clústeres reales rara vez son un conjunto de servidores clonados. Se montan en fases, se amplían con nuevas generaciones de procesadores, se combinan equipos comprados en momentos distintos y, con ello, aparecen diferencias de flags e instrucciones soportadas. En ese contexto, elegir el “CPU type” adecuado para las VMs acaba siendo un ejercicio de experiencia, hojas de cálculo y, a veces, ensayo y error.
Ahí es donde entra ProxCLMC (Prox CPU Live Migration Checker), un proyecto open source pensado precisamente para cerrar ese hueco operativo: determinar de forma automática el mayor nivel de compatibilidad de CPU que comparten todos los nodos y, por tanto, el tipo de CPU más alto que puede configurarse en las VMs sin romper la migración en caliente.
El problema: la migración en caliente depende del “mínimo común” de CPU
Proxmox permite configurar distintos modelos de CPU para una VM. En entornos homogéneos, el “host” puede ser una elección cómoda: exponer todas las capacidades del procesador al invitado. Pero en clústeres heterogéneos, esa comodidad se convierte en riesgo, porque el invitado puede terminar “viendo” instrucciones que otro nodo no soporta. Resultado: migración fallida o comportamientos difíciles de predecir.
El propio enfoque de ProxCLMC parte de una realidad que muchos administradores ya han vivido: en clústeres con hardware mixto, los desajustes de CPU se traducen en migraciones en caliente fallidas, inestabilidad del comportamiento de la VM o incluso degradaciones importantes de rendimiento, con menciones específicas a casos en Windows cuando se usa un tipo de CPU inapropiado.
El asunto no es exclusivo de Proxmox. En ecosistemas empresariales se ha abordado desde hace años con mecanismos de “baseline” a nivel clúster. VMware, por ejemplo, popularizó EVC (Enhanced vMotion Compatibility), que fuerza una línea base de CPU común para que vMotion no rompa al moverse entre hosts de generaciones diferentes. La documentación de Broadcom/VMware lo explica como la creación de una baseline “del procesador menos avanzado” soportado por todos los hosts, enmascarando características más nuevas para mantener la compatibilidad.
Qué es ProxCLMC y qué aporta a Proxmox VE
ProxCLMC se presenta como una utilidad ligera para contestar de forma determinista a una pregunta muy concreta:
“¿Qué tipo de CPU puedo usar con seguridad en todas las VMs de este clúster, garantizando live migrations sin sorpresas?”
Su lógica es sencilla, pero muy práctica: analiza las capacidades reales de CPU de todos los nodos y calcula el nivel máximo común que todos comparten. En lugar de apoyarse en suposiciones o comparaciones manuales de flags, entrega un resultado claro, repetible y fácil de aplicar como “CPU model” para VMs.
El proyecto está publicado como software libre (GPLv3) y está escrito en Rust, distribuido como binario estático y empaquetado para entornos Debian/Proxmox.
Cómo funciona: del corosync.conf al “CPU type” del clúster
El flujo de trabajo de ProxCLMC busca integrarse sin agentes ni servicios adicionales:
- Descubre el clúster automáticamente leyendo el
corosync.conflocal del nodo donde se ejecuta, para obtener la lista real de miembros. - Conecta por SSH a cada nodo y lee la información de CPU desde
/proc/cpuinfo, que refleja los flags expuestos por el kernel. - Mapea las capacidades a baselines x86-64 alineadas con modelos soportados por Proxmox/QEMU. En el proyecto se citan explícitamente:
x86-64-v1x86-64-v2-AESx86-64-v3x86-64-v4
- Calcula el “mínimo común” entre todos los nodos y lo muestra como tipo de CPU recomendado para el clúster.
El resultado es el tipo más alto que sigue siendo compatible en todo el clúster. En un ejemplo típico, aunque haya un nodo capaz de x86-64-v4, si otros dos se quedan en x86-64-v3, el clúster se consolida en x86-64-v3 para que cualquier VM pueda migrar libremente.
Para automatización, incluye un modo muy orientado a pipelines: --list-only, que devuelve únicamente el “CPU type” recomendado en stdout, ideal para integrarlo en scripts o checks antes de cambios en producción.
Instalación: repositorio APT o paquete .deb
ProxCLMC se distribuye a través del repositorio de gyptazy (también usado para ProxLB) y puede instalarse con APT. El proyecto detalla el alta del repositorio y la instalación del paquete proxclmc.
Como alternativa, también se puede descargar un .deb desde el CDN del autor y hacer la instalación manual con dpkg.
A nivel de requisitos, el planteamiento es directo: clúster de Proxmox VE, conectividad entre nodos y autenticación SSH entre miembros (recomendable sin contraseña para ejecución fluida).
Qué cambia en la operativa diaria
La aportación real de ProxCLMC no es “más rendimiento” por sí misma, sino menos incertidumbre:
- Antes de añadir un nodo nuevo, permite comprobar si ese hardware “baja” el baseline del clúster.
- Tras una ampliación, evita descubrir incompatibilidades el día que más duele: cuando hay que mover carga por mantenimiento.
- Estandariza decisiones: deja menos espacio a interpretaciones distintas entre operadores.
- Reduce el coste de la heterogeneidad: aceptar que el clúster no es uniforme no debería implicar renunciar a migraciones fiables.
Eso sí, conviene recordar el matiz importante: ProxCLMC no configura Proxmox automáticamente. Ofrece el baseline recomendado; el siguiente paso sigue siendo decisión del administrador: aplicar ese tipo de CPU en las VMs (o en plantillas), validar cargas sensibles y documentar el criterio.
Un ejemplo de “feature empresarial” nacida desde la comunidad
El propio autor plantea ProxCLMC como una pieza que faltaba en el ecosistema: una guía automática de compatibilidad de CPU a nivel clúster, comparable en concepto a lo que otras plataformas integran desde hace años.
Y llega además con cadencia de versiones reciente: en el repositorio público aparecen etiquetas como v1.2.0 (6 de enero de 2026).
En un momento en el que Proxmox VE se consolida como alternativa muy seria en virtualización, herramientas así demuestran algo que suele olvidarse: cuando una necesidad es real y recurrente, el open source tiende a convertirla en producto… aunque sea en forma de binario pequeño y directo.
Preguntas frecuentes
¿Qué problema resuelve ProxCLMC exactamente en un clúster de Proxmox VE?
Ayuda a evitar migraciones en caliente fallidas por incompatibilidades de CPU, calculando el tipo de CPU más alto que soportan todos los nodos y que, por tanto, es seguro para VMs que necesiten migrar entre cualquiera de ellos.
¿Cada cuánto conviene ejecutar ProxCLMC?
Tiene más sentido ejecutarlo cuando cambia el clúster: al añadir o reemplazar nodos, tras actualizaciones relevantes de hardware, o antes de planificar mantenimientos que dependan de migraciones masivas.
¿ProxCLMC mejora el rendimiento de las VMs?
No “acelera” por sí mismo. Su valor es reducir errores y comportamientos impredecibles. El baseline elegido puede implicar renunciar a ciertas instrucciones nuevas en nodos más modernos, a cambio de estabilidad y movilidad.
¿Funciona si el clúster tiene nodos con CPUs muy distintas?
Funciona en el sentido de que calculará el mínimo común denominador. Si las diferencias son grandes, el baseline resultante puede ser conservador. Aun así, el dato es útil: permite decidir si compensa segmentar cargas, crear pools por hardware o replantear el diseño del clúster.
Fuente: Repositorio y documentación de ProxCLMC
