WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / vSphere 6.0 / Maximum number of vCenter Servers per Single Sign-On (SSO) Domain

Maximum number of vCenter Servers per Single Sign-On (SSO) Domain

03.29.2017 by William Lam // 9 Comments

This particular question and its variations have been raised quite a bit lately by our field and customers. For me, this was an opportunity to see if we can provide some additional clarification and help explain some of the nuances that may have been causing some of the confusion around the supported maximums for both vCenter Server and the Platform Services Controller (PSC).

In the vSphere 6.5 Configuration Maximum, there are three specific maximums that helps us answer our question on the maximum number of vCenter Servers per vCenter Single Sign-On (SSO) Domain. I will go through each of the maximums and provide some additional context that will help us derive the answer to our question.

The first is the "Linked vCenter Servers" which defines the maximum number of vCenter Servers that can be supported in an Enhanced Linked Mode (ELM) configuration. What is interesting about this particular maximum is that it actually answers the majority of our question. By definition, an ELM consists of a single SSO Domain. This then means that you can only have a maximum of 10 vCenter Servers per SSO Domain.

vCenter Server Maximum

Configuration Maximum
Linked vCenter Servers (w/External PSC) 10
Linked vCenter Servers (w/Embedded PSC) 15

Note: As of vSphere 6.7, you can have up to 15 Embedded VCSA's within an ELM.

The second is the "Maximum PSCs per vSphere Domain" which defines the maximum number of PSC's that can be part of a single SSO Domain, pretty straight forward. The third is the "Maximum PSCs per site behind a load balancer" which just adds an additional constraint when using a load balancer with your PSCs.

Platform Services Controller Maximum

Configuration Maximum
Maximum PSCs per vSphere Domain 10
Maximum PSCs per site behind a load balancer 4

After going through the three maximums, we can conclude that the maximum number of supported vCenter Servers per SSO Domain is 10.

Having said that, what does this actually look like when we take into considerations the PSC maximums and the different deployment topologies and configurations that we support? I believe this is where additional confusion arises as this is not something we have historically gone into great detail. What this means is that what is supported or possible is left up for interpretation which is not a good thing, especially when it comes to configuration maximums.

To better help illustrate the possible configurations, I have created several diagrams outlining some the vCenter Servers with an External PSC scenarios.

This first diagram illustrates one method in which you can reach the absolute maximum number of vCenter Servers and PSCs that can be configured within a single SSO Domain. The reason I say one method is that we know the maximum number of vCenter Server per SSO Domain is 10 and the maximum number of PSCs per SSO Domain is 10, so you can have other permutations as long as you do not exceed the maximums listed above. For example, I can have 10xVC + 10xPSC, 1xVC + 10xPSC, 2xVC + 9xPSC, etc.

vCenter Servers w/Load Balanced PSC

If you are using a load balancer with your PSCs, then you can have up to a maximum of 4 PSCs within an SSO Site and up to 10 vCenter Servers all within a single SSO Domain. The diagram below illustrates one method to reach the absolute maximum in terms of the number of vCenter Servers and PSCs. You can also have other permutations as long as you do not exceed the maximums listed above. For example, I can have 2xPSCs being load balanced connected to 2xVCs and have up to 5 of those instances running within a single SSO Domain.

vCenter Server High Availability (VCHA)

If you are taking advantage of the new vCenter Server High Availability (VCHA) feature which was introduced in vSphere 6.5, the maximum is actually exactly the same as the diagram above. There have been a few questions on whether a VCHA setup counts as 1 or two vCenter Servers and the answer is just 1. The reason is that there is only ever one "Active" vCenter Server communicating with the PSC. The diagram below illustrates one method to reach the absolute maximum in terms of the number of vCenter Servers and PSCs.


Hopefully after going through this article, it is now clear on what are the supported maximums for both the vCenter Server and Platform Services Controller within a single SSO Domain. Lastly, the maximums listed in the vSphere Configuration Maximums are officially tested and supported limits based on the available internal resources and customer demand. Exceeding these limits can potentially have a negative impact to your environment as well as from a support standpoint. Always consult the documentation and ensure you are within all supported limits.

