vCenter Server Appliance 6.7 Install Guide

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. It should be noted that vCenter 6.7 is the final release where Windows modules will be available, see here for more information. All future releases will only be available as vCenter Server Appliance (VCSA) which is the preferred deployment method of vCenter Server. An existing Windows vCenter can be migrated to VCSA by following the steps in Migrating Windows vCenter Server to VCSA 6.7 This post gives a walk through on a clean installation of VCSA 6.7.

vCenter 6.7: Download | Release Notes | What’s New | VMware DocsvSphere Central

468x60 vmware

About VCSA

migrate2vcsaThe VCSA is a pre-configured virtual appliance built on Project Photon OS. 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 vPostgres 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. A couple of releases ago the VCSA reached feature parity with its Windows counterpart, and is now the preferred deployment method for vCenter Server. Features such as Update Manager are bundled into the VCSA, as well as file based backup and restore, and vCenter High Availability. The appliance also saves operating system license costs and is quicker and easier to deploy and patch.

Software Considerations

  • VCSA 6.7 must be deployed to an ESXi host or vCenter running v5.5 or above. However, all hosts you intend to connect to vCenter Server 6.7 should be running ESXi 6.0 or above, hosts running 5.5 and earlier cannot be managed by vCenter 6.7 and do not have a direct upgrade path to 6.7.
  • 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 vSphere 6.7 compatibility.
  • To check version compatibility with other VMware products see the Product Interoperability Matrix.
  • The points above are especially important since at the time of writing vSphere 6.7 is new enough that other VMware and third party products may not have released compatible versions. Verify before installing vSphere 6.7 and review the Release Notes and Important information before upgrading to vSphere 6.7 KB.

Architectural Considerations

  • When implementing a new vSphere 6.7 environment you should plan your topology in accordance with the VMware vCenter Server and Platform Services Controller Deployment Types.
  • A series of videos covering vCenter Server and Platform Services Architecture can be found here. If you require further assistance with vCenter planning see also the vSphere Topology and Upgrade Planning Tool here,
  • Most deployments will include the vCenter Server and PSC in one appliance, following the embedded deployment model, which I will use in this guide.
  • Greenfield deployments of vSphere 6.7 can take advantage of Embedded PSC with Enhanced Linked Mode, providing native vCenter Server HA support, and removal of SSO site boundaries.
  • 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.

embedded

Other Considerations

  • The VCSA 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 VCSA 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.
  • A list of Required Ports for vCenter Server and PSC can be found here.
  • The configuration maximums for vSphere 6.7 can be found here.
  • In vSphere 6.7 TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default, review the Release Notes for more information.
  • There are a number of Intel and AMD CPUs no longer supported with vSphere 6.7, review the Release Notes for a full list of unsupported processors.

Installation

Download the VMware vCenter Server Appliance 6.7 ISO from VMware downloads: v6.7.0.

Mount the ISO on your computer. The VCSA 6.7 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.

VCSA_1

The installation is split into 2 stages, we begin with deploying the appliance. Click Next.

VCSA_2

Accept the license agreement and click Next.

VCSA_3

Select the deployment model, in this example we will be using an embedded deployment combining the vCenter Server and Platform Services Controller in one appliance, click Next.

VCSA_4

Enter the FQDN or IP address of the host, or vCenter upon which you wish to deploy the new VCSA. Enter the credentials of an administrative or root user and 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.

VCSA_5

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

VCSA_6

Select the deployment size in line with the number of hosts and virtual machines that will be managed, click Next.

VCSA_7

Select the datastore where the VCSA will be deployed, select thin provisioning if required, and click Next. Configure the network settings for the appliance and click Next.

VCSA_8

On the summary page click Finish. The appliance will now be deployed.

VCSA_9

With the VCSA now deployed we can move on to stage 2, click Continue.

VCSA_10

Click Next to being the VCSA setup.

VCSA_11

