Category Archives: vCenter

Reconfiguring vCenter Server for External PSC

An external Platform Services Controller (PSC) can provide scalability and high availability across sites. A vCenter Server initially deployed with an embedded PSC can be reconfigured to use an external PSC by following the steps outlined below. Multiple external Platform Services Controllers can be deployed and an environment can be mixed between the appliance and Windows versions of vCenter Server and PSC.



  • The vCenter Server must be running at least version 6.0 Update 1.
  • The process involves the installation of an external PSC as a new target for vCenter Server. The PSC must be in the same Single Sign-On site and domain as the vCenter Server.
  • Ensure you have good backups of your vCenter Server. If the vCenter Server is virtual take a snapshot before starting the process, likewise after deploying the new PSC take a snapshot.
  • If the process fails for any reason revert back to the snapshots.
  • An external PSC deployment model cannot be converted into an embedded PSC.
  • If vCenter HA is enabled then disable and reconfigure after the process is complete. For more information see Configuring vCenter 6.5 High Availability.
  • The commands outlined below are the same for the vCenter Server Appliance and Windows vCenter Server, unless specified. Take into account the following environmental variables:
    • For Windows all commands should be run as an administrator in an elevated command prompt.
    • For the appliance use the root account for all commands, enable BASH and launch the shell by running shell.set -enabled True followed by shell.


The first step is to determine the Single Sign-On site by running the following commands on the vCenter Server: vCenter Server Appliance: /usr/lib/vmware-vmafd/bin/vmafd-cli get-site-name --server-name localhost. Windows vCenter Server: "C:\Program Files\VMware\vCenter Server\vmafdd\vmafd-cli" get-site-name --server-name localhost.

Make a note of the SSO site. Next deploy the new external Platform Services Controller, if you require assistance with this see the Deploying an External Platform Services Controller post. The new PSC must be configured with the same Single Sign-On site and domain as the vCenter Server you want to reconfigure.



Once the external PSC is up and running go back to the vCenter Server. Confirm the Platform Services Controller services are running, for Windows first navigate to the correct directory by using:

cd "C:\Program Files\VMware\vCenter Server\bin".

For both the appliance and Windows versions run the following command:

service-control --status --all

Check that the VMware License Service, VMware Identity Management Service, VMware Security Token Service, VMware Certificate Service, and VMware Directory Services are running.


To reconfigure the vCenter Server to use the new PSC use the following command, replacing newpsc with the IP or FQDN (case sensitive) of the new PSC, username, domainname, and password with the relevant SSO domain and user details.

cmsso-util reconfigure --repoint-psc newpsc --username username --domain-name domainname --passwd password

If the external PSC is configured to use a custom port then add [--dc-port port] where port is the port number. Check the configuration results.


Confirm the vCenter is accessible by logging in to the vSphere web client. The process is complete, if you disabled vCenter HA then you can now go ahead and reconfigure.

Deploying an External Platform Services Controller

This post will walk through the process of deploying an external Platform Services Controller (PSC) appliance. The PSC was introduced with vSphere 6.0 to deal with infrastructure services such as Single Sign-On, Certificate Authority, and licensing.  For more information on the Platform Services Controller review this KB.

The PSC can be either embedded within the vCenter Server, or external to allow scale out for larger environments. When deciding if an embedded or external PSC is appropriate review the vCenter Server deployment models here. The external PSC can be installed as a virtual appliance, or installed on a Windows server (virtual or physical). Environments can be mixed, for example a PSC virtual appliance can be deployed where a physical Windows vCenter currently exists. You may also want to review the following posts:

Installation Process

Downloaded the VMware vCenter Server Appliance here: v6.0, v6.5.

Mount the ISO on your computer. The VCSA 6.5 installer is compatible with Mac, Linux, and Windows. Browse to the corresponding directory for your operating system, e.g. \vcsa-ui-installer\win32. Right click Installer and select Run as administrator. As we are installing a new instance click Install.


On the welcome page click Next. Accept the license agreement and click Next.


For the deployment type we need to select Platform Services Controller under the External Platform Services Controller heading. Click Next.


Enter details of the vCenter or ESXi host where the appliance will be deployed, click Next.


Select a location for the virtual appliance and click Next.


Select the compute resource for the virtual appliance and click Next.


Enter a name for the virtual appliance and configure the root password, click Next.


Select the storage to use and click Next.


Select the VM network to use and configure the network settings, click Next.


Review the deploy Platform Services Controller summary page and click Finish. The Platform Services Controller appliance will now be deployed.


In stage 2 we configure the new appliance, click Next.


Configure the NTP server(s) and click Next.


