Repoint 6.x vCenter to a new PSC

Since a vCenter has a connection to a single PSC it’s important to understand how to move between PSC’s and deploy new ones when old ones have failed.   This article details this mobility and process.   


Once installed check for working vCenter

Then login via ssh and check which PSC is being used


Let’s repoint it to psc2.griffiths.local

cmsso-util repoint --repoint-psc psc2.griffiths.local


Now we are pointing to psc2 at site1.  In 6.0 you were able to repoint a vCenter to different site PSC’s this is no longer available in 6.5 (Yep no longer possible remember this trying to repoint can cause some really bad stuff in 6.5).    

As you can see we have repointed the psc from 1 to 2 at the same site:

So what do you do when all your PSC’s at a site have failed?  (Don’t have a single PSC at a site first off..)   Or this:

Install a new PSC pointing to a remaining site psc we will use psc3 at site2 to create a new PSC5 at site1.  In order to test this I shutdown psc1 and psc2 to simulate failures.  

So we are creating: 


After the PSC is installed it will replicate with psc3.griffiths.local only.    We then can repoint vc1 to psc5 and rebuild missing psc’s at site1.    We have to make sure PSC5 was deployed correctly first via visiting it’s webpage:

Now we can repoint the vc to psc5 at site1.  


Login to the vCenter web client to test working authentication via psc5

And it’s working


William Lam posted a script to automatically change vCenter to new PSC when a failure is detected and it’s here:


For those who don’t want to read the script it’s very simple it runs on the vCenter appliance and checks the PSC web page for a return code of 200 if it fails 3 times it switches to another PSC.   It runs as a automated task every x minutes. 


Remove an old PSC

Login to any PSC and type the following command:


cmsso-util unregister –node-pnid OLD_PSC_Name –username administrator@sso_domainname


So to remove psc1.griffiths.local I would type:


cmsso-util unregister –node-pnid psc1.griffiths.local –username administrator@vsphere.local




Setting up replication on the platform services controler

In the previous set of articles I discussed the following:

In this article I will discuss how to create the reference design from the following:


The reference replicate design should be:

So we need to add two new replication agreements.

PSC1 <->PC3

First login to psc1.griffiths.local and enable shell.  Then change the directory into /usr/lib/vmware-vmdir/bin

Look at the current agreements

Add an agreement with psc3.griffiths.local using the following command:

./vdcrepadmin -f createagreement -2 -h psc3.griffiths.local -u Administrator -H psc1.griffiths.local

You can see that we now have two agreements.   Rinse and repeat on PSC2 <=> PSC4 and we have the VVD topology.  Notice in this example that I did everything from PSC1 while referencing different PSC’s:

Now you have your replication agreements.   Looking at the vdcrepadmin command you have the following options

This essentially allows you to:

  • Show replication partners – showpartners
  • Show replication status (including latest replication number) – showpartnerstatus
  • Show all PSC’s in domain – showservers
  • Create replication agreement – createagreement
  • Remove replication agreement (don’t remove all) – removeagreement
  • Check that the PSC has done initial replication – isfirstcycledone

So there you have it health is checked via showpartnerstatus.


Installing Platform services controller

In the previous post I discussed the reference architecture and design tips for the PSC.  Here are all the posts in the series:

In this article I will setup four platform services controllers at two sites.   In my home lab I didn’t want to create complexity by using two different routed networks so I left them on the same subnet but created two sites inside the domain.   By the end of this article I will have created:

Four PSC’s at two sites.   So lets get into the install: