Skip to main content

Hello Nutanix community,

I'm working on a cluster refresh project and need some confirmation on a compatibility issue related to API changes in AOS 7.3.

 

The Details

 

  • Source Cluster (Old): AOS 6.5.6.1 (PE-Only, older G6 hardware, EOL soon).

  • Target Cluster (New): AOS 7.3.1 (New hardware, registered to Prism Central 7.3.1).

  • Migration Method: Nutanix Move (recommended tool).

  • Goal: Migrate all VMs from the old cluster to the new one and retire the old hardware.

 

The Specific Concern: KB-19356

 

I found Nutanix KB-19356 which states that the V3 VMs PUT API is deprecated at the Prism Element (PE) level in AOS 7.3, which impacts Nutanix Move's ability to apply post-migration features like NGT, CPU Passthrough, etc., when PE is used as the target.

My KB-19356 Summary:

"The V3 VMs PUT API is deprecated on PE in AOS 7.3. This affects Move's ability to configure features like NGT/CPU Passthrough post-migration if PE is used as the target."

 

My Proposed Strategy & Question

 

Since my target cluster (AOS 7.3.1) is registered to Prism Central (PC), my plan is to avoid the deprecated API entirely:

  1. Source Registration: Register the old AOS 6.5.6.1 cluster with Move using its PE IP.

  2. Target Registration: Register the new AOS 7.3.1 cluster with Move using its Prism Central (PC) IP.

Question for the community:

Can you confirm that by configuring the new PC IP as the Target Environment in Nutanix Move, I will successfully bypass the KB-19356 PE-level API deprecation and that Move will use the non-deprecated PC-scoped V3 VMs PUT API for all post-migration VM configuration?

Any gotchas or best practices for this large AOS version jump (6.5 to 7.3) using Nutanix Move would be highly appreciated!

PS: The new cluster is currently empty, so I could re-image it with an older, more compatible AOS version (like 6.10 LTS), but I'd rather stick with the latest 7.3.1 if possible! That's why I'm digging into this compatibility issue.

 

Thanks in advance!

Hello,
I haven’t tested this particular situation, but based on my experience from MOVE, the post-migration configurations will only take place after the VM is migrated, therefore they will happen on the new cluster running PC and AOS 7.3.x
My recommendation is that you create or clone a VM and test the MOVE migration before doing bulk migrations.

Since your target cluster is empty, you can also try the following migration strategy:
(it will require more work, but you will have zero downtime. Keep in mind that MOVE will shutdown and power-on the VMs): 

  • Upgrade source cluster to 6.10.x which is still compatible with the old G6 models and supports the new G8/G9 models as well.
  • Join your new nodes to the Source Cluster.
  • Decommission the old G6 nodes.
  • Upgrade your cluster to 7.3.x
  • Deploy PC 7.3.x 

This plan, ensure that you don’t have to reconfigure networks, storage and other stuff.
Note: Nutanix only supports nodes of different generations up to 3 generations (Gen X+3 → G6+3=G9), If you have G6 you can add G9’s without any problem.
 

Hello,

Thank you for the suggestion. After thinking it over, I agree that simplifying the process is the best path forward.

I've decided to re-image the nodes of the new cluster to AOS 6.10.1.11 . This will give us a fully supported and compatible source/target path for Nutanix Move. I will then proceed with the migration and all testing, and only perform the upgrade to AOS 7.3.1 once all workloads are stable and the old cluster is decommissioned.

Thanks Mate 

Terms & ConditionsAccessibility statement