The SSO configuration page is where we determine if the PSC should be joined to an existing SSO domain or if you are creating a new SSO domain. Enter the SSO domain details and click Next.


Tick or untick the Customer Experience Improvement Program and click Next.


On the summary page click Finish and Ok. The PSC virtual appliance will now be configured.


Once complete we can access the Platform Services Controller in 2 different ways. For the appliance management portal browse to https://IP:5480 where IP is the IP or FQDN of the virtual appliance. Login with the root account.


Here we can configure settings specific to the virtual appliance, such as networking, SSH, syslog, etc.


To access the user interface browse to https://IP/psc where IP is the IP or FQDN of the virtual appliance. Login with the administrator@vsphere.local account created or defined in the installation wizard.


Here we can configure Platform Services Controller related settings, such as permissions, certificates, etc. To join the PSC to an Active Directory domain browse to Appliance Settings, and Manage. Under Active Directory click Join.


The Platform Services Controller has now been deployed and configured. Multiple PSC instances can be placed behind a load balancer to provide High Availability, as outlined in this KB.

VMware Snapshot Overview

This post will talk about how VMware snapshots work, what they should and should not be used for, and provide a demonstration. A snapshot preserves the state and data of a virtual machine from a specific point in time. You can create multiple snapshots to save the virtual machine in different stages of a work process. Snapshots are managed using Snapshot Manager in the vSphere web client, or with PowerCLI. You should not manually alter any of the snapshot files as this may compromise the disk chain, with potential for data loss.

What happens when I take a snapshot?

When you take a snapshot of a virtual machine a number of files are created; a new delta disk (or child disk) is created for each attached disk, in vmdk format. The delta disks follow a naming convention and sequence of vmname-000001.vmdk, vmname-000002.vmdk and so on. These files are stored with the base vmdk by default. Any changes to the virtual machine are written to the delta file(s), preserving the base vmdk file. Think of this delta file as a change log, representing the difference between the current state and the state at the time the snapshot was taken. A .vmsd file is created to store the virtual machine snapshot information defining the relationships between child disks. A .vmsn file and corresponding .vmem file is created if the active state of the virtual machine memory is included in the snapshot. These configuration files are all stored in the virtual machine directory.


When should I use a snapshot?

Use a snapshot as a short term restore point when performing changes such as updating software versions or for testing software or configuration with unknown effects. You can create multiple snapshots of a virtual machine; VMware recommend no more than 32 snapshots in a chain, however best practise for performance is to keep it low, i.e. 2-3 snapshots.

Do not use a snapshot as a backup. Although it provides a restore point a snapshot relies on the base disk(s), without this the snapshot files are worthless. If you need a restore point for more than a few days then consider other options such as traditional backup, or cloning the virtual machine. According to vSphere best practises a single snapshot should not be used for more than 24 – 72 hours. There are a number of factors that determine how long a snapshot can be kept, such as the amount of changed data, and how the application will react to rolling back to a previous point in time. Some disk types and configurations are not supported by snapshots, you can see a full list of limitations here.

What are the risks of using a snapshot?

The more changes that are made within the virtual machine the more data is written to the delta file. This means the delta file grows quickly and in theory can grow as large as the virtual disk itself if the guest operating system writes to every block of the virtual disk. This is why snapshots are strictly a short term solution. Ensure there is sufficient space in the datastore to accommodate snapshots, if the datastore fills up any virtual machines residing in that datastore will be suspended.

How do I take a snaphot?

From the vSphere web client right click the virtual machine to snapshot, select Snapshots, and Take Snapshot. Note that vCenter Server is not a requirement, snapshots are also supported through the local ESXi host web UI.


Enter a name and description for the snapshot. The contents of the virtual machines memory are included in the snapshot by default, retaining the live state of the virtual machine. If you do not capture the memory state, then the virtual machine files require quiescing, otherwise should the virtual machine be reverted to a previous state; then the disks are crash consistent. The exception to this is taking a snapshot of a powered off virtual machine, as it is not possible to capture the memory state, or quiesce the file system.


To view active snapshots locate the virtual machine in the vSphere web client and select the Snapshot tab. Snapshots are listed in order with ‘you are here’ representing the current state, at the end of the snapshot chain.


It is possible to exclude disks by changing the disk mode to independent, covered here. However please use this option with care as it may have other implications. For example if your backup software uses snapshots as part of the backup process then setting independent disks may inadvertently exclude these disks from backups.

 How do I revert back to a snapshot?

Select the snapshot you want to revert back to, and click the revert icon in the top left of the snapshot menu. The icon dialog reads ‘revert the VM to the state it was in when the snapshot was taken’.