Configure the NTP servers, enable SSH access if required, and click Next.

VCSA_12

Enter a unique SSO domain name, the default is vsphere.local. The SSO domain name should not be the same as your Active Directory Domain. Configure a password for the SSO administrator, click Next.

VCSA_13

Select or deselect the customer experience improvement program box and click Next.

VCSA_14

Review the details on the summary page and click Finish. Click Ok to acknowledge that the VCSA setup cannot be paused or stopped once started. When the installer is complete click Close to close the wizard.

Post-Installation

Connect to the vCenter post install using the IP or FQDN of the vCenter. Access vSphere by clicking either Launch vSphere Client (HTML5) or Launch vSphere Web Client (FLEX). As the web client will be depreciated in future versions, and the HTML5 client is now nearly at full feature parity, we will use the HTML5 vSphere client.

Windows_vCenter67_14

You must apply a new vCenter license key within 60 days. 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. Log in to the vSphere Web Client using the SSO administrator login.  From the Menu drop-down click Administration,

Windows_vCenter67_16

Under Licensing select Licenses. First we need to add a new license key, click Add New Licenses. Enter the new license key for vCenter Server, click Next. If applicable assign a name to the licence, click Next. Click Finish to add the license key.

Windows_vCenter67_15

Switch to Assets, the vCenter Server is listed in evaluation mode. Highlight the vCenter and click Assign License. Select the license key and click Ok.

Windows_vCenter67_17

If you have an Active Directory domain then vCenter can use this as an identity source. First ensure the vCenter is joined to the domain; from the Menu drop-down click Administration. Under Single Sign On click Configuration. Select the Active Directory Domain tab and verify the vCenter is domain joined. Change to the Identity Sources tab and click Add Identity Source. Fill in the Active Directory details for your domain and click Ok.

Windows_vCenter67_18

You can now add permissions to vCenter objects such as datacenters, clusters, folders, individual virtual machines, etc. for Active Directory users and groups. To learn more about vSphere permissions click here.

To start adding ESXi hosts to vCenter click the Menu drop-down and select Hosts and Clusters. Right click the vCenter and select New Datacenter, give the datacenter a name and click Ok. Right click the datacenter and select Add Host. Follow the onscreen wizard to add a host. Creating clusters and configuring vCenter is beyond the scope of this post, for assistance follow the documentation links at the top of the page.

Windows_vCenter67_19

Windows vCenter Server 6.7 Install Guide

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. It should be noted that vCenter 6.7 is the final release where Windows modules will be available, see here for more information. All future releases will only be available in VCSA form, if you have not already started planning migration to VCSA see vCenter Server Appliance 6.7 Install Guide and Migrating Windows vCenter Server to VCSA 6.7. This post gives a walk through on a clean installation of vCenter Server 6.7 on Windows Server 2016.

vCenter 6.7: Download | Release Notes | What’s New | VMware DocsvSphere Central

Software Considerations

  • The operating system should be 64 bit and Windows Server 2008 SP2 or above.
  • For environments with up to 20 hosts and 200 VMs the bundled internal PostgreSQL database can be used.
  • If an external database is used it should be Microsoft SQL Server 2008 R2 SP2 or above, or Oracle 11g or 12c. You can review a full list of compatible versions at the Database Interoperability Matrix.
  • The account used for external database authentication requires Oracle DBA role, or SQL sysadmin server role, or db_owner fixed database role. For a full list of explicit permissions review the Database Permission Requirements.
  • 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 vSphere 6.7 compatibility.
  • Any hosts you want to add to vCenter 6.7 should be running version 6.0 or above, 5.5 and earlier will not work and do not have a direct upgrade path to 6.7.
  • To check version compatibility with other VMware products see the Product Interoperability Matrix.
  • The points above are especially important since at the time of writing vSphere 6.7 is new enough that other VMware and third party products may not have released compatible versions. Verify before installing vSphere 6.7 and review the Release Notes and Important information before upgrading to vSphere 6.7 KB.

