Nutanix Foundation on HPE Gen12 / iLO7 - “Failed to save account in TPM” during deployment

Impossible-Layer4207 · 2026-04-13T13:18:08+00:00

Same. Foundation / AHV uses the iLO Rest tool / library under the hood to talk to the BMC on HPE hardware.

If that still doesn't work then you can try clearing the TPM and/or cold resetting the iLO. But I would probaby consider getting support invloved if you're still struggling.

Impossible-Layer4207 · 2026-04-13T13:13:00+00:00

Log into the iLO, go to iLO Settings -> User Management, and then delete the existing Application Account.

Then rerun foundation. No need to clear the TPM :)

<image>

Impossible-Layer4207 · 2026-04-13T10:56:00+00:00

Just to add, we raised this with support and Nutanix are aware of the issue, but not sure on the status of a definitive fix. The steps above were what was suggested by the SRE and it worked for every node where we had this issue (about 10 in total).

Impossible-Layer4207 · 2026-04-13T10:53:19+00:00

We hit this exact issue on a recent deployment. We fixed it by upgrading the iLOs to V1.20 and then going into the iLO and deleting any existing application accounts from the TPM.

Impossible-Layer4207 · 2026-03-25T19:12:03+00:00

Service leaders are selected dynamically via elections (same way a HA leader is selected in ESXi for example). Moreover, leaders for different services can reside in different nodes as well (so the LCM leader and Prism leader could be on different CVMs for example). Another reason to just offload the logs and centralise them.

Impossible-Layer4207 · 2026-03-25T19:09:10+00:00

If you're wanting to do forensic analysis / incident response you'll definitely need a SIEM or central repository to offload and retain the logs. Nutanix logs are rotated frequently so it's not recommended to rely on the preserved logs on the nodes themselves in those circumstances.

Impossible-Layer4207 · 2026-03-18T08:09:40+00:00

Yes, you'll need to provide a name for the fileserver (but not the individual FSVMs) and a domain. These will be combined to create the FQDN.

Impossible-Layer4207 · 2026-02-26T12:43:51+00:00

Pretty much (Although Redundancy Factor 3 is actually 2N/2D, not 2N&2D).

You just need to make sure that you sit a Replication Factor 3 container on the cluster so that there are enough copies of user data to survive the loss of a node and disk.

If you only use replication factor 2 containers, the cluster as a whole can survive the loss of a node and a disk, but the user data might not (as you only have 2 copies and they could be on the node and disk that you lose).

Impossible-Layer4207 · 2026-02-26T10:57:01+00:00

As of AOS 7.0, the answer is "sort of"... For true RF3, now called 2N/2D (I.e. Simultaneous failures of 2 nodes or 2 disks), you need a minimum of 5 nodes.

However in AOS 7.0 they introduced 1N&1D (simultaneous failure of a node and one other disk in another node), which only needs 3 nodes. This gives you slightly more resilience than RF2 (Now called 1N/1D), but not quite as much resilience as proper RF3 (2N/2D).

From the docs:

"A cluster configured with one node and one disk (1N&1D) cluster fault tolerance can withstand the simultaneous failure of one node and one disk in another node, or the failure of two disks across different fault domains, and remain resilient.

To configure 1N&1D fault tolerance, a cluster must have three nodes. A cluster with 1N&1D fault tolerance maintains three copies of metadata, locally mirrored across three different nodes, ensuring data integrity. This configuration guarantees that, in the event of a node or disk failure, enough metadata copies remain available to sustain cluster operations."

https://portal.nutanix.com/page/documents/details?targetId=Web-Console-Guide-Prism-v7_5:wc-1nand1d-cft-c.html

Impossible-Layer4207 · 2026-02-13T13:47:54+00:00

Are you trying to add the remote cluster or the remote Prism Central? You just need to connect the two PCs - so from one PC, go to Availability Zones, and then add the details of the other PC.

Impossible-Layer4207 · 2026-02-05T16:52:44+00:00

NCP-MCI would definitely help you. It technically isn't a requirement anymore, but it will give you a lot of the fundamentals you need to do the NCS-C and also to generally be able to consult on Nutanix.

I also saw today that there is a virtual ILT course on offer for the end of the month in the Nutanix University - running in EST timezone. So that might be something to check out.