Review the confirmation message. The virtual machine state and data will be reverted back to the point in time when the selected snapshot was taken. The current state of the virtual machine (changes made since the snapshot was taken) will be lost unless you have taken a further snapshot. Click Yes to continue.


If you have multiple snapshots you will see the ‘you are here’ marker move to the point in the chain you have reverted to. Snapshots taken after this point are still valid and can be reverted to if required. After you have reverted to a snapshot you are happy with you need to save, or commit, the state of the virtual machine. More on this below.


How do I keep the state of the virtual machine?

When you keep the current state of the virtual machine the delta disks are merged with the base disks, committing the changes and the current state of the virtual machine. This is done by using the delete snapshot options in Snapshot Manager.

  • Delete All – deletes all snapshots from the virtual machine. This merges the delta disk(s) with the base disk(s) to save, or commit, the virtual machine data and configuration at the current point in time. If you have reverted to a snapshot you still need to delete all snapshots to start writing to the base disk again.
  • Delete – deletes individual snapshots from a chain; writing disk changes since the previous snapshot to the parent snapshot delta disk. If only a single snapshot exists then deleting this snapshot is the same as a Delete All for multiple snapshots; the VM state is committed and data is written to the base disk as normal.

Right click the virtual machine in the vSphere web client and select Snapshots, Manage Snapshots. From the All Actions menu select Delete Snapshot to delete the selected snapshot, or Delete All Snapshots. In this example we are deleting all snapshots, so click Yes to confirm.


All snapshots are now removed and the current state of the virtual machine is committed to the base disk. Any changes made from here on in are written to the base disk as normal, unless another snapshot is taken.


What is snapshot consolidation?

Snapshot consolidation is useful if a Delete or Delete All operation fails; for example if a large number of snapshots exist on a virtual machine with high I/O, or if a third party tool such as backup software utilising snapshots is unable to delete redundant delta disks. Using the consolidate option removes any redundant delta disks to improve virtual machine performance and save storage space. This is done by combining the delta disks with the base disk(s) without violating a data dependency, the active state of the virtual machine does not change.

To determine if a virtual machine requires consolidation browse to the vCenter Server, cluster, or host level in the vSphere web client and click the VMs tab. Right click anywhere in the column headers and select Show/Hide Columns. Tick Needs Consolidation and click Ok.


If a virtual machine requires consolidation right click and select Snapshots, Consolidate. There is also a default alarm defined at vCenter level for virtual machine consolidation needed.


From vSphere 6 onwards the snapshot consolidation process was improved. You can read more about the specifics, and testing, in this blog post by Luca Dell’Oca.

The snapshot functions described in this post can also be managed using PowerCLI, this blog post by Anne Jan Elsinga covers the commands you’ll need.

vSphere Data Protection Install Guide

This post will walk through the installation of vSphere Data Protection (VDP) 6.1.3; a vSphere integrated backup and recovery solution. Data Protection is based on EMC Avamar deduplication backup and recovery software, and can also integrate with EMC Data Domain for scalability. In addition to full virtual machine backups vSphere Data Protection offers file level restores, application level backup and restores,  backup data replication to remote sites, and reporting. An emergency host level restore feature has been added for situations where the vCenter Server or web interface is unavailable. For more information on the features available to vSphere Data Protection 6.1.x see this technical overview.

