Homelab: Beginners Guide – Part 2 Installing Virtual Center 6.7

Where Are We and What’s Next?

At this point in our lab build we have our ESXi hosts up and connected to some storage but nothing else.  We need a tool to manage all our hosts and provide accss to all the cool features that VMware and Virtualisation is known for such as moving VMs between hosts, advanced networking, HA, load balancing etc.

Within vSphere this is Virtual Center.  Currently available in two formats.  One being an installable that can run on a Windows Server and one being a deployable appliance that is simply pushed out to a host without any other OS requirements.  For this guide we are going to be deploying the appliance version (known as the Virtual Center Server Appliance, VCSA).  This is because it’s now the recomended version to use from VMware and the Windows version is probably going to be phased out sometime in the near future.  The VCSA also doesnt require a Windows licence and the patching that goes with it either.  and finally, for a lab environment, the requirements are a little lower so it’s a better fit.

Virtual Center Server Appliance: It’s More Than One Thing!

One thing to note before we proceed is that the VCSA is actually MORE than one component. but, for the purposes of simplicity I’m refering to the suite as one entity in this beginners guide.  If your curious the VCSA is actually split in two.  The vCenter Management Server (responsible for managing the environment and the ‘thing’ you actually log on to) and the Platform Services Controller [PSC] (which deals with mutiple things like sign on, certificates, licensing etc.)  The PSC can be installed with the VCSA (embedded mode) or split out to a seperate box for high load installs.  In this lab we’re going to use the embedded PSC for simplicity.

Before You Start: Sort Out DNS

vSphere in general relies heavily on name resolution to work correctly. Indeed, installing the Virtual Center Server Appliance without having DNS in place first (i.e. using the IP address) can cause issues further down the line such as the inability to change the hostname without the system falling over or other such quirks.

So, before going any further we are going to create a DNS server on your first ESXi host.  In my case I have installed a Windows 2012 R2 Active Directory VM on our first ESXi host and configure a domain and DNS.  I’m not going to cover how to configure Active Directory in this post but before going any further you should ensure that a domain for you lab exists (in this example ‘lab.local’) as well as  forward and reverse DNS lookup zones with entries for your ESXi servers and Virtual Center Server Appliance.  In my case:

NOTE: If your shared storage solution supports extra features you can simply add DNS to this instead of using a Windows server / Active Directory.  For example.  Synology DSM has a supported DNS application that can make the NAS run as a DNS server for you lab.

Reverse Lookup Zone: Three static entries for ESXi and VCSA and the autocreated entry for the AD server.

Screen Shot 2016-07-26 at 22.08.46

Forward Lookup Zone Entries: For the two ESXi servers and the Domain controller.

Screen Shot 2016-07-26 at 22.08.31

and  the entry for the VCSA about to be deployed.

Screen Shot 2016-07-27 at 22.09.07


Deploying The VCSA (Automated)

In vSphere 6 the VCSA can be deployed the traditional way, clicking through wizards etc. This is a bit old school and not the way of the future.  It’s always best to understand how to automate something and VMware provice a simple command line tool to automate the whole process.   This works for Windows, Mac and Linux and is the method we are going to use here.

NOTE: The following is shown using a Windows PC as the client.  This can also be done via a Mac.  It’s just the kick off command that changes.

What You’ll Need

For this section of the guide you’ll need:

  • A Windows PC on the same network subnet as the ESXi hosts previously set up.
  • Windows Powershell
  • The VCSA ISO file (I used VMware-VCSA-all-6.7.0-10244745.iso from VMware site).
  • The ability to mount .iso images (Native to Windows 10).

Step 1: Mount the VCSA ISO and Configure Settings.

Mount your VCSA ISO.  In Windows this is done by Right-Clicking the VCSA .iso file and selecting Mount from within Windows 10.

Navigate to <CD Drive>:\vcsa-cli-installer\templates\install and copy the embedded_vCSA_on_ESXi.json file to somewhere simple to access (such as c:\temp)

Open the .json file and edit in the values as you require for your environment.  I’ll explain the requirements for the values after this example (shown).

