Hey folks,
I got asked to cross-post this to the Proxmox forums. You might already know me from the ProxLB project for Proxmox, BoxyBSD or some of the new Ansible modules for Proxmox and I just published a new open-source tool: ProxCLMC (Prox CPU Live Migration Checker).
Live migration is one of those features in Proxmox VE clusters that everyone relies on daily and at the same time one of the easiest ways to shoot yourself in the foot. The hidden prerequisite is CPU compatibility across all nodes, and in real-world clusters that’s rarely as clean as “just use host”. Why?
ProxCLMC inspects all nodes in a Proxmox VE cluster, analyzes their CPU capabilities, and calculates the highest possible CPU compatibility level that is supported by every node. Instead of guessing, maintaining spreadsheets, or breaking migrations at 2 a.m., you get a deterministic result you can directly use when selecting VM CPU models.
Other virtualization platforms solved this years ago with built-in mechanisms (think cluster-wide CPU compatibility enforcement). Proxmox VE doesn’t have automated detection for this yet, so admins are left comparing flags by hand. ProxCLMC fills exactly this missing piece and is tailored specifically for Proxmox environments.
If you’re running mixed hardware, planning cluster expansions, or simply want predictable live migrations without surprises, this kind of visibility makes a huge difference.
GitHub: https://github.com/gyptazy/ProxCLMC
Blog: https://gyptazy.com/proxclmc-identi...model-for-live-migration-in-proxmox-clusters/
I got asked to cross-post this to the Proxmox forums. You might already know me from the ProxLB project for Proxmox, BoxyBSD or some of the new Ansible modules for Proxmox and I just published a new open-source tool: ProxCLMC (Prox CPU Live Migration Checker).
Live migration is one of those features in Proxmox VE clusters that everyone relies on daily and at the same time one of the easiest ways to shoot yourself in the foot. The hidden prerequisite is CPU compatibility across all nodes, and in real-world clusters that’s rarely as clean as “just use host”. Why?
- Some of you might remember the thread about not using `host` type in addition to Windows systems (which perform additional mitigation checks and slow down the VM)
- Different CPU Types over hardware generations when running long-term clusters
What ProxCLMC does
ProxCLMC inspects all nodes in a Proxmox VE cluster, analyzes their CPU capabilities, and calculates the highest possible CPU compatibility level that is supported by every node. Instead of guessing, maintaining spreadsheets, or breaking migrations at 2 a.m., you get a deterministic result you can directly use when selecting VM CPU models.
Other virtualization platforms solved this years ago with built-in mechanisms (think cluster-wide CPU compatibility enforcement). Proxmox VE doesn’t have automated detection for this yet, so admins are left comparing flags by hand. ProxCLMC fills exactly this missing piece and is tailored specifically for Proxmox environments.
How it works (high level)
ProxCLMC is intentionally simple and non-invasive:- No agents, no services, no cluster changes
- Written in Rust, fully open source (GPLv3)
- Shipped as a static binary and Debian package via (my) gyptazy open-source solutions repository and/or credativ GmbH
- Being installed on a PVE node
- It parses the local corosync.conf to automatically discover all cluster nodes.
- It connects to each node via SSH and reads /proc/cpuinfo.
- In a cluster, we already have a multi-master setup and are able to connect by ssh to each node (except of quorum nodes).
- From there, it extracts CPU flags and maps them to well-defined x86-64 baselines that align with Proxmox/QEMU:
- x86-64-v1
- x86-64-v2-AES
- x86-64-v3
- x86-64-v4
- Finally, it calculates the lowest common denominator shared by all nodes – which is your maximum safe cluster CPU type for unrestricted live migration.
If you’re running mixed hardware, planning cluster expansions, or simply want predictable live migrations without surprises, this kind of visibility makes a huge difference.
Installation & Building
You can find the ready to use Debian package in the project's install chapter. This are ready to use .deb files that ship a staticly built Rust binary. If you don't trust those sources, you can also check the Github actions pipeline and directly obtain the Debian package from the Pipeline or clone the source and build your package locally.More Information
You can find more information on GitHub or in my blog post.GitHub: https://github.com/gyptazy/ProxCLMC
Blog: https://gyptazy.com/proxclmc-identi...model-for-live-migration-in-proxmox-clusters/
