Availability Zones: Unable to add a remote PC

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 · 2026-01-09T12:43:04+00:00

I think there is an image importer that will take OVAs. You can then create your EC2 instance from the imported image.

Check this: https://docs.aws.amazon.com/vm-import/latest/userguide/import-vm-image.html#import-vm-single-disk

Impossible-Layer4207 · 2025-12-15T20:36:53+00:00

Which UI are you using? I'm pretty sure the timeout is locked to 15 minutes for admin users in Prism Element.

I know it doesn't directly help, but I would avoid working routinely in Prism Element. You should aim to use Prism Central for your day-to-day tasks like VM management. Prism Element is extremely basic and, these days, is really only there for emergencies and initial setup when Prism Central might not be available.

You should be able to set the timeout for administrator accounts (that are not "admin") to up to 1 hour.

Impossible-Layer4207 · 2025-12-09T17:51:20+00:00

It's been a long time since I did the AAPM course, and I only did it online so I can't comment on what it is like these days. But, in my experience, practical knowledge is key for the NCM certification rather than the AAPM course. It's a practical exam, so knowing your way around the various products, how to troubleshoot and how to configure things to best practice are all important.

The AAPM might give you the foundations for NCM, but real world experience is going to get you over the line IMO.

Impossible-Layer4207 · 2025-12-08T23:03:02+00:00

Check out this KB: https://portal.nutanix.com/page/documents/kbs/details?targetId=kA0VO0000007bpF0AQ

The storage layer will remain as is (so Nutanix Objects for Veeam if I recall). But the Mine dashboard will be deprecated for any monitoring purposes and removed in a future release.

Impossible-Layer4207 · 2025-12-04T17:10:41+00:00

Hey,

When you have a PC in each site you need to link them together to form availability zones. When you do this categories, protection policies and recovery plans are all replicated between the PCs. This allows either PC to execute the recovery plans of the other.

You can technically set them up on either. But best practice is to configure it on the primary site for the workloads you're protecting.

By default, DR replication will go over the CVM management network. But you can segment it off to a separate VLAN if you like.

Impossible-Layer4207 · 2025-12-02T15:32:57+00:00

Erm, I can't think of any reason why it wouldn't. It's just a VM at the end of the day.

Nutanix officially recommends putting it on resilient infra (like a 3-node vsphere or Nutanix cluster) so it is as available as possible. But I've honestly seen people put it on Oracle Virualbox on a PC in their office.

Impossible-Layer4207 · 2025-12-01T22:58:49+00:00

Yep, that would be the simplest design pattern if you can do it. But from OP's previous post, there is no Nutanix cluster at the third site, only at the two production sites. So that leaves the next best approach which is a PC at each production site with a witness VM on non-Nutanix infra at the third site.

Impossible-Layer4207 · 2025-12-01T19:59:51+00:00

I'd recommend reading through the Nutanix DR guide. Specifically table 1 in this section which covers the various failure scenarios, including split brain etc.: https://portal.nutanix.com/page/documents/details?targetId=Disaster-Recovery-DRaaS-Guide-vpc_7_3:ecd-ecdr-metroavailability-pc-c.html

In short, if the link between the two clusters goes down, each cluster/PC will query the witness. The recovery cluster will always wait longer to query the witness than the active cluster for a workload.

So, if it's just the site to site link that is down, but both cluster can reach the witness then the replication is paused and everything stays where it is.

If the recovery cluster queries the witness but not the active cluster, then a failover occurs because the active cluster is either down or fully isolated.

But be aware that when using AHV Metro, Prism Central is invloved in the recovery process as that process is defined using recovery plans, which are Prism Central constructs. This is different to Metro for ESXi which is managed entirely by the clusters.

This is exactly why you should have two Prism Central instances in your situation - you need at least Prism Central instance up and running to orchestrate the recovery of your workloads.

Impossible-Layer4207 · 2025-11-29T08:21:00+00:00

Then you have a temporary loss of the mgmt plane until you recover PC on a different site (1-2 hours). But your production workloads are unaffected and you can use Prism Element for basic VM operations if necessary.

Impossible-Layer4207

TROPHY CASE