Architectural Considerations

  • As noted above the Windows modules will not be included for future versions, therefore the recommended installation method for vCenter 6.7 is the vCenter Server Appliance (VCSA).
  • When implementing a new vSphere 6.7 environment you should plan your topology in accordance with the VMware vCenter Server and Platform Services Controller Deployment Types.
  • A series of videos covering vCenter Server and Platform Services Architecture can be found here. If you require further assistance with vCenter planning see also the vSphere Topology and Upgrade Planning Tool here,
  • Most deployments will include the vCenter Server and PSC on one server, following the embedded deployment model, which I will use in this guide.
  • Greenfield deployments of vSphere 6.7 can take advantage of Embedded PSC with Enhanced Linked Mode, providing native vCenter Server HA support, and removal of SSO site boundaries.

embedded

Hardware Considerations

  • A Windows based vCenter Server can be installed on either a physical or virtual machine. Windows vCenter Server with embedded PSC requires the following hardware resources:
    • 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.
  • Where the PSC is deployed on a separate machine this requires 2 CPUs, 4 GB RAM.
  • Environments with ESXi host(s) with more than 512 LUNs and 2048 paths should be sized large or x-large.
  • The Windows vCenter Server requires the following free disk space for installation: (the first 2 may not necessarily be the system drive depending on installation location) Program Files 6 GB, Program Data 8 GB, System folder 3 GB. The PSC machine requires; Program Files 1 GB, Program Data 2 GB, System folder 1 GB.
  • There are a number of Intel and AMD CPUs no longer supported with vSphere 6.7, review the Release Notes for a full list of unsupported processors.

Other Considerations

  • It may be necessary to temporarily stop any third party software which could interfere with the installer, such as anti-virus scanner.
  • If the vCenter Server services are running as a user other than the Local System account then the user must be a member of the administrators group and have the following permissions; log on as a service, act as part of the operating system.
  • Verify that the local machine policy allows assigning Log on as a batch job rights to new local users.
  • All vSphere components should be configured to use the same NTP server.
  • FQDN resolution should be in place when deploying vCenter Server.
  • A list of Required Ports for vCenter Server and PSC can be found here.
  • The configuration maximums for vSphere 6.7 can be found here.
  • In vSphere 6.7 TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default, review the Release Notes for more information.

Create Data Source

Before beginning if you intend to use vCenter Server with an external SQL database you must configure a 64-bit ODBC data source for external databases. You may also need to install the Microsoft ODBC Driver for SQL Server. ODBC Data Source Administrator can be accessed via Control Panel > Administrative Tools. Click System DNS, Add and input the details for the external database, test the data source before continuing. If you are using the internal Postgres database then the System DSN is added automatically during installation.

odbc

Installation

Download the VMware vCenter Server and Modules for Windows ISO from VMware downloads: v6.7.0.

Mount the ISO and right click autorun.exe, select Run as administrator. The VMware vCenter Installer will open. Ensure vCenter Server for Windows is selected and click Install.

Windows_vCenter67_1

The vCenter Server 6.7 Installer will open in a separate window, click Next.

Windows_vCenter67_2

Accept the end user license agreement and click Next.

Windows_vCenter67_3

In this guide we will be using an embedded deployment model. If you are using an external deployment model the PSC component must be installed first before the vCenter. Select the deployment type and click Next. If the Windows server does not have sufficient resources allocated the installer will error at this stage.

Windows_vCenter67_4

Enter the FQDN in the System Name field and click Next.

Windows_vCenter67_5

Create a new Single Sign-On domain, or join the vCenter to an existing SSO domain. If you are creating a new SSO domain either leaves as the default vsphere.local or create a new SSO domain name, (not the same as your Active Directory name). Configure a password for the SSO administrator account and a vCenter specific site name, click Next. Note: vCenter 6.7 is the last release where a SSO site name will need to be provided.

