Upgrading infrastructure should be a predictable, repeatable process, but occasionally, subtle architectural changes reveal conditions that have gone unnoticed. One example is the “Power cycle all the VMs in the cluster to ensure CPU compatibility” error that administrators may encounter when running clusters on Nutanix AOS 7.5 with Nutanix AHV 11.0.
This blog breaks down the causes of the error, why it appears in specific workflows, and how to remediate or work around it safely in production environments.
When Does This Error Occur?: The error typically appears during workflows that require rolling host reboots, including:
- Firmware upgrades
- AHV upgrades from 11.0 to a newer version
- Rolling host reboots
- GPU driver installation using the install_host_package script
In these cases, the workflow fails with a pre-check error instructing administrators to power-cycle all VMs in the cluster to ensure CPU compatibility.
The Root Cause: Legacy VMs and CPU Compatibility: At the core of this issue is Advanced Processor Compatibility (APC).
Clusters running AOS 7.5 and AHV 11.0 enforce stricter CPU compatibility validation during host reboot workflows. If the cluster detects legacy VMs that:
- Were originally powered on before AOS 6.8 / AHV 20230302.100173, and
- Have never been power-cycled since, and
- Do not have an APC profile assigned
The pre-check fails to prevent potential mismatches in CPU features during host transitions.
From a platform integrity standpoint, this behavior is intentional; it ensures workload safety across hosts with different CPU microcode or feature sets. However, in long-running environments, these legacy VMs can remain invisible until a disruptive workflow surfaces them.
Identifying Impacted VMs: Before remediation, you can proactively identify legacy VMs by running the command below on any CVM. This command flags VMs using legacy CPU models that are likely blocking upgrade or reboot workflows:
hostssh 'for vm in $(virsh list --name | grep -Ev "^$|CVM"); do xml=$(virsh dumpxml "$vm" | tr -d "\n"); title=$(echo "$xml" | sed -n "s/.*<title>\(.*\)<\/title>.*/\1/p"); model=$(echo "$xml" | sed -n "s/.*<model[^>]*>\(.*\)<\/model>.*/\1/p"); [[ $model =~ ^(kvm64|epyc-ibpb|EPYC.*|Opteron_G.*)$ ]] && echo "$title ($vm) --> $model"; done || true'Recommended Fix: Power-Cycle the Identified VMs: The preferred and safest remediation is simple: Power-cycle the affected VMs
A full power-off and power-on sequence forces the VM to reinitialize with a compatible CPU profile, clearing the legacy state and allowing the cluster workflow to proceed.
While this does introduce workload downtime, it is the only method that fully resolves the underlying condition.
Operational Takeaways: These approaches enable progress but do not address the root cause, so that the error may recur in future operations.
This issue highlights a few essential operational lessons:
- Legacy VM states can persist silently for years
- Stricter validation in newer platform releases is intentional, not a regression
- Pre-upgrade checks before major AOS/AHV transitions are critical
- Planned power-cycling windows should be part of lifecycle management
If you’re preparing for AOS 7.5 or AHV 11.x upgrades, running the detection command before the change window can save significant time on troubleshooting.
Summary: As Nutanix continues to evolve AHV and enforce stricter CPU compatibility, legacy configurations are being surfaced rather than ignored.
Proactively addressing them leads to cleaner upgrades, safer rolling operations, and fewer surprises during critical maintenance windows.
If you’re running long-lived clusters that have survived multiple major upgrades, now is a good time to audit VM CPU compatibility and plan accordingly.
