In this article, I will share alternative methods of deploying replicated Platform Services Controller Node (PSCs) using the VCSA 6.0 appliance. Take a look at the various deployment methods below and their respective instructions for more details. If you are deploying using one of the scripts below, you will need to extract the contents of the VCSA ISO. If you are deploying to Workstation/Fusion, you will need to extract the VCSA ISO and add the .ova extension to the following file VMware-VCSA-all-6.0.0-2562643->vcsa->vmware-vcsa before deploying.
Disclaimer: Though these alternative deployment options work, they are however not officially supported by VMware. Please use at your own risk.
Deploying to an existing vCenter Server using ovftool (shell script)
I have created a shell script called deploy_vcsa6_replicated_psc_to_vc.sh which requires using ovftool 4.1 (included in the VCSA ISO) to specify the appropriate OVF "guestinfo" properties for a replicated PSC deployment. You will need to edit the script and modify several variables based on your environment.
Here is an example of executing the script:
Deploying to an ESXi host using ovftool (shell script)
I have created a shell script called deploy_vcsa6_replicated_psc_to_esxi.sh which requires using ovftool 4.0 or greater to specify the appropriate OVF "guestinfo" properties for a replicated PSC deployment. You will need to edit the script and modify several variables based on your environment. The behavior of this script is similar to the one above, except you are deploying directly to an ESXi host.
Deploying to an existing vCenter Server using ovftool (PowerCLI)
I have created a PowerCLI script called Deployment-PSC-Replication.ps1 which uses ovftool and specifies the appropriate OVF "guestinfo" properties for a replicated PSC deployment. You will need to edit the script and modify several variables based on your environment.
Deploying to VMware Fusion & Workstation
To properly deploy the new VCSA 6.0, the proper OVF properties MUST be set prior to the booting of the VM. Since VMware Fusion and Workstation do not support OVF properties, you will need to manually deploy the VCSA, but not power it on. Once the deployment has finished, you will need to add the following entries to the VCSA's VMX file and replace it with your environment settings. Once you have saved your changes, you can then power on the VM and the configurations will then be read into the VM for initial setup.
guestinfo.cis.deployment.node.type = "infrastructure"
guestinfo.cis.vmdir.domain-name = "vghetto.local"
guestinfo.cis.vmdir.site-name = "vghetto"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.vmdir.first-instance = "false"
guestinfo.cis.vmdir.replication-partner-hostname = "192.168.1.50"
guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.addr = "192.168.1.63"
guestinfo.cis.appliance.net.pnid = "192.168.1.63"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.dns.servers = "192.1681.1"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.ssh.enabled = "true"
For more information, you can take a look at this article here.
Deploying using new supported scripted install (bonus)
As mentioned earlier, there is also a new scripted installer included inside of the VMware-VCSA ISO under /vcsa-cli-installer which supports Windows, Mac OS X and Linux, but must be connected directly to an ESXi host. There are several templates that are also included within the /vcsa-cli-installer/templates. I thought as a bonus I would also share the template I have been using to deploy replicated PSC instances using a static IP Address which some of you may find useful.
{
"__comments":
[
"William Lam - www.virtuallyghetto.com",
"Example VCSA 6.0 Replicated Platform Service Controller Node Deployment w/Static IP Address"
],
"deployment":
{
"esx.hostname":"192.168.1.200",
"esx.datastore":"mini-local-datastore-1",
"esx.username":"root",
"esx.password":"vmware123",
"deployment.network":"VM Network",
"deployment.option":"infrastructure",
"appliance.name":"psc-02",
"appliance.thin.disk.mode":true
},
"vcsa":
{
"system":
{
"root.password":"VMware1!",
"ssh.enable":true,
"ntp.servers":"0.pool.ntp.org"
},
"sso":
{
"password":"VMware1!",
"domain-name":"vghetto.local",
"site-name":"virtuallyGhetto",
"first-instance":false,
"replication-partner-hostname":"192.168.1.50"
},
"networking":
{
"ip.family":"ipv4",
"mode":"static",
"ip":"192.168.1.51",
"prefix":"24",
"gateway":"192.168.1.1",
"dns.servers":"192.168.1.1",
"system.name":"192.168.1.51"
}
}
}
The use the scripted installer, you just need to change into the appropriate OS platform directory (win32,mac or lin64) and there should be a binary called vcsa-deploy. To use this template, you just need to save the JSON to a file and then specify that as the first argument to vcsa-deploy utility.
Here is an example of deploying a PSC using the vcsa-deploy scripted installer.
- Part 0: Introduction
- Part 1: Embedded Node
- Part 2: Platform Services Controller Node
- Part 3: Replicated Platform Services Controller Node
- Part 4: vCenter Server Management Node
Hi William,
I have a question about the default timeout settings policy for the vcsa bash shell login.
I have noticed that after some time if the putty session is inactive the vcsa shell session displays the message and it's as mentioned in the below screenshot.
vmware-vcsa:/ #timed out waiting for input: auto-logout
command>
Wanted to know if this timout can be altered within the linux appliance without going into the VAMI page or not.
Thanks in advance,
Yes, you'll want to use shell.set command and specify a timeout:
Command> shell.set --help
Usage:
shell.set [--help/-h] --enabled BOOL --timeout INT
Description:
Set enabled state of BASH, that is, access to BASH from
within the controlled CLI.
Input Arguments:
--enabled BOOL
Enabled can be set to true or false
--timeout INT
The timeout (in seconds) specifies how long you enable the
Shell access.
BTW - There's no VAMI in the VCSA 6.0
thanks a lot for the quick reply.
This definately helped me.
Cheers.
Hi William,
I have another question that needs to be addressed by VMware as this is critical . I'm currently testing the VCSA for security hardening for within our organization and i'm having a major concern over the way the appliance is storing the password in plain text.
/usr/lib/vmware/cis_upgrade_runner\config-template.json
{
"source-components": {
"com.vmware.vpxd":
[{"url" : "//localhost:443",
"username" : "root",
"password" : "vmware",
"platform" : "linux",
"version" : "5.1"}]
},
"destination-components": {
"com.vmware.vpxd":
[{"url": "//localhost",
"username" : "root",
"password" : "vmware",
"platform" : "linux"}]
},
"targets": [
{
"host": "localhost",
"username" : "root",
"password" : "vmware",
"platform" : "linux"
}
],
"upgrade-settings" : {
"power-off-source" : "True",
"infrastructure" : {
"host": "localhost",
"httpPort": "80",
"httpsPort": "443",
"username": "root",
"password": "vmware"
},
"export-folder" : "/tmp/vmware/cis-export-folder"
}
Please review this at the earliest and let your product team know if this case be hashed in anyway so that we donot save password's in plain text.
Regards,
Srinivas.B.N
Hi Srinivas,
Thanks for your comment. The file you're referencing is actually just a default "template" file and the VCSA is not storing the actual passwords. You can confirm by setting the password of choice during deployment and checking this file again. I can see how this could be miss-interpreted, especially by security tools. I've also shared this feedback with Engineering.
Either I'm missing something, or there seems to be an issue with the dns.servers key when trying to enter more than one DNS server. The following doesn't work:
"dns.servers": "8.8.8.8,4.2.2.1",
This works fine:
"dns.servers": 8.8.8.8",
This also works fine:
"ntp.servers": "ntp1.test.local,ntp2.test.local",
I get "The value, 8.8.8.8,4.2.2.1, of the key 'vcsa->networking->dns.servers' is invalid!" when running the script.
Missing a quote in my single DNS server example. Should be "dns.servers": "8.8.8.8",
Our TAM pointed me to the release notes...it's a bug. Hopefully it will be fixed soon!
https://www.vmware.com/support/vsphere6/doc/vsphere-esxi-vcenter-server-60-release-notes.html
The vCenter Server Appliance scripted installer fails if more DNS servers are provided simultaneously
The scripted installation of vCenter Server Appliance fails if you provide more than one DNS server during the installation process.
Workaround: You should use only one DNS server at a time, and after the installation has finished, you can add more DNS servers.
I managed to resolve this by changing the dns.server entry under the network section to this:
"dns.servers": "8.8.8.8,9.9.9.9",
The default templates have another notation and will throw an error:
"dns.servers": [
"",
""
],
The same (serialized string) notation is being used for the ntp.servers variable, and documented in "Command-Line Deployment and Upgrade of VMware vCenter Server Appliance 6.0 Update 2"
William, You VCSA posts have been amazing as I work to get our vSphere design updated for 6! I'm working on a script to automated the changing/repointing of the vcsa to different PSCs but am getting stuck on having plink establish the session & enable shell before it executes the '/usr/lib/vmware-vmafd/bin/vmafd-cli set-dc-name --server-name localhost --dc-name PSCFQDN' command.
I was thinking of a PowerShell script to read the root creds securely and select which VC to change and which PSC to change the VC to... then pass all that in a plink script to execute.
If I manually establish a putty session, then exit and run my script it works. but if the VC reboots, then the script wont work.
Any advice? Other approaches?
I've not really done much with plink, so won't be able to help much there. I would recommend that you build up a shell script and just have plink run that, that way you don't have to worry about the execution of the script over SSH and just have it run it locally. Good Luck
I am having trouble trying to find out how to verify that replication is setup and occuring as expected between 2 PSC setup behind a load balancer. I am pretty confident I have deployed this correctly but am looking for some type of validation.