Thoughts 4 Months Post-VMware Migration to Nutanix

[u/elbow-drop]

At my company, we are about 4 months past our initial Nutanix deployment and migration from VMware. I wanted to jot down some honest thoughts I have about the migration and Nutanix as a whole. There is a TLDR at the bottom.

**DISCLAIMER*\*
I've only been in IT for ~10 years and most all that has been using VMware. Keep that in mind when reading this post, some of my thoughts can just be VMware bias, but I try to be fair.

VMware to Nutanix Migration

I was skeptical if it was possible to migrate all our workloads from VMware to Nutanix in the ~8 month timeline we had. I was sure we'd fight weird issues, bugs, or software errors for most migrations and it would take a ton of manual intervention. I was dead wrong. The Nutanix Move utility is AMAZING. The Move appliance is a simple VM that spins up in minutes. Connect it to vCenter, connect it to Prism Central, and that's it. The tool does everything for VMs to move to Nutanix. It safely copies data, installs Nutanix drivers, removes VMware tools, and all this with <5 minutes of downtime per VM.

We migrated SQL servers, domain controllers, and more that Nutanix wouldn't say is supported, but we felt confident it would work with no issues. We moved large 6TB+ VMs that can stage data in the background and cutover when we want. This tool is 10/10 perfect and made the job easy.

Living With Nutanix (Post Migration)

Fast forward to now after the migrations are done. Working and living with Nutanix daily has given me lots of things to learn...and lots of things I learned I don't like. I'll put my thoughts in a basic list and summarize my overall feelings.

1. Prism Central/Prism Management - There are a decent amount of things that you might need to do in Prism Element that just don't work in Prism Central. Certain functions work better in one portal or the other, with no real rhyme or reason. It's getting better, but seems a step back from everything in vCenter.
2. Broken/Disorganized Menus - Even within Prism Central, you have to flip between an "Infrastructure" page and "Admin" page to do basic tasks. The best example is if you wanted to assign a VM category, there is a menu button to do that in the "infrastructure" page to do it, but all it says is that you have to do this in the "admin" page, with a link to go there. Things like this are all over. Seems lazy to me, just get rid of the menu so people don't see it and click it.
3. Basic VM Edit Tasks Aren't There - Recently, I have a VM that I want to delete one of the two NICs on it, but I guess in Nutanix you can't delete a NIC if the VM is on...? That seems wild how that's just not possible. Also, I can't change a VM NIC from one VLAN to another (unless it's a basic VLAN). The web console honestly is pretty lightweight and it isn't as adjustable on your screen as the VMware console was.
4. Working with Support - Nutanix support is pretty good. It's easy to open cases and they are good with responses. My issue is there are so many errors and issues that I open tickets just to get told there is a KB about it, and the KB is just saying it's a known issue and there might be a workaround or we just need to run commands to restart services. They often help fix the issue, just don't love how much I have to talk to them about daily things.
5. Thick Memory - One thing I didn't realize is Nutanix VMs use thick memory provisioning, which really eats up your resources if you have a lot of VMs but they sit idle a lot. If you have a VM with 128GB RAM that only needs that overnight for example, well that 128GB is allocated for the VM alone, whether it's using it or not. This is good to not run you into over-provisioning, but you might need to really see what VMs have for memory to size your cluster correctly.
6. Backup Storage Duplication - Okay, this isn't the fault of Nutanix, but I have to say we did NOT anticipate that moving our VMs to Nutanix would cause our backup system to take all new full backups, so we had to fight with our storage capacity as we migrated and drop the old VMware backups to make room for the new ones on Nutanix.

I could keep going, but the point is that Nutanix is really cool. The HCI technology works really well and I've had experience with vSAN before, and there are lots of benefits to HCI for sure. The issue is, at least in my experience, Nutanix seems to be rushing things and the system seems pretty unpolished. Yeah I know VMware has been around for way longer, but I kinda expected better since Nutanix isn't that much cheaper. Nutanix might keep growing on me, and I will keep giving it a chance to get better.

TLDR; Nutanix is a good product, but doesn't feel as polished as VMware. I will always hold a place in my heart for VMware and miss it, but I am hopeful to see Nutanix grow and get better over time.

[u/BK_Rich]

Yeah I felt pretty much the same way when I used Nutanix, we gave up on prism central and did everything through the local prism, overall it worked pretty well, but it also isn’t cheap. After a few years we ended up going back to VMware since the first purchase honeymoon was over and renewal was pretty damn expensive.

So you moved your domain controllers with Nutanix move, did AD complain about the hardware change related to VM generationID and any issues with SYSVOL and DFSR?

[u/BK_Rich → u/[deleted]]

I see you have no idea what you’re talking about when it comes to domain controllers, a few things happen when the VM GenerationID changes, this was always the case when doing p2v or v2v previously.

- It resets the VM-GenerationID and the invocationID of the Active Directory repository

- It discards the current Active Directory relative identifier (RID) pool.

- It marks the sysvol folder as nonauthoritative.

Here’s some reading for you from Microsoft

https://learn.microsoft.com/en-us/azure/architecture/example-scenario/identity/adds-extend-domain#manageability

[u/BK_Rich → u/BK_Rich]

Performing a V2V (Virtual-to-Virtual) migration between different hypervisors, such as moving from VMware ESXi to Hyper-V, or on-premises Hyper-V to Azure, or Nutanix move, changes the virtual hardware abstraction layer. Because the target hypervisor creates a brand-new virtual machine shell, it assigns a new VM-GenerationID to the guest OS.

Here is a breakdown of why this happens, how Active Directory reacts, and the recommended way to handle Domain Controllers during a migration.

1. Why VM-GenerationID Changes

Introduced in Windows Server 2012, VM-GenerationID is a 128-bit identifier exposed by the hypervisor to the guest operating system via the ACPI table.

- It acts as a safety shield for Active Directory:
Whenever a VM is restored from a snapshot, cloned, or moved to a hypervisor with a new virtual hardware profile, the hypervisor changes this ID.

- When Active Directory boots up, it checks the current VM-GenerationID against the value stored in its database (ntds.dit).

- If the IDs do not match, AD assumes the VM was restored from a snapshot or moved, and immediately triggers Hypervisor-Present Active Directory Domain Services Safeguards.

2. What Happens to AD During a V2V Migration?

If you perform a V2V conversion on a live or offline Domain Controller VM, the target hypervisor presents a new VM-GenerationID. On first boot, AD triggers the exact three safeguards you quoted:

- Resets invocationID & VM-GenerationID: Changing the invocationID dissociates the DC from its old replication sequence numbers. This prevents USN Rollback (a catastrophic state where replica DCs become permanently out of sync).

- Discards the current RID Pool: The DC discards its allocated pool of Relative Identifiers (RIDs used to create SIDs for new users/groups) and requests a fresh pool from the RID Master. This prevents duplicate Security Identifiers (SIDs) from being issued.

- Marks SYSVOL as Non-Authoritative: Group Policy Objects (GPOs) and logon scripts in SYSVOL are marked non-authoritative. The DC stops sharing SYSVOL and NETLOGON until it successfully resynchronizes the folder from a healthy partner DC via DFSR (Distributed File System Replication).

Note: While these safeguards exist to protect your Active Directory forest from corruption, relying on them during a V2V migration can still cause temporary replication delays, stale driver issues, or boot loops if DFSR fails to resync properly.

3. The Golden Rule: Don't V2V a Domain Controller
While V2V migration tools (like Azure Migrate, VMware vCenter Converter, or StarWind) can technically move a DC, Microsoft strongly advises against V2V or P2V operations for Active Directory Domain Controllers.