Design Considerations

  • vSphere Data Protection is deployed as an OVA template.
  • The virtual appliance can be deployed with the following configurations:
    • 0.5 TB backup datastore, 873 GB disk space, 4 vCPU, 4 GB memory.
    • 1 TB backup datastore, 1600 GB disk space, 4 vCPU, 4 GB memory.
    • 2 TB backup datastore, 3 TB disk space, 4 vCPU, 4 GB memory.
    • 4 TB backup datastore, 6 TB disk space, 4 vCPU, 8 GB memory.
    • 6 TB backup datastore, 9 TB disk space, 4 vCPU, 10 GB memory.
    • 8 TB backup datastore, 12 TB disk space, 4 vCPU, 12 GB memory.
  • The backup datastore can be extended after deployment, up to the maximum size of 8 TB per appliance.
  • For assistance with sizing the appliance for your environment see pages 27 and 28 of the vSphere Data Protection Administratrion Guide.
  • To avoid block size limitations the appliance should be deployed to VMFS5 or later.
  • Each vCenter Server supports up to 20 vSphere Data Protection appliances.
  • Each vSphere Data Protection appliance supports up to 400 virtual machines however…
  • The amount of virtual machines each appliance typically supports is 150 – 200. This is dependent on factors such as the virtual machine size, the amount of changed data, and the date retention period.
  • By default Data Protection can backup machines utilising SAN, NAS, or VSAN datastores.
  • For hosts using DAS, or hosts in remote locations, external proxies can be deployed as virtual appliances from the VDP UI.
  • Up to 8 proxies can be deployed per vSphere Data Protection appliance.
  • Review the vSphere Data Protection 6.1.x Release Notes and vSphere Data Protection Administratrion Guide.


  • The table below lists the supported vCenter Server versions for 6.1 variations of vSphere Data Protection.


  • If you are using vCenter 5.5 U3 with Data Protection 6.1, 6.1.1, or 6.1.2, see this kb.
  • All variations of Data Protection 6.1.x support ESXi 5.1 through to ESXi 6.0 U2. For ESXi 6.5 version 6.1.3 of Data Protection should be used.
  • To check compatibility with any other VMware products see the Product Interoperability Matrix.
  • Editions of vSphere Essentials Plus and above (or vSphere with Operations Management / vCloud Suite) include licensing for vSphere Data Protection.
  • FQDN resolution must be in place. A forward and reverse DNS entry needs manually adding.
  • A static IP address is required for the VDP appliance and any additional proxy appliances.
  • The vCenter Server and attached ESXi hosts must be configured with an NTP server. The VDP appliance pulls the time configuration from vSphere.
  • The following disk types are unsupported: independent, RDM independent (virtual compatibility mode), and RDM physical compatibility mode.
  • Each virtual machine to be backed up should be running VMware Tools and hardware v7 or above.

Install VDP

Download the VMware vSphere Data Protection OVA here. The ISO is used for upgrades. Browse to the vSphere web client and right click the cluster where the virtual appliance will reside. Click Deploy OVF Template. Browse to the downloaded OVA file and click Next.


Review the OVF template details and click Next.


Accept the EULA and click Next.


Enter a name for the virtual appliance and select a location, click Next.


Select the datastore for the virtual appliance and click Next. Select the VM network to use and click Next.


Enter the network settings for the virtual appliance. Review the summary page, tick the Power on after deployment box and click Finish.


Configure VDP

DNS values for forward and reverse lookup must be in place for the configuration wizard. Manually add a DNS host record for the IP address of the virtual appliance and the desired host name and domain.

After deployment browse to https:\\:8543/vdp-configure, where is the IP address or FQDN of the vSphere Data Protection appliance. Log in with the root default password changeme.


The configuration wizard will load, click Next.


Enter a host name and domain for the appliance. The network settings are auto- populated, click Next. If DNS forward and reverse lookup values are not in place the wizard will fail at this point.


Select a time zone and click Next.


Configure a new root password for the virtual appliance and click Next.


Enter the vCenter Server details and click Test Connection. If successful click Next.


Select the size of the datastore to create for backup data, click Next.


Select the storage to use and the provisioning type, click Next. Accept the default CPU and memory allocations and click Next.


Select or leave the Customer Experience Improvement Program check box and click Next.


Select whether or not to run performance analysis on the storage configuration. The performance analysis tests the read, write, and seek speeds of the underlying storage. Once ready click Next to apply the changes. Click Yes to confirm. The virtual appliance will now be reconfigured and rebooted.


This process can take around 15 minutes depending on your infrastructure. When the appliance is back online a VDP icon will be added to the home page of the vSphere web client, default alarms are also added.


To view and change settings related to the virtual appliance you can log back into https:\\:8543/vdp-configure, where is the IP address or FQDN of the vSphere Data Protection appliance.


The installation is now complete and you can begin scheduling backup jobs using the Create Backup Job wizard.


vSphere Distributed Switches

In vSphere networking a Distributed Switch provides centralised management for network configuration across all hosts associated to the Distributed Switch. A vSphere switch is made up of a data plane and a management plane. The data plane resides on each ESXi host and implements package switching, tagging, etc. In a vSphere Standard Switch the management plane also resides on each host, therefore each host must be configured individually which is time consuming, and prone to errors or different configuration standards. The vSphere Distributed Switch separates the management plane using the vCenter Server. By separating the management plane from the data plane we can define functionality, configuration, and standardisation across the ESXi estate.

The following image shows the architecture of a Distributed Switch, from the VMware vSphere 6.5 Documentation Centre. In this post we will walk through the setup of a vSphere Distributed Switch. A vCenter Server and vSphere Enterprise Plus licensing is required, you can sign up for a 60 day trial here.


Create a vSphere Distributed Switch

Open the vSphere web client and right click the datacentre object, select Distributed Switch, New Distributed Switch. The wizard will load, enter a name for the Distributed Switch and click Next.