Windows_vCenter67_6

Select whether to run vCenter services as the local system account or enter details of a service account and click Next. Ensure the account running vCenter services has been granted permissions as per the other considerations section of this guide.

Windows_vCenter67_7

Select an embedded Postgre database or point the installer to the DSN for an external database, click Next.

Windows_vCenter67_8

Accept the default port configuration and click Next.

Windows_vCenter67_9

Select the directory to install vCenter services and click Next.

Windows_vCenter67_10

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

Windows_vCenter67_11

Check the configuration on the review page and click Install to begin the installation process.

Windows_vCenter67_12

Once the installation has completed click Finish.

Windows_vCenter67_13

Post-Installation

Connect to the vCenter post install using the IP or FQDN of the vCenter. Access vSphere by clicking either Launch vSphere Client (HTML5) or Launch vSphere Web Client (FLEX). As the web client will be depreciated in future versions, and the HTML5 client is now nearly at full feature parity, we will use the HTML5 vSphere client.

Windows_vCenter67_14

You must apply a new vCenter license key within 60 days. 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. Log in to the vSphere Web Client using the SSO administrator login.  From the Menu drop-down click Administration,

Windows_vCenter67_16

Under Licensing select Licenses. First we need to add a new license key, click Add New Licenses. Enter the new license key for vCenter Server, click Next. If applicable assign a name to the licence, click Next. Click Finish to add the license key.

Windows_vCenter67_15

Switch to Assets, the vCenter Server is listed in evaluation mode. Highlight the vCenter and click Assign License. Select the license key and click Ok.

Windows_vCenter67_17

If you have an Active Directory domain then vCenter can use this as an identity source. First ensure the vCenter is joined to the domain; from the Menu drop-down click Administration. Under Single Sign On click Configuration. Select the Active Directory Domain tab and verify the vCenter is domain joined. Change to the Identity Sources tab and click Add Identity Source. Fill in the Active Directory details for your domain and click Ok.

Windows_vCenter67_18

You can now add permissions to vCenter objects such as datacenters, clusters, folders, individual virtual machines, etc. for Active Directory users and groups. To learn more about vSphere permissions click here.

To start adding ESXi hosts to vCenter click the Menu drop-down and select Hosts and Clusters. Right click the vCenter and select New Datacenter, give the datacenter a name and click Ok. Right click the datacenter and select Add Host. Follow the onscreen wizard to add a host. Creating clusters and configuring vCenter is beyond the scope of this post, for assistance follow the documentation links at the top of the page.

Windows_vCenter67_19

Provisioning Virtual Machines with PowervRA

This post will walk through using PowervRA to provision virtual machines from vRA catalog items. PowervRA is a powerful tool allowing us to automate and customise vRA configuration and deployments by leveraging the RESTFUL API. We’ll cover requesting catalog items using both the default settings and with additional values or customisation using a JSON file. For more information review the PowervRA documentation here, the full syntax for Request-vRACatalogItem can be found here.

PowervRA can be installed direct from the PowerShell gallery.

Install-Module -Name PowervRA

Alternatively you can download from GitHub here, drop the PowervRA folder into C:\Program Files\WindowsPowerShell\Modules, and then import.

Import-Module PowervRA

Use Connect-vRAServer to establish a connection to the vRA appliance. This will prompt for a username and password.

Connect-vRAServer -Server <vRA Server> -Tenant <Tenant Name>
Connect-vRAServer -Server vralab01.corp.local -Tenant esxsi -IgnoreCertRequirements

You can also add the -Username switch and -Password switch, or -Credential to add a Powershell credential file. If you are using self signed certs add -IgnoreCertRequirements.

Use Get-vRACatalogItems to list all catalog items the user has access to. Add the -Name switch to list details for a specific catalog item. Make a note of the Id, this is required to request the catalog item.

