Skip to main content
Question

Best practice to upgrade Metro Availability clusters with Witness

  • February 4, 2026
  • 4 replies
  • 49 views
Daniel Martinez
Forum|alt.badge.img+1

Hi

I’m looking for guidance on the best practice to upgrade a Metro Availability setup with a Witness VM and would like to confirm the recommended and supported approach.

Scenario:

  • Two AHV clusters configured with Metro Availability

  • External Witness VM providing quorum on a third site

  • Prism Central deployed (one per cluster)

Upgrade-related questions:

  1. During maintenance, is it recommended or even possible to:

    • Temporarily pause or disable the Witness service

    • Upgrade Prism Central

    • Re-enable the Witness afterward

    Or is this not required / not supported?

  2. Can Prism Central be upgraded without impacting Metro Availability, assuming both clusters remain healthy and communication between them is intact?

  3. My concern is the following scenario:

    • During a Prism Central upgrade, communication with the Witness is temporarily lost due to the reboot of the VM or the services

    • Both clusters are still communicating correctly with each other all time

    In that case, should the environment continue operating normally, or could this trigger any automatic failover / stonith / VM stun behavior?

  4. Regarding the Witness VM lifecycle:

    • How often should the Witness VM be updated?

    • Should it be upgraded every time Prism Central or AOS is upgraded?

    • Or is the Witness typically a “deploy once, rarely touch” component, updated only for major compatibility or security reasons?

 

Thanks in advance!

4 replies

K
Forum|alt.badge.img+2
  • Khoskin
  • Trendsetter
  • February 4, 2026

if both clusters can still communicate with each other then it doesn’t matter if the witness goes down.  It would only be an issue if neither cluster can communicate with each other or the witness

Daniel Martinez
Forum|alt.badge.img+1

if both clusters can still communicate with each other then it doesn’t matter if the witness goes down.  It would only be an issue if neither cluster can communicate with each other or the witness

 

Thanks! So, if I understand correctly if the Witness VM temporarily loses connectivity to one Prism Central for example during PC maintenance process, this is not an issue as long as both clusters can still communicate with each other on the background. Cause the cluster quorum doesnt depends on the Prism Central…. is that correct?

 

That said, what about the Witness VM upgrading? is it a common taks or could I keep witness VM with the same version (for example 7.5) even if both clusters are on higher AOS versions?

 

JeroenTielen
Forum|alt.badge.img+8
  • JeroenTielen
  • Vanguard
  • February 4, 2026

You can just upgrade everything will just continue working. 
 

When the witness vm is down both cluster will stil communicate with each other and so nothimg will happen. 
 

when upgrading prism central, there will aways be two pcvm’s still running so pc will not go down (you should have a scaled pc setup when having this kind of setup). 
 

when upgrading a cluster, 1 node at the time will be upgraded. Meaning the cluster stays up and running. 
 

short answer: all keeps running, just run you upgrades ;). 

Nutanix NTC 2022+2023+2024+2025+2026 || Nutanix NUG Champion || Nutanix Certified Instructor
    Daniel Martinez
    Forum|alt.badge.img+1

    Thaks for answering!

    So in summary, you can upgrade a Prism Central or the Witness VM without afecting the service as long as the rest of the enviroment keeps its communications alive.

    Then as a last questions, what about the Witness VM upgrading? is it an element that you should upgrade frequently or could you keep witness VM with the same version (for example 7.5) even if both clusters are on higher AOS versions?

    Im asking this question cause the customer third site (where witness VM will be hosted) is not directly managed by the customer and will no be easy for him to upgrade it.

    Terms & ConditionsAccessibility statement