Select the version to use and click Next. Ensure you use a version compatible with all ESXi hosts that are going to be connected to the Distributed Switch. The version can be upgraded non-disruptively, but cannot be downgraded. If you select an older version then the features listed in newer releases are not available, until such time as the Distributed Switch is upgraded.


Configure the number of uplinks to use. An uplink is a template used to configure physical network adapters mapped from the ESXi host. We assign networks or policies to an uplink to ensure standardisation; as these are propagated to consistent physical NICs of the hosts associated with the Distributed Switch. Make sure the hosts that will use the Distributed Switch have sufficient physical NICs to meet the specified number of uplinks.

Enter a datacentre-unique name for your new port group. Distributed port groups contain networks used by virtual machines and VMkernel traffic. Settings such as NIC teaming, failover, load balancing, VLAN, security, traffic shaping , and other policies are configured on distributed port groups. Click Next.


Review the summary page and click Finish. The Distributed Switch will now be created.


Add Hosts

In the vSphere inventory click the networking tab and select the new Distributed Switch.


Open the Configure tab and select Properties under the Settings menu. You can change the default settings of the virtual switch if required by clicking Edit. Read more about the properties here.


We will now add some hosts to our new switch; from the drop down Actions menu select Add and manage hosts. Click Add hosts and Next to continue.


Click New hosts and select the hosts to associate with the Distributed Switch. If you add multiple hosts and want to configure standardised network settings then tick the template mode box. Click Next.


An additional page is added to the wizard, select the host to use as a template and click Next. We will configure the network settings on this host to be copied to all other hosts associated with the Distributed switch.


Select the tasks to manage, in this example we will configure physical adapters to use for uplinks so select Manage physical adapters and click Next. Each option adds a new configuration page to the wizard.


In the Manage physical network adapters page we assign uplinks to physical NICs. Select the physical NIC, e.g. vmnic1, and click Assign uplink. Assign a physical adapter to each uplink, the number of uplinks was determined when creating the Distributed Switch. In this example since we are using template mode we assign the uplinks and then click Apply to all. This sets the same physical network adapter settings on the other hosts. Click Next.


Review the impact on network dependent services, such as iSCSI. If everything is green click Next.


Review the summary page and click Finish.


Add Distributed Port Groups

The next step is to add network configuration, known as port groups. A port group specifies port configuration options, defining how a network connection is made. The port group can contain security policies, traffic shaping policies, VLAN configuration, and so on. When a port group is created it can be used by all hosts associated with the Distributed Switch.

Right click the Distributed Switch and select Distributed Port Group. We can alter the default port group created with the Distributed Switch by selecting Manage Distributed Port Groups. Select the policies to edit and click Next.


Click Select distributed port groups and add the default port group created earlier. Click Next and follow the wizard to configure as required.


We can add new port groups by right clicking the Distributed Switch and selecting Distributed Port Group, New Distributed Port Group. Enter name for the port group and click Next.


Configure the settings for the port group, in this example I have configured a port group tagged with VLAN 10. Click Next.


Click Finish. Repeat the process if multiple port groups are required.


Virtual machines can now be provisioned to use the networks defined in the distributed port groups. You can find out more about Distributed Switch configuration and advanced settings in the vSphere 6.5 Documentation Centre, or the VMUG Wiki.

Configuring vCenter 6.5 High Availability

The vCenter Server Appliance now provides vCenter High Availability (HA) with vSphere 6.5 onwards. By implementing vCenter HA you can protect your vCenter from host and hardware failures, and significantly reduce down time during patching due to the active / standby nature of the vCenter cluster. In vSphere 6.7 Update 1 onwards the vCenter HA configuration is simplified, see Configuring vCenter 6.7 High Availability for more information.

The vCenter HA architecture is made up of the components in the vSphere image below. The vCenter Server Appliance is cloned out to create passive and witness nodes. Updated data is replicated between the active and passive nodes. In the event of an outage to the active vCenter the passive vCenter automatically assumes the active role and identity. Management connections still route to the same IP address and FQDN, however they have now failed over to the replica node. When the outage is resolved and the vCenter that failed comes back online; it then takes on the role of the passive node, and receives replication data from the active vCenter Server.




  • vCenter HA was introduced with the vCenter Server Appliance 6.5
  • The vCenter deployment size should be at least small, and therefore 4 vCPU 16 GB RAM
  • A minimum of three hosts
  • The hosts should be running at least ESXi 5.5
  • The management network should be configured with a static IP address and reachable FQDN
  • SSH should be enabled on the VCSA
  • A port group for the HA network is required on each ESXi host
  • The HA network must be on a different subnet to the management network
  • Network latency between the nodes must be less than 10ms
  • vCenter HA is compatible with both embedded deployment model and external PSC
  • For further information on vCenter HA performance and best practises see this post