Get-vRACatalogItem
Get-vRACatalogItem -Name <Catalog Item Name>
Get-vRACatalogItem -Name PSTestBlueprint

Use Request-vRACatalogItem to make the request, you can also add -Wait to wait for the request to complete, and -Verbose to show the event log.

Request-vRACatalogItem -Id <Catalog Item Id>
Request-vRACatalogItem -Id 78eddfcc-c9dd-4104-abd6-218b6ff1e9fa -Wait -Verbose 

We can even do something like:

$CatalogItemId = (Get-vRACatalogItem -Name PSTestBlueprint).Id
Request-vRACatalogItem -Id $CatalogItemId

powervra

In this scenario we want to go further and add values for some custom properties to the request. The request can be customised using a JSON file.

Output the catalog item properties to a JSON file for customisation.

Get-vRACatalogItemRequestTemplate -Name <Catalog Item Name> | Out-File path\file.json
Get-vRACatalogItemRequestTemplate -Name PSBlueprintTest | Out-File C:\requestTemplate.json

Set $json as the updated JSON file. You can verify this has worked and the contents of the JSON file using Write-Output.

$json = Get-Content path\file.json -Raw
$json = Get-Content C:\requestTemplate.json -Raw
Write-Output $json

powervra_1

Update and save the JSON file as required, for example adding the value for a custom property, or amending the CPU / memory allocation.

vra_json

We can now request the catalog item using the JSON file.

Request-vRACatalogItem -JSON $json

powervra_2

When the request is submitted either monitor through Powershell, if you used the verbose switch, or follow the status in the vRA portal as normal under the requests tab.

Setting Manual DFW Override for NSX Restore

The recommended restore process for NSX Manager is to deploy a new OVA of the same version, and restore the configuration. After a recent failed upgrade we needed to restore NSX Manager, so deployed a new OVA with the same network settings. After the new NSX Manager was powered on we were unable to ping the IP address, this was because there were no default rules allowing access to the VM, and since the existing NSX Manager was down we were unable to connect to the UI or API to add the required firewall rules. NSX Manager is normally excluded from Distributed Firewall (DFW) by default, however at this point the hosts saw it as any other VM, since we had not yet restored the configuration. Therefore we needed to add a manual override to clear the filters applied to the new NSX Manager, allowing us to connect and restore the configuration. The following commands were run on the host where the new NSX Manager OVA was deployed, using SSH. For further guidance on the backup and restore process of NSX see the NSX Backup and Restore post.

Disclaimer: the steps below are advanced commands using vsipfwcli which is an extremely powerful tool. You should engage VMware GSS if doing this on anything other than a lab environment, you should also understand the impact of stopping the vsfwd service on the host and the impact this may have on any other VMs with a DFW policy of fail closed.

net-stats -l lists the NIC details of the VMs running on the host, verify the new NSX Manager is present.

/etc/init.d/vShield-Stateful-Firewall stop stops the vsfwd user world agent, you can also use status to display the status.

vsfwd

summarize-dvfilter lists port and filter details, we need the port name for the VM, e.g. nic-38549-eth0-vmware-sfw.2.

DFW_1

vsipioctl getrules -f nic-38549-eth0-vmware-sfw.2 lists the existing filters applied to the port, replace the port name with your own, from the output check to confirm the ruleset name, e.g. ruleset domain-c17.

DFW_2

vsipioctl vsipfwcli -f nic-38549-eth0-vmware-sfw.2 -c "create ruleset domain-c17;" creates a new empty ruleset with the same name, overriding the previous ruleset applied to the port. Replace the port name with your own and the ruleset name if it is different.

vsipioctl getrules -f nic-38549-eth0-vmware-sfw.2 again lists the existing filters applied to the port, the ruleset should now be empty as no filters are applied.

DFW_3

The NSX Manager is now pinging and the normal restore process can resume; connect to the web interface by browsing to the IP address or FQDN of the NSX Manager.