More from my site

  • Generating vCenter Server & Platform Services Controller deployment topology diagrams
  • How to automatically repoint & failover VCSA to another replicated Platform Services Controller (PSC)?
  • Which Platform Services Controller (PSC) is my vCenter Server pointing to?
  • vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations
  • Ultimate automation guide to deploying VCSA 6.0 Part 3: Replicated Platform Service Controller Node

Categories // vSphere 6.0, vSphere 6.5 Tags // Enhanced Linked Mode, platform service controller, psc, sso, vCenter Server, VCHA, vSphere 6.0, vSphere 6.5

Comments

  1. *protectedJoe Cooper says

    03/29/2017 at 8:48 am

    Thank you so much for illustrating this so beautifully, William. Can I throw a bit more complexity into the situation? What happens if you have multiple sites? Consider vCenter HA failover where the passive vCenter is in a different physical location. Which PSC site would that vCenter point to? Can I have a vCenter in one site bound to a PSC in a different site for vCenter HA purposes?

    Reply
    • William Lam says

      03/29/2017 at 9:53 am

      You'll want to co-locate PSC's within the same SSO Site, especially as we improve PSC HA in the future, this will be important as that'll be the boundary. Also, keep in mind that the further away your PSC is from your VC, login times and other operations can be delayed, so keep that in mind.

      Reply
  2. *protectedJoe Cooper says

    03/29/2017 at 11:34 am

    So it sounds like vCenter HA passive nodes should stick within the same SSO Site as the active vCenter. You note able latency at login is well taken. - Thanks!

    Reply
  3. *protectedJoe Cooper says

    03/29/2017 at 11:35 am

    Wow... I can't type today. So it sounds like vCenter HA passive nodes should stick within the same SSO Site as the active vCenter. Your note about latency at login is well taken. – Thanks!

    Reply
  4. *protectedIvana Brajko says

    03/30/2017 at 2:55 am

    This is an interesting article which sheds some light on a huge change between 6.0 and 6.5 version.

    In Configuration Maximums for 6.0, the values mentioned above were pretty much the same or really close, we could have a maximum of 10 Linked vCenters and 8 PSCs per SSO domain.

    However, a topology like the one presented wasn't possible in our wildest dreams. This was due to another constraint we had which was: "Maximum number of VMware Solutions in a vSphere Domain = 10". This effectively meant that you could have your maximum of 8 PSCs but only 2 vCenters due to this constraint. Or 5 PSCs and 5 vCenters and so on.

    I wonder what has changed in vmdir operations in 6.5 to allow for such a big change. Could it be that the constraint was there for 6.0 only for the time being until the PSCs and this type of architecture proved stable enough in production environments.

    Reply
  5. *protectedJeff Johnson says

    04/04/2017 at 5:11 am

    We run vcenter HA with embedded PSC. However we want to move to and enhanced link mode model so we need to convert to external psc. However we have no load balancer at some sites and the documentation states a load balancer is required for the external psc if you are in vcenter HA mode. Is that really a just a suggestion? If a psc fails why couldn't a manual repoint be done to vcenter whether it was standalone or in HA mode?

    Reply
    • William Lam says

      04/04/2017 at 6:48 am

      If you have VCSA w/External PSC, you will need an LB, its not optional. If you don't have an LB, the issue is that 2nd/3rd party solutions which integrate w/VCHA will not be aware of the failover and those solutions will not work. This is something that's being worked on and hopefully in the near future, an LB will not be required. For the time being, you will need an LB.

      Reply
      • *protectedJeff Johnson says

        04/04/2017 at 7:20 am

        Ok that makes sense. And I assume you mean things like SRM, which we may be purchasing. Good to know.

        Reply
  6. *protectedGuillermo Barton says

    09/13/2018 at 10:24 am

    William, is there an update to this thread now that 6.7 is out?

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...