Configuration Types

When setting up vCenter HA we are given the option of basic configuration or advanced. The correct deployment type depends on your environment. If the VCSA is managing its own ESXi host and virtual machine, or is managed by another vCenter Server in the same SSO domain then the basic deployment method should be used. This automatically clones the vCenter, and creates DRS anti-affinity rules.

If the VCSA is on a separate vCenter in a different SSO domain then the advanced deployment method should be used. In this case we need to manually add an additional NIC and clone the VCSA. The basic and advanced configuration types produce the same end result, but with a different process for different environments.

Both the embedded PSC and external PSC deployment models are supported. In this post we will walk through the advanced and basic configuration steps for vCenter with embedded PSC. For external PSC a load balancer can be implemented to provide HA, you can read more about implementing vCenter HA with the external deployment model here. If you are configuring vCenter HA in a cluster with less than the required number of physical hosts, such as in a home lab, you can add a parameter to override the anti-affinity setting; see this post by William Lam.

Basic Configuration Process

Log into the vSphere web client. Right click the top level vCenter Server in the inventory and select vCenter HA Settings. Click Configure in the top right hand corner.


Select the configuration type, in this example we are going to use Basic. Click Next.


An additional NIC will automatically be added to the active VCSA. Select the HA network to use and enter an IP address, remember this must be a separate subnet to the management network or the configuration wizard will error. Click Next.


Once the configuration wizard is complete the active VCSA will be cloned to create passive, and witness nodes. On this page we need to specify the HA IP addresses to use for each node, then click Next. You do not need to manually add any NICs during the basic configuration, this is all done for you. However as per the pre-requisites you do need to make sure a network is available to use for HA traffic.


Review the deployment page, if applicable you may need to change the compute or datastore locations by clicking Edit to ensure each component is spread across the vSphere cluster.


As you can see on the final page clone tasks will automatically be created. The new VMs are named VCSA-peer and VCSA-witness, where VCSA is the VM name of your current vCenter Server Appliance. Click Finish.


Monitor the tasks pane, vCenter HA may take around 5 minutes to clone and deploy the cluster nodes, depending on the speed of your underlying infrastructure. Once complete the vCenter HA status will show Enabled, and all nodes in the cluster will show Up.


You can edit the status of vCenter HA at any time by going back into the vCenter HA menu and clicking Edit. These are the available options.


Advanced Configuration Process

The advanced deployment process takes longer as it involves much more manual configuration. The first thing we need to do is add an additional network adapter to our existing vCenter Server Appliance, and configure a vCenter HA IP address. Log into the vSphere web client of the vCenter managing the VCSA. Locate and right click the VCSA, select Edit Settings. From the New device drop down select Network and click Add. Select the port group to use, remember this needs to be a separate subnet to the management network, ensure Connect is ticked and click Ok.

Now we can configure the network settings using the Appliance Management portal. Browse to https:// :5480 where is the IP address or FQDN of your vCenter Server Appliance. Log in with the root password.


Select Networking on the left hand navigation menu.


Open the Manage tab and click Edit next to the Networking Interfaces box. Expand nic1, note that the status is down, configure the IP settings and click Ok.


Verify that nic1 is now showing a status of Up.


We can now start the vCenter HA configuration wizard. Open the vSphere web client of the VCSA for which you want to configure HA. Right click the top level vCenter Server in the inventory and select vCenter HA Settings. Click Configure in the top right hand corner.


Select the configuration type, in this example we are going to use Advanced. Click Next.


Enter the IP address settings for the passive and witness nodes, on the HA network, then click Next.


Now we need to do some manual cloning, go back to the vSphere client of the vCenter Server managing the VCSA. Locate the VCSA in the inventory, right click and select Clone, Clone to Virtual Machine.

Run through the clone wizard, let’s create the passive node first. During the clone wizard we configure all settings, including management IP address and host name, to be the same as the active VCSA except for the HA IP address. Each node has a unique IP address on the HA network.

  • Enter a name and location for the virtual appliance.
  • Select different compute resource and datastores to the active VCSA if possible.
  • On the clone options page select Customise the operating system, Power on virtual machine after creation.


  • On the customise guest OS page click the create new specification icon.
  • Enter a name and description for the new customisation.


  • Enter the same OS host name and domain as the active node.
  • Configure the same time zone as the active node.
  • On the network page edit the settings for NIC1, select use the following IP settings, and enter the management network settings of the active vcsa. This network adapter will be used to assume the identity of the active VCSA in the event of a fail over.


  • Edit the settings for NIC2, select prompt the user for an address when the specification is used. Enter the subnet mask and leave the gateway blank. This adapter will be used for the HA network, we will configure the unique IP address shortly.


  • On the DNS and domain settings page of the wizard enter the domain name and DNS server(s) that the interface will connect to, click Finish.
  • You will be returned to the clone virtual machine wizard. Select the newly created customisation profile.
  • Enter the IP address for NIC1. This is the HA IP for the passive node we input during the vCenter HA configuration wizard earlier.


  • Accept the default virtual hardware and vApp properties.