Restore_NSX_1

Select Backup & Restore.

Restore_NSX_2

Select the appropriate restore point and click Restore. Click Yes to confirm.

Restore_NSX_3

The restore generally takes 5-10 minutes, once complete you will see a restore completed successfully message in a blue banner on the Summary page. You may need to log out and log back in after the config is restored.

Restore_NSX_4

Once the NSX Manager services have started you can manage the DFW from the vSphere web client as normal. Remember to start the vsfwd service again on the host, after the vsfwd service is started the empty ruleset we created earlier is replaced with the original ruleset when the host syncs with NSX Manager.

/etc/init.d/vShield-Stateful-Firewall start starts the vsfwd user world agent, you can also use status to display the status.

Updating ESXi Vendor Images with Latest Patches

This post will walk through updating a vendor specific ESXi image with updated VIBs. In this instance we are applying patch ESXi650-201803001 which bundles the esx-base, esx-tboot, vsan, and vsan health VIBs (ESXi650-201803401-BG) with the updated CPU microcode (ESXi650-201803402-BG), to provide part of the hypervisor-assisted guest mitigation for operating systems of the Branch Target Injection issue (CVE-2017-5715) commonly known as Spectre. The appropriate patches for ESXi 6.0 and 5.5 can be found in VMware Security Announcement VMSA-2018-0004.3 here.

For more information on Meltdown and Spectre see this blog post, VMwares responses can be found here, on the VMware Security & Compliance Blog here, as well as VMware Security Announcement VMSA-2018-0004 here. Ensure your vCenter Server is also patched accordingly by following the guidance in this post.

There are a number of ways to push out ESXi patches to hosts, such as CLI, Update Manager, Auto Deploy. The latest images can be downloaded from the patch repository here. As we are using vendor specific images, which are typically slow to be updated from the main VMware image, there is no vendor image available that mitigates against Spectre at the time of writing. Therefore the steps below will cover replacing VIBs in the HPE ESXi 6.5 image with the updated VIBs released by VMware. The same process can be used for other vendor images and ESXi versions by downloading the appropriate images, however the custom image we create may not be supported, and therefore may not be appropriate for production environments.

meltdown-spectre-vmware

The steps below assume Auto Deploy and Image Builder are already setup. You don’t need to use Auto Deploy to be able to use the Image Builder, but the services do need to be started, if they’re not then see the Auto Deploy Guide. Download the latest vendor image, in my case I am using HPE, and the latest ESXi build from the patch repository here.

Log into the vSphere web client and click the Auto Deploy icon from the home page.

Auto_Deploy

Click the Software Depots tab. Software depots contain images or software packages. If you don’t already have a custom software depot click the Add Software Depot icon to add a new custom depot where images will be stored. Use the Import Sofware Depot to upload a zip file, in this case we need to add the vendor image (in my case VMware-ESXi-6.5.0-Update1-7388607-HPE-650.U1.10.2.0.23-Feb2018-depot.zip) and the updated VMware image (ESXi650-201803001.zip).

Select the software depot containing the vendor image, in my case VMware-ESXi-6.5.0-Update1-7388607-HPE-650.U1.10.2.0.23-Feb2018-depot. Under Image Profiles select the vendor image and click Clone.

Auto_Deploy_2

We are cloning the vendor image to replace the updated VIBs. Enter a name and vendor for the image, select the software depot.

Image_Builder_2

On the next page the software packages are listed, those already included in the build are ticked. Ensure the Software depot is set to All depots in the drop-down.

Review the updated VIBs in the appropriate ESXi patch release.

ESXi650-201803401-BG:

  • VMware_bootbank_esx-base_6.5.0-1.41.7967591
  • VMware_bootbank_esx-tboot_6.5.0-1.41.7967591
  • VMware_bootbank_vsan_6.5.0-1.41.7547709
  • VMware_bootbank_vsanhealth_6.5.0-1.41.7547710