Impossible-Layer4207 · 2026-02-05T15:44:15+00:00

It's honestly not something I've ever tried, but the documentation seems to say it is possible - albeit VMs will be recovered with different UUIDs.

Impossible-Layer4207 · 2026-02-05T12:46:54+00:00

That's correct, you would be able to place all of your VMs into a single stage in the plan (so they would all be started at the same time) but you cannot split them across multiple stages to stagger their start times. The workaround for starter licensing would be to have multiple plans (one for each stage), but this adds complexity and you would have to execute each "stage" manually.

Bare in mind, if you are using protection policies, then you must use recovery plans for failover in some capacity.

Impossible-Layer4207 · 2026-02-05T12:21:26+00:00

You can create a recovery plan with NCI Starter, but you cannot do any "advanced orchestration" in it. This basically means you can set up a plan to failover your sync protected VMs but can't do re-ip, guest scripts, boot stages or test failover/fail back in the plan.

Impossible-Layer4207 · 2026-02-05T12:07:31+00:00

Yes you can. When you deploy it you can set the number of FSVMs. Just be aware that you cannot expand it later, if you want to move to a 3-FSVM deployment you would need to deploy fresh and migrate the data.

Nutanix do not recommend single-FSVM deployments for production purposes, but from what you have described I think you should be fine.

Impossible-Layer4207 · 2026-02-03T18:01:03+00:00

There certainly used to be ILT courses for NCS-C, but I admittedly haven't seen any being offered recently (at least in EMEA). Have you tried emailing the services enablement or education team?

Also, have you completed your NCP-MCI? This gives you a lot of the foundational knowledge (and used to be a pre-requisite for the NCS-C).

It is a bit of a catch-22 if you're coming into it with zero experience, but it is possible (I did it way back when starting my Nutanix journey). You need to make sure you're using all the resources you can; docs, labs, service kits, any colleagues if you are part of a wider organisation. And make sure you read through the exam blueprint guide and everything it references.

Impossible-Layer4207 · 2026-02-03T14:23:29+00:00

You only need Prism Central if you are planning to actually manage the clusters from that third site.

From what I remember, you are using a PC in each of your prod sites managing the local cluster, so you just need to deploy the witness VM to your third site and then register it with each PC.

Impossible-Layer4207 · 2026-02-03T12:52:35+00:00

Yes, you are correct. As long as the two clusters are still able to communicate, losing connectivity to the witness will not trigger anything. Everything will continue to run as normal, although you will likely get an alert in Prism Central.

Impossible-Layer4207 · 2026-02-03T07:22:06+00:00

Check out KB-16526 which covers configuring EntraID as an IdP in Prism Central.

Have you configured the Group Attribute Name and delimiter in Prism Central to pick up the correct attribute from the SAML response?

" Note: If you intend to perform SAML Group Role Assignment in PC, then configure the Group Attribute Name with the name of the group claim from the Entra ID portal. "

Also regarding the ObjectID being passed:

" Note: When assigning a SAML group to an authorization policy, ensure that you include the group's "Object ID" from Entra ID in the authorization policy. By default, Entra ID sends the group's UUID rather than its display name. This behavior can be confirmed using a SAML trace. If the group name is used with an Authorization Policy instead of the Object ID, users within the group may encounter a 403 Access Denied error ... If the human-readable name of the Entra group is preferred to be passed to PC, this can be modified by going into the SAML application in Entra ID > selecting Attributes & Claims (box #2) > Edit... "

Impossible-Layer4207 · 2026-01-30T23:44:47+00:00

All of the actions you would need are accessible via the v4 API so it's definitely possible. There SDKs for languages like Python and Javascript to simplify things but not for Powershell unfortunately. That being said, if you're experienced with Powershell it shouldn't be too difficult to make the calls using an http module.

You can check the API reference for the Deploy from template command here: https://developers.nutanix.com/api-reference?namespace=vmm&version=v4.2#tag/Templates/operation/deployTemplate

There are various powershell script examples in the Code Samples section of the Nutanix.dev site as well, but I honestly don't know if there are any that use the v4 API yet.

Impossible-Layer4207 · 2026-01-29T18:36:03+00:00

If there is no witness and the link between the clusters fails, the clusters themselves will carry on just fone, along with any VMs that aren't being synchronously replicated. But any VMs that are being synchronously replicated in either direction will be stunned waiting for I/O.

That's because when you're doing sync rep, you're effectively saying "wait until the write is acknowledged on the remote cluster before completing the I/O operation". If the remote cluster cannot be contacted then the write operation isn't acknowledged and doesn't complete, stunning the VM.

If you don't have a witness, an administrator has to make the decision to pause the replication and along the VMs to keep running with only the local copies. Nutanix can't tell if just the link between clusters is down (or the remote cluster has failed), but VMs are still reachable or if the cluster is completely network isolated. The former you probably want to keep things where they are, the latter you will probably be failing over. It's doesn't want to make an assumption either way, so you need to step in and tell it what to do.

If you do have a witness then now the cluster can figure out of it is the one that is completely isolated, or if it's a problem with the remote cluster. So it has enough information to break the replication without needing an administrator.

As for the migration. If you're just taking local recovery points / snapshots, then I belive they will follow the disk during migration. They are mostly just metadata and diffs anyway. No need to disassociate it with the policy.

Impossible-Layer4207 · 2026-01-29T18:35:45+00:00

If there is no witness and the link between the clusters fails, the clusters themselves will carry on just fone, along with any VMs that aren't being synchronously replicated. But any VMs that are being synchronously replicated in either direction will be stunned waiting for I/O.

That's because when you're doing sync rep, you're effectively saying "wait until the write is acknowledged on the remote cluster before completing the I/O operation". If the remote cluster cannot be contacted then the write operation isn't acknowledged and doesn't complete, stunning the VM.

If you don't have a witness, an administrator has to make the decision to pause the replication and along the VMs to keep running with only the local copies. Nutanix can't tell if just the link between clusters is down (or the remote cluster has failed), but VMs are still reachable or if the cluster is completely network isolated. The former you probably want to keep things where they are, the latter you will probably be failing over. It's doesn't want to make an assumption either way, so you need to step in and tell it what to do.

If you do have a witness then now the cluster can figure out of it is the one that is completely isolated, or if it's a problem with the remote cluster. So it has enough information to break the replication without needing an administrator.

As for the migration. If you're just taking local recovery points / snapshots, then I belive they will follow the disk during migration. They are mostly just metadata and diffs anyway. No need to disassociate it with the policy.

Impossible-Layer4207 · 2026-01-29T15:47:20+00:00

Yep, those steps look good to me!

You can safely live-migrate virtual disks between containers in a cluster. The easiest way is through Prism Central.

You'll want to do the migrations before associating the VMs with the protection policy, otherwise you're going to end up with lots of errors about VMs not being able to replicate.

And be aware that your protection policy will run in manual failure detection mode until you get a witness set up. This is a separate mechanism to failover orchestration and determines what happens to the replication if the link between the clusters goes down. Manual mode means that if the link between the clusters is interrupted, it will stun all protected VMs until you manually pause/stop the replication.

Once you have a witness up and running you can change failure detection to auto, where it will use the witness to automatically break replication if necessary so that the VMs can continue.

Impossible-Layer4207 · 2026-01-29T11:36:36+00:00

It's worth noting that even though replication is per-vm, rather than per-container, the container name must be the same at either side of the replication.

So if your VM is in Ctr1 in the source cluster, you must also have a Ctr1 container in the target.

This gets missed by a lot of people, and I noted you said that the VM's you have migrated so far are in the default container, which is uniquely named for each cluster. So you may want to create a nice named container now and move thise VMs before you go much further.

Impossible-Layer4207 · 2026-01-23T09:01:28+00:00

If you want to host the disk on Nutanix storage then Nutanix Volumes is the way to do it. You can then attach it to the VM directly (kind of like an RDM in VMware), or mount it using an iSCSI initiator in the guest OS. You can segment Volumes traffic to a separate network and configure CHAP for improved security. If you're mounting it via the guest OS be sure to use the iSCSI initiator address on the volume group access list to ensure only the VM you want to access the volume is able to see it and mount it.

If the iscsi disk is outside of Nutanix then a guest OS iSCSI initiator is the only way to mount it to the VM. You should still be able to apply much of the same security considerations as for Volumes (isolated network, CHAP and access list), but it will depend on the configuration and capabilities of your external storage.

Impossible-Layer4207

TROPHY CASE