The VCSA will now be cloned to create the passive node. Repeat the steps above for the witness node, however this time select the existing guest customisation that we created first time round.


Enter the unique HA IP address for the witness node that we specified during the vCenter HA configuration wizard.


When these manual steps have been completed go back to the vCenter HA configuration wizard and click Finish. Monitor the Configure a vCenter HA Cluster task in the recent tasks pane.


Once complete the vCenter HA status will show Enabled, and all nodes in the cluster will show Up.


For more information on vCenter HA or configuring different aspects of the advanced deployment; see the vCenter High Availability section of the vSphere 6.5 Documentation Centre.

The final step is to configure an anti-affinity rule to stop the vCenter Server appliances from running on the same hosts. Log into the vSphere web client and browse to Hosts and Clusters. Click the vSphere cluster and select the Manage tab. Under Configuration click VM/Host Rules. Under VM/Host Rules click Add.

Enter a name for the rule, such as vCenter HA, ensure Enable rule is ticked and select Separate Virtual Machines as the rule type. Click Add and select the vCenter Server nodes. Click Ok.


This rule will ensure DRS does not place nodes on the same hosts in a vSphere cluster.

vCenter Appliance 6.5 Upgrade

VMware vCenter Server pools ESXi host resources to provide a rich feature set delivering high availability and fault tolerance to virtual machines. The vCenter Server is a centralised management application and can be deployed as a virtual appliance or Windows machine. This post walks through an upgrade of the vCenter Server Appliance from v5.5 or v6.0 to v6.5. See also vCenter Server Appliance 6.5 Install Guide, or Migrating Windows vCenter Server.

The latest vSphere version is now 6.7, updated posts:

vCenter Server Appliance 6.7 Install Guide

Windows vCenter Server 6.7 Install Guide

Migrating Windows vCenter Server to VCSA 6.7

About VCSA

The VCSA is a pre-configured virtual appliance; as of v6.5 the operating environment is built on Project Photon OS 1.0. Since the OS has been developed by VMware it benefits from enhanced performance and boot times over the previous Linux based appliance. Furthermore the embedded Postgre database means VMware have full control of the software stack, resulting in significant optimisation for vSphere environments and quicker release of security patches and bug fixes. The VCSA scales up to 2000 hosts and 35,000 virtual machines.

In vSphere 6.0 the VCSA reached feature parity with its Windows counterpart, 6.5 begins to pave the way for VCSA to become the preferred deployment method for vCenter Server. One key addition is the inclusion of Update Manager bundled into the VCSA, as well as vCenter High Availability, Backup and Restore, and other features. The appliance also saves operating system license costs and is quicker and easier to deploy and patch.

Upgrading to VCSA 6.5 involves the deployment of a new appliance and migration of all configuration and historical data (optional) using the upgrade installer. The VCSA uses a temporary IP address during migration before switching to the IP and host name of the new VCSA, the old appliance is then powered off.


Software Considerations

  • VCSA 6.5 must be deployed to an ESXi host running v5.5 or above. All hosts you intend to connect to vCenter Server 6.5 should also be running ESXi v5.5 or above.
  • The VCSA to be upgraded can be either v5.5 or v6.0.
  • VCSA 6.5 does not support the use of an external database. Where a system using an external database is upgraded, the data is imported into the internal Postgres database within VCSA 6.5.
  • You must check compatibility of any third party products and plugins that might be used for backups, anti-virus, monitoring, etc. as these may need upgrading for use with vSphere 6.5.
  • If you are unsure check the Product Interoperability Matrix.

Architectural Considerations

  • From vSphere 6 onwards the Platform Services Controller (PSC) was introduced to the vSphere architecture. The PSC contains infrastructure services such as Single Sign On, Certificate Authority, licensing, etc. The PSC is deployed internally with vCenter Server or as an external component. Read more about the PSC in this KB.
  • When implementing a new vSphere 6.5 environment you should plan your topology in accordance with the VMware vCenter Server and PSC Deployment Types. Larger environments may require an external PSC.
  • When upgrading vCenter the deployment model already in place will be migrated, the upgrade supports different deployment topologies but can not make changes to the topology and SSO domain configuration.
  • In this post we will be upgrading vCenter Server 6.0 using the embedded deployment model. If you are using an external deployment model the PSC appliance must be upgraded before the vCenter Server.
  • Consider if the default self-signed certificates are sufficient or if you want to replace with custom CA or VMware CA signed certs, see Installing vCenter Internal CA signed SSL Certificates for more information.