ESXi650-201803402-BG:

  • VMware_bootbank_cpu-microcode_6.5.0-1.41.7967591

Use the search function to find each of the updated VIBs. Un-select the existing version and select the new version to add it to the build.

Image_Builder_3

For the Spectre patches remember to include the CPU microcode.

Image_Builder_4

Once complete click Next and Finish. Select the custom software depot where the image has been created. The image is now ready to use with an Auto Deploy rule, or can be exported in ISO or ZIP format by right clicking and selecting Export Image Profile.

Image_Builder_5

For the Spectre updates after the new image has been installed/applied to an ESXi host we can perform some verification of the hypervisor-assisted guest mitigation. This blog post from virtuallyGhetto provides PowerCLI functions and instructions for validating the correct microcode and patches are present. In the example below I have updated host 1 but not host 2:

Verify_1

The virtual machines can also be validated to confirm they are seeing the new CPU features, a power cycle is required for each VM. Before power cycling:

Verify_2

After power cycling:

Verify_3

Altaro Continuous Data Protection

Altaro v7.6 introduces a Continuous Data Protection (CDP) feature which reduces data loss by providing Recovery Point Objectives (RPO) of up to 5 minutes. Altaro CDP works by saving a point in time copy of the virtual machine based on snapshots at set intervals, configurable per host or per virtual machine. The frequency options available are every 5 minutes, 15 minutes, 30 minutes, every hour, 4 hours, 8 hours, or 12 hours. Each version of a CDP backup is retained for 4 hours since the last successful backup, after this CDP backups are merged into a single recovery point and kept in accordance with your own configured retention policy.

Altaro v7.6 is available now, you can read about what is new in v7.6 here. CDP is initially available for Hyper-V, with VMware expected mid Q2 this year. This post will be updated when VMware CDP compatiblity is added.

Altaro_CDP_1

Configuring CDP

  • If you do not already have Altaro VM Backup installed see the Altaro VM Backup Install and Overview post. You can download a copy of Altaro here.
  • The CDP Settings option can be accessed from the navigation pane of the Altaro VM Backup management console, under Setup. Hosts that have been added to Altaro are listed, along with any discovered VMs.
  • Use the Enable CDP check box and Maximum Frequency drop down to configure CDP with the desired settings.

Altaro_CDP_2

  • When configuring CDP there should already be a backup schedule and backup location in place for the virtual machines. If you have not yet configured this part then see the install and overview post referenced above.
  • Click Save Changes to commit the CDP configuration.

Altaro_CDP_4

  • The first time you configure CDP backups the VM Backup management console will display a warning about the Backup Health Monitor. The Backup Health Monitor verifies the state of backup data, during which time backups cannot run.
  • Depending on your environment and desired configuration you can change the schedule of the Backup Health Monitor to not conflict with CDP backups.
  • Once CDP backups are in use they become available restore points for restoring virtual machines.

Altaro_CDP_3

  • The Backup Health Monitor can also be configured from the navigation pane under Sandbox & Configuration.

Altaro_CDP_5

In summary, Altaro CDP boosts business continuity by allowing administrators to recover to a more granular point in time; thereby reducing data loss from virtual machine restores. The feature is easy to configure and the frequency options provide near continuous data protection with the maximum data loss being up to 5 minutes, this along with application consistent backups should be sufficient protection for most business critcal applications. When planning implementation of a CDP model you should consider other factors such as network bandwidth, and hypervisor performance, for example having a high number of machines taking snapshots every 5 minutes on the same host may add a CPU/memory overhead.

Altaro v7.6 is available now, you can download here.

Changing Active Directory OU of vRA Provisioned Machines

In this post we will make use of ActiveDirectory.rename in the vRO Active Directory plugin to move a computer object to a new OU as a custom action from within the vRA portal. Although technically it isn’t quite Solarwinds integration with vRA, we can cheat by monitoring the new OU. In this setup we will have vRA provision machines to a standard unmonitored OU, and then have an action in the portal triggering a vRO workflow to move the computer account to a monitored OU.

