In this article, I will share alternative methods of deploying the first Platform Services Controller Node (PSCs) using the VCSA 6.0 appliance. If you are interested in deploying additional PSC instances joined to an existing SSO Domain, stay tune for Part 3 where this will be covered. 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.
psc
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_first_psc_to_vc.sh which requires using ovftool 4.1 (included in the VCSA ISO) to specify the appropriate OVF "guestinfo" properties for a 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:

vcsa-6.0-platform-service-controller-node-deployment

Deploying to an ESXi host using ovftool (shell script)

I have created a shell script called deploy_vcsa6_first_psc_to_esxi.sh which requires using ovftool 4.0 or greater to specify the appropriate OVF "guestinfo" properties for a 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.ps1 which uses ovftool and specifies the appropriate OVF "guestinfo" properties for a 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.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.addr = "192.168.1.60"
guestinfo.cis.appliance.net.pnid = "192.168.1.60"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.dns.servers = "192.168.1.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 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 the first PSC using a static IP Address which some of you may find useful.

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.

vcsa-6.0-first-platform-service-controller-scripted-install

13 thoughts on “Ultimate automation guide to deploying VCSA 6.0 Part 2: Platform Services Controller Node

  1. Where I can download VMware-VCSA-all-6.0.0-2446786.iso ?
    As a beta-test member I have an access to only 6.0.0-2175370
    and there is no mac or lin64 dirs inside

    • There have been some updates since the Beta release, so that’s why you’re not seeing it. This will be available very shortly when vSphere 6.0 GAs, so stay tune

  2. Hi William,
    I must have hit your site 1000 times, atleast through feedly. I was wondering whether you could do a ‘how to’ article on deploying windows VM (ova or ovf) via powershell+ovftool directly to the esxi. If possible with network configured.

  3. William,

    This article is so helpful. I have a question. If it is an embedded PSC (SSO), the info gets stored in /etc/vmware-sso/sso.properties. If it is an external PSC (SSO), do you know where that information will get stored..? I couldn’t find sso.properties file at all.

  4. I know this thread is old, but there is some great VCSA stuff on here. I am considering moving from vSphere 5.5 Windows install to the VCSA v6 appliance. Starting over from scratch. During the VCSA install I can choose tiny, small, etc. with large handling 1000 hosts. Yet the VCSA documentation says the embedded Postgres is only suitable for small environments. That confuses me. 1,000 hosts doesn’t seem small 🙂

    • Hi Jeff,

      That’s definitely a documentation error/typo. Starting with vSphere 6, both Windows VC and VCSA is at parity not only from a scale standpoint but also performance/features. Agree, that 1K is not “small” environment but I guess some might say it is 😉

      Whatever you decide to choose from a sizing standpoint, you can always increase the CPU/MEM (which is what is happening on the backend) as you increase # of Hosts/VMs you are managing)

  5. Hi William

    Thanks again for some great info ..You rock!

    Is there any chance you could details how to load the guestinfo values at command line using the ovftool with a proper working example without a script please ? Just a raw command line to add at least one setting 🙂

    Could you also possibly show an example as to how to set the config file for ovftool so it parses the values correctly ?

    Look forward to hearing from you

    Happy New year

    D

    • Hi,

      Please don’t spam my blog with similar and repeated questions. If you’re not familiar with ovftool, I would first recommend you take a look at the official ovftool user guide which goes over things like inspecting/probing an OVF/OVA using ovftool https://www.vmware.com/support/developer/ovf/ From there, you’ll be able to deduce the guestinfo.* properties which I’ve also documented for your earlier questions. In fact, you can find several dozen examples on my blog include the article you’re asking the question in. So I ask that you at least look at the some of the scripts that I’ve created to see if you can figure it out. I’ve even categorized all my OVF/OVA/ovftool related articles which can be found here http://www.virtuallyghetto.com/ovf

  6. Hey William – another great article!

    I’m running into an issue when deploying an external PSC using the PowerCLI script. The VM deploys correctly, and appears on the network, I can ssh to it, etc. I’ve configured it for a new SSO Domain.

    But when I run the vdcrepadmin -f showservers utility, it tells me:

    lca1-b1-stg-test-psc:/usr/lib/vmware-vmdir/bin # ./vdcrepadmin -f showservers -h localhost -u administrator
    password:
    Vdcrepadmin failed. Error [Server down] [9127]

    I have also done a similar external PSC deployment from the browser, using the same settings I’m using in the PowerCLI script, and it works:

    lca1-b1-stg-AUTOpsc:/usr/lib/vmware-vmdir/bin # ./vdcrepadmin -f showservers -h localhost -u administrator
    password:
    cn=lca1-b1-stg-autopsc.stage.linkedin.biz,cn=Servers,cn=default-first-site,cn=Sites,cn=Configuration,dc=linkedin,dc=sso

    So I’m struggling to figure out what is different between the browser-based deployment and the PowerCLI deployment… If you could steer me in the right direction, I’d really appreciate it.

    Thanks!

    • I’ve found some more info on this problem, by comparing a vanilla PSC deployment (from the browser-deployed method) and a PSC deployed from the PowerCLI script.

      When trying to run ‘service-control’, it would error out telling me:

      Traceback (most recent call last):
      File “/bin/service-control”, line 335, in
      exit(main())
      File “/bin/service-control”, line 309, in main
      cfg = parseArguments()
      File “/bin/service-control”, line 302, in parseArguments
      restrict=intServices, deploymentType=get_deployment_nodetype(),
      File “/usr/lib/vmware/site-packages/cis/utils.py”, line 416, in get_deployment_nodetype
      with codecs.open(fPath, ‘r’, ‘utf-8’) as fp:
      File “/opt/vmware/lib/python2.7/codecs.py”, line 878, in open
      file = __builtin__.open(filename, mode, buffering)
      IOError: [Errno 2] No such file or directory: ‘/etc/vmware/deployment.node.type’

      I looked in /etc/vmware, and in fact there was no file called ‘deployment.node.type’, and it was also missing a file called “db.type”. I added those files, modeling them after the working node that I deployed from the browser.

      After doing that, I was able to use service-control successfully. However, when doing a ‘service-control –start –all’, I encountered another problem:

      Stderr = /etc/init.d/vmware-stsd: line 204: [: -$: unary operator expected
      awk: fatal: cannot open file /usr/lib/vmware-sso/vmware-sts/conf/catalina.properties' for reading (No such file or directory)
      ..failed

      2016-01-15T17:17:07.407Z {
      "resolution": null,
      "detail": [
      {
      "args": [
      "Command: ['/sbin/service', u'vmware-stsd', 'start']\nStderr: /etc/init.d/vmware-stsd: line 204: [: -$: unary operator expected\nawk: fatal: cannot open file
      /usr/lib/vmware-sso/vmware-sts/conf/catalina.properties’ for reading (No such file or directory)\n..failed\n”
      ],
      “id”: “install.ciscommon.command.errinvoke”,
      “localized”: “An error occurred while invoking external command : ‘Command: [‘/sbin/service’, u’vmware-stsd’, ‘start’]\nStderr: /etc/init.d/vmware-stsd: line 204: [: -$: unary operator expected\nawk: fatal: cannot open file `/usr/lib/vmware-sso/vmware-sts/conf/catalina.properties’ for reading (No such file or directory)\n..failed\n'”,
      “translatable”: “An error occurred while invoking external command : ‘%(0)s'”
      }
      ],
      “componentKey”: null,
      “problemId”: null
      }
      ERROR:root:Unable to start service vmware-stsd, Exception: {
      “resolution”: null,
      “detail”: [
      {
      “args”: [
      “vmware-stsd”
      ],
      “id”: “install.ciscommon.service.failstart”,
      “localized”: “An error occurred while starting service ‘vmware-stsd'”,
      “translatable”: “An error occurred while starting service ‘%(0)s'”
      }
      ],
      “componentKey”: null,
      “problemId”: null
      }
      Unable to start service vmware-stsd, Exception: {
      “resolution”: null,
      “detail”: [
      {
      “args”: [
      “vmware-stsd”
      ],
      “id”: “install.ciscommon.service.failstart”,
      “localized”: “An error occurred while starting service ‘vmware-stsd'”,
      “translatable”: “An error occurred while starting service ‘%(0)s'”
      }
      ],
      “componentKey”: null,
      “problemId”: null
      }

      I *could* create the ‘catalina.properties’ file manually, again basing it off of the browser-based deployment, but at this point, there is clearly something going on with the PowerCLI deployment that is different than the browser-based deployment. I’m not sure if it is using some sort of post-install script to set all of these things up? It would appear that it’s not picking up “embedded” and “infrastructure” types from the ovf properties, since the ‘db.type’ and ‘deployment.node.type’ files don’t exist.

Thanks for the comment!