Other Considerations

  • VCSA 6.5 with embedded PSC requires the following hardware resources (disk can be thin provisioned)
    • Tiny (up to 10 hosts, 100 VMs) – 2 CPUs, 10 GB RAM.
    • Small (up to 100 hosts, 1000 VMs) – 4 CPUs, 16 GB RAM.
    • Medium (up to 400 hosts, 4000 VMs) – 8 CPUs, 24 GB RAM.
    • Large (up to 1000 hosts, 10,000 VMs) – 16 CPUs, 32 GB RAM.
    • X-Large (up to 2000 hosts, 35,000 VMs) – 24 CPUs, 48 GB RAM – new to v6.5.
  • Storage requirements for the smallest environments start at 250 GB and increase depending on your specific database requirements. See the Storage Requirements document for further details.
  • Where the PSC is deployed as a separate appliance this requires 2 CPUs, 4 GB RAM, 60 GB disk.
  • Environments with ESXi host(s) with more than 512 LUNs and 2048 paths should be sized large or x-large.
  • The ESXi host on which you deploy the new appliance should not be in lockdown or maintenance mode.
  • All vSphere components should be configured to use an NTP server. The installation can fail or the vCenter Server Appliance vpxd service may not be able to start if the clocks are unsynchronized.
  • FQDN resolution should be in place when deploying vCenter Server.
  • Review the list of Required Ports for vCenter Server and PSC.
  • Official resources – vSphere 6.5 Documentation Centre, vSphere 6.5 Release Notes.
  • Read the Important information before upgrading to vSphere 6.5 KB.


Download the VMware vCenter Server Appliance 6.5 ISO from VMware downloads: v6.5.0 | v6.5.0 U1.

Unlike the Windows vCenter installer, which hasn’t changed much in v6.5; the VCSA installer has had a complete overhaul. You’ll notice straight away that the GUI is much cleaner, and multiple deployment options (install, upgrade, migrate, restore) are now bundled into one installer.

Mount the ISO on your computer. The VCSA 6.5 installer is compatible with Mac, Linux, and Windows. Browse to the corresponding directory for your operating system, e.g. \vcsa-ui-installer\win32. Right click Installer and select Run as administrator. As we are upgrading an existing system click Upgrade.


The installation is split into 2 stages, we begin with deploying a new appliance. The second stage migrates all data and settings. Click Next.


Accept the EULA and click Next.


Enter the details for the existing vCenter Server Appliance and the host or vCenter it is managed by. Click Next.


Enter the FQDN or IP address of the host, or vCenter upon which you wish to deploy the new VCSA, then click Next. The installer will validate access, if prompted with an untrusted SSL certificate message click Yes to continue. Tip – connect to the vCenter for visibility of any networks using a distributed switch, connecting to the host direct will only pull back networks using a standard switch.


Enter a VM name and root password for the new appliance, and click Next.


Configure the deployment size of the new appliance and click Next.


Select the datastore to locate the virtual appliance and click Next. Configure the temporary network settings for the appliance. These will only be used during migration of the data, once complete the temporary settings are discarded and the VCSA assumes the identity, including IP settings, of the old appliance. Click Next.


The new VCSA will now be deployed, once complete click Finish.


Stage 2 migrates data and identity across to the new VCSA, click Next.


Select the data to migrate and click Next.


Select whether or not to join the VMware Customer Experience Improvement Program and click Next.


Review the summary page, confirm you have taken a backup of the vCenter and click Finish.Click OK to the shut down warning.


Data will now be migrated to the new VCSA, once complete the old VCSA will be powered off and the network settings transferred.


When finished click Close, the vCenter upgrade is complete.



Connect to the vCenter post install using the IP or FQDN of the vCenter. Access vSphere by clicking either the vSphere Web Client (Flash) or the vSphere Client (HTML5). Connect to the vSphere Web Client to manage your system, the thick client (Windows) is no longer supported.


Log in to the vSphere Web Client using the SSO administrator login. Verify the installed version is correct under the Summary tab when selecting the vCenter, you can also go to Help > About.


You must apply a new vCenter license key within 60 days. From the Hosts and Clusters view select the vCenter Server. Click Actions and Assign License. Select a license or use the green plus button to add a new license and click Ok.

You can obtain a 60 day trial license for vCenter Server here. If you have purchased vCenter Server then log into your licensing portal here. If the license key does not appear then check with your VMware account manager.