Solarwinds_vRA

vRO Configuration

  • Log into the vRealize Orchestrator client and switch to Design view. Open the Workflows tab.
  • The steps below assume that an Active Directory server has been registered with vRA. If this is not the case then browse to Library, Microsoft, Active Directory, Configuration. Run the Add an Active Directory server workflow and enter the AD information. If successful the AD server should be listed in the Inventory tab under Active Directory.
  • Now from the Workflow tab right click the folder where the new workflow will be created and click New workflow. Enter a name for the new workflow and click Ok.
  • Enter a description if required. Under the Attributes header add a new attribute, give the attribute a name (in this case AD_Host) and change the type to AD:AdHost. The value will be the Active Directory host already configured as mentioned above.

New_Workflow_1

  • Click the Inputs tab. Add a new parameter, give the parameter a name (in this case vmName) and change the type to VC:Virtual Machine. There are no outputs.
  • Click the Schema tab. Drag and drop the Scriptable task item onto the design canvas.
  • Click the Scriptable task. From the Info tab update the task name (in this case I have used Add to Monitored OU).
  • From the IN tab click the Bind to workflow parameter/attribute button. Select the attribute (AD_Host) and parameter (vmName) we created earlier.

New_Workflow_2

  • Open the Scripting tab. The commands I have used are below, this finds and outputs the computer name (using the vmName parameter) from AD (searching the Active Directory host specified in the AD_Host attribute), and then moves it to the new OU.
  • Save and close the workflow.

var object = ActiveDirectory.getComputerAD(vmName.name,AD_Host);

System.log("Searching for computer: " + vmName.name)
System.log("Found computer: " + object)

ActiveDirectory.rename(object.distinguishedName, "CN= " +vmName.name , "OU=Monitored,OU=Servers,DC=Corp,DC=Local" , AD_Host)

vRA Configuration

The next step is to hook the vRO workflow into vRA. Log into the vRealize Automation portal as a user with service architect permissions. From the Design tab select XaaS and Resource Actions. Any existing resource actions are listed. Click New.

Existing_Resource

Map the resource action to the relevant vRO workflow. In this case we need to expand Library, Solarwinds and select the Add to Monitoring workflow.

SW_vRA

The input mappings should already be populated; the resource type is IaaS VC Virtual Machine, the input parameter matches up with the parameter configured in the vRO workflow (vmName which passes the virtual machine name), and this maps to the VC:VirtualMachine orchestrator type.

SW_vRA_1

Accept the default values in the Details tab. Edit the Form as appropriate, in this example I have added just a text description for the user. When you’re done click Finish.

SW_vRA_2

The new resource action is now listed as a draft. To start using the action select it and click Publish. Now select the Administration tab and Catalog Management. Open the Actions page, the new resource action we created should now be displayed.

If you want to change the icon of the resource action you can do so by selection the action and clicking Configure. There are a number of useful vRA icons available here, including sample icons for day 2 actions. Note for users of vRA 7.2 there is a known issue with changing the icon for custom actions, resolved in 7.3 as per this KB article.

SW_Catalog

The next step is to assign our custom action to an entitlement. Open the Entitlements page and select the relevant entitlement. Click the Items & Approvals tab, under Entitled Actions click the green plus symbol. Locate the new resource action and select the check box to add it to the entitled actions. Click Ok and Finish.

SW_Catalog_1

To confirm the configuration has worked browse to the Items tab and select Machines. Any virtual machines that have the custom resource action added to the entitlement will show the new action in the drop-down Actions menu.

SW_Catalog_2

When selecting the new action I am presented with the action form as per the design canvas we saw earlier. In this example when I click Submit the Add to Monitoring workflow is run moving the computer object of the virtual machine to the OU specified in the script.