In my last blog post, we discussed some of the new features and capabilities found in vCenter Server 6.0 such as how you can quickly and easily update the vCenter Server Appliance 6.0 to Update 1.
Now, it’s time to focus our attention on a two key enhancements found in vCenter Server 6.0 Update 1 – both the appliance and Windows-based form factors:
- Reconfigure – You can now reconfigure an embedded deployment node to an external deployment model, also known as MxN.
- Repoint – Simplified repointing of a management node in an external deployment model from one external Platform Services Controller to another external Platform Services Controller.
Why is this important?
The reconfiguration enhancement enables you to take an existing embedded deployment and transition it to a more optimal external deployment model – MxN. There is also the simplified ability to repoint a management node to another Platform Services Controller which enables you to quickly recover from an external Platform Services Controller failure and to distribute load to alternate nodes that are in the same SSO domain.
Before moving forward with either the reconfigure or repoint operations, there is a key set of requirements that you need to meet.
Reconfiguration Requirements
- The vCenter Server instance must be an embedded deployment model.
- The target Platform Services Controller must be a replication partner of the existing embedded Platform Services Controller in the same SSO Domain.
Note: In vCenter Server 6.0 Update 1, we only support a single transition from embedded deployment to a external deployment (MxN) model for per SSO domain. See the Known Issues section of the Release Notes for additional details.
Repointing Requirements
- The vCenter Server instance must be an external deployment model.
- The target Platform Services Controller must be a replication partner of the existing external Platform Services Controller in the same SSO Domain.
We’ve introduced an update to cmsso-util in vCenter Server 6.0 Update 1. This utility can be found in:
- VCSA: /bin/cmsso-util
- Windows: <Drive>:Program FilesVMwarevCenter Serverbincmsso-util
This utility automates the entire process by passing the new required namespace (either reconfigure or repoint) and its arguments. For example, with the VCSA, the namespaces would be:
- VCSA: /bin/cmsso-util reconfigure
- VCSA: /bin/cmsso-util repoint
Okay, so, how do we do it? Well, let’s see both namespace options in action in the vCenter Server Appliance (VCSA). Note that the cmsso-util namespaces and arguments are the same for a vCenter Server 6.0 Update 1 instance installed on Windows.
Reconfigure an Embedded Deployment to an External Deployment
Recall that before you can reconfigure an embedded deployment to an external deployment you must first deploy an external Platform Services Controller that is a replication partner to the embedded Platform Services Controller. Thus, these instances belong to the same SSO Domain (e.g. vsphere.local).
In this example, I have an existing vCenter Server Appliance 6.0 Update 1 embedded deployment on the system mgmt01vc01.demo.vmware.com. Note that when logging into the SSH session the type is also indicated as “vCenter Server with an embedded Platform Services Controller”.
In order to reconfigure the deployment model on the appliance, we must first enable BASH and launch the shell in the appliance by running:
Command> shell.set –enabled True
Command> shell
Now we’re ready to reconfigure the appliance using the cmsso-util by passing the reconfigure namespace and its required arguments.
cmsso-util reconfigure –repoint-psc <FQDN-of-External-PSC> –username <SSO-DomainAdmin> –domain-name <SSO-Domain> –passwd <SSO-DomainAdmin-Password>
If the external Platform Services Controller is not using the default HTTPs port (443) we’d specify the custom HTTPs port as an argument as follows.
cmsso-util reconfigure –repoint-psc <FQDN-of-External-PSC> –dc-port <Port> –username <SSO-DomainAdmin> –domain-name <SSO-Domain> –passwd <SSO-DomainAdmin-Password>
Note: All required parameters must be provided as command line arguments.
-h, –help: Help and Exit
–repoint-psc : Fully Qualified Domain Name of Platform Services Controller
–username : SSO Domain Administrator. Required for Reconfiguring an Embedded Deployment to External Deployment
–passwd : SSO Domain Administrator Password. Required for Reconfiguring an Embedded Deployment to External Deployment.
–domain-name : Required for Reconfiguring an Embedded Deployment to External Deployment.
–dc-port: HTTPs Port of External Platform Services Controller – If Not Set, Defaults to 443
Now, we’ll initialize the cmsso-util with the reconfigure namespace and arguments to repoint the system to our externally replicated Platform Services Controller – mgmt01psc01.demo.vmware.com. Then we’ll demote the embedded deployment to a management node.
cmsso-util reconfigure –repoint-psc “mgmt01psc01.demo.vmware.com” –username “Administrator” –domain-name “vsphere.local” –passwd “VMware1!”
When the reconfigure namespace is used it automates the following tasks to transition an embedded deployment to an external deployment topology.
- Stops all non-core services
- Sets the dc-name option as the external Platform Services Controller
- Sets the dc-port if HTTPs is running on a custom port
- Changes the Deployment Type in the registry: embedded to external
- Removes the local Platform Services Controller from federated SSO domain.
- Stop all services
- Changes the Deployment Node Type to start only services for a Management Node
- Update the service dependencies
- Starts the vmafdd required to join the external Platform Services Controller
- Disables services and registration for the embedded Platform Services Controller (Appliance)
Runs MSI uninstall scripts to remove and unregister services for the embedded Platform Services Controller (Windows) - Restarts all services
Here we see the execution of the reconfiguration option followed by status messages for each stage of the automation process. Once completed, the instance is reconfigured and repointed to the external Platform Services Controller that we specified in the arguments – mgmt01psc01.demo.vmware.com.
Let’s take a moment to validate the reconfiguration from here within the SSH session by running:
/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location –server-name localhost
The results indicate that this vCenter Server management node has been repointed to our specified external Platform Services Controller. Alternatively, you can open the vSphere Web Client and search for the config.vpxd.sso.admin.uri in the Advanced Settings of the vCenter Server instance. Here we can see the same information that we returned in the vmafd-cli command.
Recall that during the automation process, cmsso-util changes the deployment type from embedded to external, removed the local Platform Services Controller from the federated SSO domain, and then changes the deployment node type to only start the services for the management node. We can quickly verify that this change is completed by logging into another SSH session to our VCSA – mgmt01vc01.sddc.local. Here we see that the Type is now shown as “vCenter Server with an external Platform Services Controller.”
Success! We’ve successfully reconfigured a vCenter Server 6.0 Update 1 deployment model with an embedded Platform Services Controller to an external deployment model.
Repoint an External Deployment to an Alternate Platform Services Controller in the Same Site (Intra-Site)
Now, what if we wanted to repoint this vCenter Server instance to use an alternate external Platform Services Controller in the same site? For example, to quickly recover from an external platform services controller failure and/or distribute load to alternate nodes that are in the same SSO domain.
While we could do this in vCenter Server 6.0 following KB 2113917, we’ve made it easier in 6.0 Update 1 with a bit of automation. The repoint namespace just wraps the service-control and vmafd-cli command into a nice little package with some validation logic – so again, it is what we are already doing in KB 2113917, but automated for you.
Let’s return to the BASH shell in the appliance first and see how it’s done.
Simply repoint the appliance to an alternate Platform Services Controller in the same SSO domain using the cmsso-util and passing the repoint namespace with its required arguments.
cmsso-util repoint –repoint-psc <FQDN-of-External-PSC>
If the external Platform Services Controller is not using the default HTTPs port (443) then specify the custom port HTTPs port:
cmsso-util repoint –repoint-psc <FQDN-of-External-PSC> –dc-port <Port>
Note: All required parameters must provide as command line arguments.
-h, –help : Help and Exit
–repoint-psc : Fully Qualified Domain Name of Platform Services Controller
–dc-port : HTTPs Port of External Platform Services Controller – If Not Set, Defaults to 443
Here we’ll initialize the cmsso-util with the repoint namespace and arguments to repoint the system to an alternate Platform Services Controller – mgmt01psc02.demo.vmware.com – which is an existing replication partner with our existing Platform Services Controller – mgmt01psc01.demo.vmware.com – in the vsphere.local SSO domain.
cmsso-util repoint –repoint-psc “mgmt01psc02.demo.vmware.com”
When the repoint namespace is used it automates the following tasks to repoint an external deployment to another external platform services controller that is a replication partner.
- Sets the dc-name as the new external Platform Services Controller
- Sets the dc-port if HTTPs is running on a custom port
- Stops all services
- Starts all services
Below we see the execution of the repoint operation followed by status messages for each stage of the process. Once it’s completed, the instance is repointed to an alternate external Platform Services Controller that we specified in the arguments – mgmt01psc02.demo.vmware.com.
Once again, let’s validate the reconfiguration from here within the SSH session by running:
/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location –server-name localhost
The results vmafd-cli command indicate that this vCenter Server has been repointed to the alternate external Platform Services Controller.
Repoint an External Deployment to an Alternate Platform Services Controller in Another Site (Inter-Site)
The process I showed above was for repointing a vCenter Server to an an alternate external Platform Services Controller in the same same (aka. intra-site) but you can also move vCenter Server between SSO domain sites (aka. inter-site) in vCenter Server 6.0 Update 1.
When the vCenter Server is installed, it creates services registrations that it issues to start the vCenter Server services. These service registrations are written to a specific site of the Platform Services Controller that was used during install time. So. when you attempt to move the vCenter Server’s affinity to a new Platform Services Controller in a new site, the vCenter Server will fail to start its services due to not having the proper service registrations in the new site.
Refer to KB 2131191 and download the cmsso-util in this article to facilitate the movement of the services registrations.
For example, if mgmt01psc02.demo.vmware.com was in a different site from my original Platform Services Controller, mgmt01psc01.demo.vmware.com, I would run the following commands on the vCenter Server to move to an alternate Platform Services Controller in a new site AND move its service registrations.
cmsso-util repoint –repoint-psc “mgmt01psc02.demo.vmware.com”
cmsso-util move-services (Prompted Option)
If using the prompts, simply provide the following to the utility when it asks:
Domain:
Username:
Password:
PSC Node:
Old Site Name:
New Site Name:
For example:
Domain: vsphere.local
Username: Administrator
Password: VMware1!
PSC Node: mgmt01psc02.demo.vmware.com
Old Site Name: PaloAlto-CA
New Site Name: LasVegas-NV
Of course, you can also pass the arguments to the move-services namespace:
cmsso-util move-services –psc-node <FQDN-of-PSC-in-New-Site> –domain-name <SSO-DomainName> –username <SSO-Administrator> –passwd<SSO-Administrator-Password> –oldsite-name <Original-SSO-Site-Name> –newsite-name<New-SSO-Site-Name>
For example:
cmsso-util move-services –psc-node mgmt01psc02.demo.vmware.com –domain-name vsphere.local –username Administrator –passwd VMware1! –oldsite-name PaloAlto-CA –newsite-name LasVega-NV
And there you have it. These new enhancements in vCenter Server 6.0 Update 1 now empower you to reconfigure an existing embedded deployment and transition it to an external deployment model. By using a simplified method when repointing a management node to another Platform Services Controller you are enabled to transition a deployment model architecture to an external deployment model and quickly recover from an external Platform Services Controller failure and/or distribute load to alternate nodes that are in the same SSO domain, both in the same site or across sites.
ganesh
Hi,
I tired re-pointing command in two different setup..
1. from the embedded to the external with same domain .
2. From the external PSC – another PSC which is in enhanced linked mode.
Re-pointing is failing with the below error , it is failing while it starting the inventory service..
Stdout = Starting VMware Inventory Service…
Waiting for VMware Inventory Service…………………………………………………………………………
WARNING: VMware Inventory Service may have failed to start.
Stderr =
2015-09-23T18:07:58.521Z {
“resolution”: null,
“detail”: [
{
“args”: [
“Command: [‘/sbin/service’, u’vmware-invsvc’, ‘start’]nStderr: ”
],
“id”: “install.ciscommon.command.errinvoke”,
“localized”: “An error occurred while invoking external command : ‘Command: [‘/sbin/service’, u’vmware-invsvc’, ‘start’]nStderr: ‘”,
“translatable”: “An error occurred while invoking external command : ‘%(0)s'”
}
],
“componentKey”: null,
“problemId”: null
}
ERROR:root:Unable to start service vmware-invsvc, Exception: {
“resolution”: null,
“detail”: [
{
“args”: [
“vmware-invsvc”
],
“id”: “install.ciscommon.service.failstart”,
“localized”: “An error occurred while starting service ‘vmware-invsvc'”,
“translatable”: “An error occurred while starting service ‘%(0)s'”
}
],
“componentKey”: null,
“problemId”: null
}
Unable to start service vmware-invsvc, Exception: {
“resolution”: null,
“detail”: [
{
“args”: [
“vmware-invsvc”
],
“id”: “install.ciscommon.service.failstart”,
“localized”: “An error occurred while starting service ‘vmware-invsvc'”,
“translatable”: “An error occurred while starting service ‘%(0)s'”
}
],
“componentKey”: null,
“problemId”: null
}
Ryan Johnson
re #1 (I tried re-pointing command …) from the embedded to the external with same domain.
The requirement for repointing mentioned in the post are:
– The vCenter Server instance must be an external deployment model.
– The target Platform Services Controller must be a replication partner of the existing external Platform Services Controller in the same SSO Domain.
Therefore, you’d need to reconfigure the embedded node, not repoint it. Setup a PSC that is a replication partner to the embedded deployment’s SSO domain first. Next, run the cmsso-util reconfigure namespace with the required arguments. The utility will repoint the to the external PSC and then reconfigure the embedded node to an MxN deployment model.
re #2 (I tried re-pointing command …) from the external PSC – another PSC which is in enhanced linked mode.
Are the nodes in the same SSO domain (assuming since ELM?) Are they in the same site?
Anders O
Hi. Thanks for a great blog post about repointing manually as a failover maneuver, which is exactly what we’re researching for our new vCenter design.
What we can’t really wrap our heads around when doing a site-internal repoint is the fact that each PSC seems to be its own unique VMCA instead of all certificate information being shared/replicated between them. This means that after we repoint a vCenter Server to a new PSC, all of its issued certificates (to ESXi hosts as well as machines/solutions) will come from another root CA.
We think this will be harmless as long as we distribute all of the public root CA certificates (one per PSC) to all affected nodes’ ‘trusted roots’ at PSC setup, but this certainly makes the administration more cumbersome and we risk forgetting about this when deploying new PSCs. Are there any pitfalls to avoid here, or will everything work as well as your blog post above describes, including when “failing back” to the original PSC after redeploying it?
Regards,
Anders
Chris
This article was helpful. I did have one issue. In my case, the name of the new PSC in the reconfigure command was case sensitive. I replied to a communities post here:
I performed the reconfigure to a single PSC using the reconfigure. I then did the repoint command to my load balancer VIP FQDN and it worked fine.
Adam
Great article. I’m trying to figure out if my design will work. Right now I have 2 vCenters, one for each datacenter, running the 5.5 U3 VCSA. Of course since I’m running the VCSA, each vCenter has its own SSO site and vSphere domain, although they are named the same.
My end goal is to have 2 VCSA 6.0 U1 appliances and a single SSO and vSphere domain replicating between 2 PSC’s. Is this possible? Each site would still have its own PSC, but I’d like the PSC’s to replicate with each other and only have one SSO and vSphere domain so I can use enhanced linked mode.
I know my end result design is supported and a recommended best practice. I just don’t know if I’m able to get there from where I am now. Thoughts?
Ryan Johnson
I’m working on a blog post to cover this! 🙂
Adam
Hey Ryan, so some more on this. I took my existing 5.5 environment which is on the VCSA, installed 5.5 SSO on Windows and was able to point the 5.5 appliances to 5.5 SSO easy enough. I was then able to upgrade both to 6.0, keeping SSO on Windows. There doesn’t seem to be a way to add a 6.0 U1 VCSA to a 6.0 Windows PSC/SSO domain.
I don’t really care if I keep my existing SSO configuration as it’s pretty easy to re-create. So I tried creating a new 6.0 U1 PSC with a new SSO site name, migrate my 5.5 VCSA to 6.0 U1 and then re-pointing/re-configuring the VCSA to the external PSC, but that fails.
Any hints before your blog article comes out? Thanks!
Ryan Johnson
Hey Adam,
Apologies for the detail! Unfortunately, you can not repoint a vCenter Server 6.0 U1 instance to a PSC in a net new SSO domain. It must be within the same domain.
If you have additional questions, let me know – you can email me at ryan.johnson@vmware.com or tweet me @tenthirtyam.
Ryan Johnson
@tenthirtyam
HH
Hi Ryan,
I have a similar issue but with Windows Version. I have 3 5.5U2 vCenters, two have shared SSO Domain, but different site names (Multisite). the third is standalone with its own SSO domain (albeit the same domain name ‘vsphere.local’). All of them are embedded as well.
My target is to have 3 external PSC with a single unified Domain. All PSC will have their site name and replicating everything between each other.
This is major as I want to use enhanced linked mode which requires Common SSO domain.
When are you expecting to release this blog post?
Ryan Johnson
Contact me on Twitter as @tenthirtyam with your details. Happy to help.
Ryan
Dan Barr
Hi Ryan, thanks for the detailed post. I have a question about reconfiguring from an embedded to external PSC, something which isn’t explicitly stated in this post or in the documentation. When deploying the new external PSC, it’s clear that it needs to be a replication partner with the embedded PSC in the same SSO domain, but what about *site*? Should the new external PSC be in the same site as the embedded, or a new site?
Thanks!
Ryan Johnson
Hey Dan!
You can use the same site or a new one; however, if using a new site you must run the “cmsso-util move-services” option after the reconfig.
Ryan
Ryan Johnston
Would recommend using this design instead of Load Balancing the PSC’s with Citrix Netscalers? Is there any advantage or disadvantage to using Netscalers over this design?
karlos knox
can you elaborate on how to implement this requirement?
The target Platform Services Controller must be a replication partner of the existing embedded Platform Services Controller in the same SSO Domain.
I have an embedded PSC that I want to repoint to an external PSC, different sites but same domain.
thanks,,
karlos
Anthony
Hey Ryan,
Thanks for this blog. I’m working on a similar project and I need some advice.
1 have 4 vCenter 5.5 (simple install), each have their SSO domains and each have their own site (default-first-site).
I want to upgrade these 4 vCenter 5.5 to vCenter 6 with 1 SSO domain and 2 sites.
At the moment I am researching the possibility of building 4 new servers, install SSO servers on them and repoint the 4 vCenters. Then do an upgrade to vCenter 6. The challenge I have is how do I get all of them unto the same SSO domain.
Please, kindly advice on a better approach.
Thank you.
Anthony
Rick Grimaldi
Hey Ryan,
Excellent post. I had a question regarding the process:
I have a deployment with two sites (vCenters) and a single SSO Domain. Currently the PSC is embedded on both sites. In the release notes, it states:
“Attempts to reconfigure a vCenter Server with Embedded PSC to a vCenter Server with External PSC will fail if you have more than one external PSC in the same vSphere domain”
Does this mean I cannot move the PSC at both sites to an external PSC? The desire is to do one at a time, effectively having one PSC + vCenter at each site at end state. Also, will any additional reconfiguration be required if bi-directional SRM is being used?
Thanks in advance.
Cheers,
Rick
James Weaver
Hey Ryan,
VMware support is telling me the cmsso-util is not supported for intra site (PSC within same site and domain) repointing. Can you confirm or deny?
Thanks!