Example JSON Config File

    "__version": "2.13.0",
    "__comments": "Modified template to deploy a vCenter Server Appliance with an embedded Platform Services Controller on an ESXi host.",
    "new_vcsa": {
        "esxi": {
            "hostname": "labesxi01.lab.local",
            "username": "root",
            "password": "",
            "deployment_network": "VM Network",
            "datastore": "Datastore2"
        "appliance": {
            "__comments": [
                "You must provide the 'deployment_option' key with a value, which will affect the VCSA's configuration parameters, such as the VCSA's number of vCPUs, the memory size, the storage size, and the maximum numbers of ESXi hosts and VMs which can be managed. For a list of acceptable values, run the supported deployment sizes help, i.e. vcsa-deploy --supported-deployment-sizes"
            "thin_disk_mode": true,
            "deployment_option": "small",
            "name": "LABVCSA"
        "network": {
            "ip_family": "ipv4",
            "mode": "static",
            "ip": "",
            "dns_servers": [
                "", ""
            "prefix": "24",
            "gateway": "",
            "system_name": "labvcsa.lab.local"
        "os": {
            "password": "",
            "ntp_servers": "",
            "ssh_enable": true
        "sso": {
            "password": "",
            "domain_name": "vsphere.local"
    "ceip": {
        "description": {
            "__comments": [
                "++++VMware Customer Experience Improvement Program (CEIP)++++",
                "VMware's Customer Experience Improvement Program (CEIP) ",
                "provides VMware with information that enables VMware to ",
                "improve its products and services, to fix problems, ",
                "and to advise you on how best to deploy and use our ", 
               "products. As part of CEIP, VMware collects technical ",
                "information about your organization's use of VMware ",
                "products and services on a regular basis in association ",
                "with your organization's VMware license key(s). This ",
                "information does not personally identify any individual. ",
                "Additional information regarding the data collected ",
                "through CEIP and the purposes for which it is used by ",
                "VMware is set forth in the Trust & Assurance Center at ",
                "http://www.vmware.com/trustvmware/ceip.html . If you ",
                "prefer not to participate in VMware's CEIP for this ",
                "product, you should disable CEIP by setting ",
                "'ceip_enabled': false. You may join or leave VMware's ",
                "CEIP for this product at any time. Please confirm your ",
                "acknowledgement by passing in the parameter ",
                "--acknowledge-ceip in the command line.",
        "settings": {
            "ceip_enabled": true

So, what are the values that need filling in?  From the top:

esx:hostname - This field is populated with the IP address / hostname of the ESXi server you want to deploy this VCSA to.  NOTE: Use IP if DNS is not set up corretly at this stage but preferably use DNS as this can stop known issues arising later if you want to rename the appliance or do anything that relies on FQDN.
esx:username - The username you want to use to connect to the specified ESXi host.  Usually root.
esx:password - The password for the account specified in the field above. Note this is stored in plain text.
esxi:deployment.network - This is the name of the network created in part 1 of the guide. If you didn't change anything it's 'VM Network'. 
esx:datastore - Then EXACT name of the datastore on the ESXi host to deploy the VCSA on. NOTE: This is case and space sensitive.
appliance:thin.disk.mode - Either true or false. vSPhere can, simplistically, allocate all disk space requested to a VM at creation or as it is used (more efficient). I recomend true in this instance
appliance:deployment.option - This dictates the amount of CPU, DISK and RAM allocated to the VCSA based on VMware's t-Shirt sizes. Small is good for up to 100 hosts and 1000 VMs and is perfect for a lab. There is a Tiny option but you can hit the VM limit in a lab quite quickly. 
appliance:name - The text name that you wan to call the VCSA.
network:ip.family - specifies wether the above address is in IPv4 or IPv6 format. Default is IPv4
network:mode - Choose between static or DHCP. Static is prefered for predictability. 
network:ip - This is the IP address of this VCSA server you're going to be deploying. 
network:DNS.servers - This setting requires a list (can be one) of DNS servers for name resolution.  I have set these to be my default gateway (for internet name resolution) and then the IP address of the AD server i intend to build in the lab.
network:prefix - This field is the subnet mask of the network for the VCSA in slash notation. (i.e. 24 = 
network:gateway - This is the default gateway to the internet in IP format.
network:system_name - This is the hostname this VCSA server. NOTE: vSphere is very, very picky about DNS. In this example I assume you have deployed a domain controller or have DNS set up WITH an entry for this VCSA server alreaddy created. e.g. labvcas.lab.local pointing to the IP address you want to give this appliance. If DNS resolution is not ready yet an IP address MUST be used here otherwise the install will fail. However, this will trigger known issues if you ever want to rename your apliance or change its identity. It is HIGHLY recomended to get DNS sorted at this stage. 
os:password - This specifies the root password for the VCSA and is needed for access to the console or SSH access. NOTE: stored in plain text.
os:ntp_servers - This specifies the Network time servers you want the appliance to use. Should be the same as configured for ESXi in part 1 of this guide
os:ssh.enable - A true or false value specifying wether you want to enable SSH access to the VCSA.  AS this is a lab I have enabled it in the example.
sso:password - This sets the default password for the administrator SSO (the in built authentication system) account.
sso:domain-name - The domain name for the SSO component install. NOTE: This cannot be the same as an existing orsoon to be existing Windows domain.  I have used vsphere.local (so the admin account is administrator@vsphere.local). 

Once all of the values have been filled in for your envionment you are ready to deploy the VCSA and automatically configure it with the settings in the JSON  file.

Step 2: Deploy the VCSA

Open a PowerShell window and run the vcsa-deploy.exe from the  VCSA ISO with the path to the JSON file appended to the end (as shown). Please NOTE: Where you run this from needs to be able to resolve the FQDN of the domain controller, ESXi server etc.  So, in my case I ran this on my laptop and had to add the FQDN information of my lab servers to my HOSTS file (C:\Windows\System32\drivers\etc\HOSTS) The Command:

<Drive>:\vcsa-cli-installer\win32\vcsa-deploy.exe install C:\temp\<json-file> --accept-eula --acknowledge-ceip


There will be a prompt asking you to accept the SSL certificate of the ESXi host you’re deploying to.  Type yes and press Enter.

Accept the fingerprint

The isntaller will now deploy the VCSA image, boot the VM and configure based on your settings.

NOTE: Depending on your storage this can take a VERY long time to deploy and an equally long time to configure and boot for the first time (up to 30 mins).

Once the deployment is complete you should be able to open a browser window to the VCSA and log in using the administrator@vsphere.local account.

The Two URLs below are for the different access methods.  The first of for the FLASH client, the second for the HTML5 client (valid from vSphere 6.5 on and the one you SHOULD use).


Ignore the security certificate warning and add it to your exceptions list.


Enter your logon credentials as specified in the JSON file earlier. Press Logon.


You have now deployed and logged on to the VCSA.  The main screen (below, known as the vCenter UI)Capture.JPG should now be visible.  Next up we need to add the ESXi hosts to the VCSA so it can manage and configure them.

Step 3: Create a Datacenter, Cluster and Add ESXi Hosts to VCSA

Going forward I will be showing the processes to set up the basics of vCenter via the GUI as, at this point, it gives a better understanding on how things fit together.  You should know that all these steps are possible via the command line (PowerCLI) which is quicker but requires you to know what you want to do.

Now that you are in the VCSA client we can start to configure it to manage our environment.  All vSphere administration and configuration is done via the VCSA.  Indeed, once a host is added to the VCSA it will warn you that nothing should be changed if you log on locally to a host.

First order of bnusiness is to create a new Datacenter.  This is a top level logical container for clusters of ESXi hosts.

Right click on the VCSA in the left hand pane and select New Datacenter from the context menu.



Enter a friendly name for this Datacenter and Press Ok.1.JPG


You’ll now see that the created Datacenter object appears in the left hand pane of the vSphere web client. Again, right-click and select  New Cluster from the context menu.


This brings up a nicly detailed set of options that can be turned on for a cluster.  Give the cluster a sensible name and make sure you turn on DRS and HA.

DRS (Dynamic Resource Scheduling) is VMware’s technology for load balancing VMs across all the hosts in the cluster. It can mopve VMs between hosts to allow better usage of available resources.  It’s an awesome feature and should definitly be turned on.  You can leave the defaults for it’s actual configuration and feel safe it wont break anything.

HA (High Availability) monitors VMs to see if they are responsive.  If a host goes down (for example) and HA is turned on the VMs on the downed host will be powered up on the remaining hosts in a crash consistent state.  Not essential for a LAB environment but worth playing with none the less.

You’ll notice there is also the option of turning on “vSAN”.  This is a feature that takes the storage you have in your hosts and makes, as the name says, a virtual SAN out of them.  My hardware isn’t set up like this so, therefore, I can’t demonstrate this feature now.


After Pressing OK you should now have the Datacenter and Cluster Object visible in Virtual Center.


Now we need to add a host to the cluster.  Right click on the Cluster and select Add Hosts.  This will bring up a wizard to add in your hosts.  Type the IP (if no DNS is set up) or the Hostname (if DNS is set up) of the first host you want to add and select Next.

NOTE: As always I recomend using the hostname to add your host in as vSphere is sensitive to DNS working correctly for advance functions and adding by hostname implicitly verifies that everything is working correctly.

Type the FQDN hostnames, usernames (root) and the passwords for these hosts and click Next.1.JPG

You may get the standard certificate warning when connecting to a host for the first time.  Tick the boxes and Select OK.


A Summary page is displayed. Note the watrnings for me that there are powered VMs running (true). Click Next.


There is now a final “review and finish” screen.  Select Finish.











Once completed you should see you ESXi host(s) appear under the cluster object. Note that my existing AD server and the actual Virtual Center server VMs are now showing as part of the cluster and not under a specific ESXi host.

screenshot 2019-01-06 at 11.02.29

You should notice the following warning at the top of the screen.  Simply informing you that the software is unlicenced.  Clicking on Details should inform you you have 59 days left (i.e. the trial period).  This wont go away unless you licence the software.

screenshot 2019-01-06 at 11.09.51

Step 4 –  Errors and Warnings

You’ll probably notice that now the cluster is set up there may be some warnings displayed.  Most probably it’s the ones shown below:

Screenshot 2019-01-06 at 11.22.03.png

(if you dont have some or all of these, no matter, skip that part).  At this point we need to decide if these are an issue or not (really)  From the above:

The host is potentially Vunerable to issues……:  This is VMware speak for  not having a fully patched ESXi.  You should read the linked KB and remediate ASAP.
This host currently has no network Redundency: This is correct in my setup  I’ve not currently configured multiple NICs for the Management or storage networks. Safe to Ignore
SSH Enabled
: We deliberatly as this is our lab and it allows for easy access while playing. You should NOT do this in production.
Syslogs on Non persistent storage: We need to fix this as logs will currently dissappear when the system is rebooted.

Fixing the “Syslogs on non persistent storage” is possible in one step.  Select the first host in the cluster (in the left hand tree view) and click: Configure > System >Advanced System Settings.

Scroll down and select the setting labelled Syslog.global.logDir

Screenshot 2019-01-06 at 11.28.27.png

Right click this setting and select Edit Option


Change the value to match something like that shown below.  I’ve redirected the logs to Datastore1.  NOTE: when editing this value the “[  ]” MUST be kept and the name inside them is case and space sensitive.  It must match EXACTLY the name of the Datastore. Click Save.  Repeat for the other hosts in the cluster.  I like to target each host to a different Datastore.  If you only have the one Datastore target the logs to a seperate folder to avoid confusion.

Screenshot 2019-01-06 at 11.29.45.png

Now reboot the vCenter appliance and the error relating to the logging should dissappear.

Fixing the SSH Is Enabled Error

The final warning we see was about the ESXi Secure Shell (SSH) being active.  As mentioned before we probably want this running in a lab but, if you want to know how to remove it, the steps to disable this are shown below.


Simply select the host with the warning in the left pane of the vCenter webclient and then select the Manage tab.   Now select the Security Profile item in the left bar (you’ll need to scroll down), select services area and click edit button.  Select SSH and Stop the service.

Next Steps

Thats the end of the deployment and basic setup of vCenter and ESXI.  You should now have a working ESXi cluster and vCenter and be able to deploy simple VMs all on a single network and get going.  Next up we will cover the configuration of more advanced networking and authentication within vCenter (using a distributed switch over multiple standard switches, joining the lab to a domain) and how to set up vMotion and other cool features of vSphere to get something resembeling a production environment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s