Category Archives: ESXi

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.


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.


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 and the updated VMware image (

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


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


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.


  • 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


  • 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.


For the Spectre patches remember to include the CPU microcode.


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.


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:


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:


After power cycling:


ESXi 6.5 FCoE Adapters Missing

After installing or upgrading to ESXi 6.5 FCoE adapters and datastores are missing. In this case the hardware in use is a HP ProLiant BL460c Gen9 server with HP FlexFabric 10Gb 2-port 536FLB adapters, although this seems to have been a problem for other vendors (see here) and versions too.

This issue should be resolved with a driver provided by the vendor which has the FCoE auto discovery on boot parameter enabled. Cross reference your hardware against the VMware Hardware Compatibility Guide here, and confirm you are using the correct version of the bnx2fc driver and firmware. If no updated driver is available from the vendor then review the workarounds outlined below.

Stateful Installs

Credit to this article, SSH onto the host and run the following commands.

esxcli fcoe adapter list lists the discovered FCoE adapters, at this stage there will be no results.

esxcli fcoe nic list lists the adapters available as potential FCoE candidates. Locate the name of the adapter.

esxcli fcoe nic enable -n vmnicX enables the adapter, replace vmnicX with the adapter name, for example vmnic2.

esxcli fcoe nic discover -n vmnicX enables discovery on the adapter, replace vmnicX with the adapter name.

esxcli fcoe adapter list lists the discovered FCoE adapters, you should now see the FCoE adapters listed.

The storage adapters should now be showing in the vSphere web client, however if you are using stateless installs with Auto Deploy, then this workaround is not persistent and is lost at reboot.


Stateless Installs

Credit to this article, we were able to create a custom script bundle to enable discovery on the FCoE adapters as part of the deploy rule with the steps below. Custom script bundles open up a lot of possibilities with Auto Deploy, but at this stage they are CLI only. I also noticed that if you create a deploy rule with a script bundle from the CLI, although it shows in the GUI if you then edit that rule in the GUI (for something unrelated, e.g. updated host profile) then it removes the script bundle without warning. So this is something you would need to weigh up against your environment, if you are already using CLI to configure deploy rules it shouldn’t be a problem.

PowerCLI can now be installed directly through PowerShell, if you don’t already have PowerCLI installed see here.

  • First up we’ll need to create the script on a Linux / Unix system. I just used a test ESXi host we had kicking about over SSH. Type vi replacing with an appropriate name for your script.
  • The file will open, type i to begin editing.
  • On the first line enter #!/bin/ash followed by the relevant enable and discover commands from the section above. You can see in the example below the commands for enabling vmnic2 and vmnic3 as FCoE adapters.


  • Press escape to leave the text editor and type :wq to save changes to the file and close.
  • Next we need to create the script bundle that will be imported into Auto Deploy. Type tar -cvzf bundlename.tgz


  • Copy the script bundle with the .tgz extension to your local machine, or the computer from where you will be using PowerCLI to create the deploy rule. In my case I copied the file over with WinSCP.
  • You should also have an ESXi image in zip format, make a note of the location. Add the script bundle and the ESXi software depot by running the following commands Add-ScriptBundle location\bundlename.tgz and Add-EsxSoftwareDepot location\ If you need further assistance with building custom images or using PowerCLI to manage Auto Deploy see the VMware Auto Deploy 6.x Guide and How to Create Custom ESXi Images posts.


  • Build the deploy rule using your own variables, again if you’re already using Auto Deploy I’m assuming you know this bit, we’re just adding an additional item in for the script bundle. See the guide referenced above if you need assistance creating deploy rules. I have used:
    • New-DeployRule -Name "Test Rule" -Item "autodeploy-script","HPE-ESXi-6.5.0-Build-5146846", LAB_Cluster, -Pattern "ipv4=" | Add-DeployRule


  • The deploy rule is created and activated, I can now see it in the Auto Deploy GUI in the vSphere web client, with the associated script bundle. When the host boots from the deploy rule the script is extracted and executed, and the FCoE adapters are automatically enabled and discovered on boot.


  • If you don’t use the | Add-DeployRule parameter then the deploy rule will be created but show inactive. You can activate using the GUI but do not edit the rule using the GUI or the script bundle will break.
  • If you are updating an existing image then don’t forget to remove cached rules by remediating host associations, under the Deployed Hosts tab.

ESXi Command Line Upgrades

Upgrading and patching of ESXi hosts can be done using the esxcli software commands, with either the online depot, or an offline bundle. For managing multiple hosts Update Manager is generally the best way to go. Update Manager is now built into VCSA 6.5 (vCenter Server Appliance 6.5 Install Guide) or can be installed on a Windows server (VMware Update Manager 6.0 Install Guide / VMware Update Manager 6.5 Install Guide).

In both the methods outlined below we will be connecting to the ESXi host via SSH. For assistance with enabling SSH review this KB article, remember to disable SSH when you’re done. Before beginning you should ensure any powered on virtual machines are shut down or migrated off the host. The host should be placed into maintenance mode and requires a reboot after patches are applied. You may find the following commands of use:

Lists the installed ESXi build version: vmware -v

Lists installed vibs: esxcli software vib list

List VMs present on the host: vim-cmd vmsvc/getallvms

Gracefully shut down a VM, replacing number with the VMID obtained from the above command: vim-cmd vmsvc/power.shutdown number

Power off a VM, replacing number with the VMID obtained from the above command: vim-cmd vmsvc/ number

Power on a VM, replacing number with the VMID obtained from the above command: vim-cmd vmsvc/power.on number

Enter maintenance mode: vim-cmd /hostsvc/maintenance_mode_enter

Exit maintenance mode: vim-cmd /hostsvc/maintenance_mode_exit

When installing individual vibs replace -d with -v, for example: esxcli software vib install -v viburl

The esxcli software commands below all use the update tag, this ensures that only newer contents of a patch are applied. If a system contains newer revisions of the selected patches then these will not be applied. The install tag can potentially overwrite existing drivers, and therefore the update method is recommended for upgrading ESXi and installing patches to prevent an unbootable state.

Online Depot

Useful for patching or upgrading individual hosts which have an internet connection and sufficient boot drive capacity. Open an SSH connection to the ESXi host using a client such as Putty, and log in with the root account. First enter the following command to open the firewall for outgoing http requests:

esxcli network firewall ruleset -e true -r httpClient

Find the image profile to upgrade to by reviewing the ESXi patch tracker here. To upgrade the ESXi host run the following command, replacing Imageprofile with the desired image profile name.

esxcli software profile update -d -p Imageprofile

For example:

esxcli software profile update -d -p ESXi-6.0.0-20161104001-standard

When the upgrade is complete use reboot to restart the host. Finally close the outgoing http port:

esxcli network firewall ruleset -e false -r httpClient

Offline Bundle

First download the relevant offline bundle from VMware, for upgrades ESXi ISO images can be found here, patches in zip format can be found here.

Next we need to upload the downloaded file to a datastore the ESXi host or hosts have access to. Log into the vSphere web client or the ESXi host UI. Navigate to the Storage view, right click the datastore and select Browse Files. Click the upload file icon and select the zip file downloaded earlier. With the patches now accessible from the host we can start the update process.

Open an SSH connection to the ESXi host using a client such as Putty. Install the downloaded updates using the following command, replacing datastore with the name or UUID of the datastore, and zip with the file name of the downloaded patches:

esxcli software vib update -d /vmfs/volumes/datastore/zip

For example:

esxcli software vib update -d /vmfs/volumes/Datastore01/

Check the installation result, a reboot is required. The content listed below this is a breakdown of the VIBs installed, removed, and skipped. Restart the host using the reboot command.


Following on from upgrading or patching an ESXi host you should also ensure VMware Tools is updated on any guest virtual machines.

For more information on ESXi command line tools see the Troubleshooting with ESXi Shell and vSphere Management Assistant Guide posts.

Troubleshooting with ESXi Shell

The ESXi Shell gives us a subset of commands for troubleshooting and managing individual ESXi hosts. ESXi Shell can be useful to quickly investigate and resolve issues with single hosts, for example if management agents are unresponsive. This section will cover how to enable ESXi Shell, how to access the ESXi Shell, and how to use the ESXi Shell. It is important to remember that when the ESXi Shell and SSH services are enabled you are potentially opening up vulnerabilities to which attackers may be able to use maliciously. For this reason you will see a warning on any hosts in the web client when the ESXi Shell and / or SSH service is enabled. You can suppress the ESXi Shell warning by following this kb. Remember to disable the ESXi Shell when you have finished, it is also possible to configure time-outs when enabling the ESXi Shell; availability time-out to determine how long ESXi Shell is enabled for, and idle time-out to determine how long idle sessions are kept connected.

You can remotely manage multiple hosts using the vSphere Management Assistant, for more information see the vSphere Management Assistant Guide.

Enabling ESXi Shell

By default the ESXi Shell is disabled, it can be enabled using the DCUI or web client (local or vSphere).

  • DCUI (Direct Console User Interface)
    • Access the console of the ESXi host by plugging in a monitor and keyboard, or establishing a remote console session using remote server tools such as ILO, IMM, etc.
    • Press F2 and enter the root password. Browse to Troubleshooting Options.
    • Select ESXi Shell and press Enter to toggle between enabled and disabled. If you are going to access the Shell locally this is sufficient, for remote connections you must also enable SSH.
    • Press Esc twice to exit out of the menus.


  • ESXi host web client (standalone hosts v6.5 and above)
    • Browse to the IP address of FQDN of the host and log in with the root password.
    • From the Navigation menu select Manage, and open the Services tab.
    • Locate and Start TSM for the ESXi Shell, and TSM-SSH for SSH if required.


  •  vSphere web client (hosts connected to vCenter Server)
    • Browse to the IP address or FQDN of the vCenter Server and log in with an administrator account.
    • Locate the host in the inventory and select the Configure tab.
    • Scroll down to the Security Profile menu under System.
    • Click Edit and start the Direct Console UI, ESXi Shell, and SSH services.


Access ESXi Shell

Once enabled, the ESXi Shell can be accessed locally using the DCUI or remotely over SSH.

  • For DCUI access to the ESXi Shell press ALT + F1 from the ESXi console screen. Log in with the root password.


  • For remote access open a connection over port 22 using an SSH client such as Putty, and log in with the root password.


Using ESXi Shell

The ESXi Shell contains the full range of esxcli and esxtop commands, as well as esxcfg for legacy purposes (although be aware that esxcfg is depreciated and may be phased out in future releases). The ESXi Shell is useful for performing maintenance and troubleshooting individual hosts, it cannot be used for scheduling scripting jobs. For managing multiple hosts and scripting use vSphere CLI (vCLI) either as a local installation or with the vSphere Management Assistant (vMA).

Have a look in /usr/sbin to view the available commands for the ESXi Shell; enter cd /usr/sbin and then ls. Note that commands are case sensitive.


esxtop is a powerful utility for examining ESXi host performance metrics and investigating performance issues. In the ESXi Shell enter esxtop with variables such as c for CPU, m for memory, n for network, and d for disk, read more in the Troubleshooting with ESXTOP post.

esxcli is a comprehensive set of commands for managing the vSphere environment. The command set is broken down into namespaces, to view the available namespaces use the esxcli command.


This propogates down the chain, for example use esxcli storage to view the options within the storage namespace. You can use –help at any level of esxcli for assistance.


You can view a full list of esxcli commands by entering esxcli esxcli command list. The screenshot below has been cropped and isn’t a full list, it may be beneficial to drill down through the relevant individual sections using the method outlined above.


As you can see the range of esxcli commands is vast, let’s take a look at a few examples.

  • esxcli hardware allows us to view and change the physical server hardware information and configuration. Use esxcli hardware cpu global set to enable or disable hyperthreading.


  • esxcli system allows us to view and change the ESXi system configuration. To enable or disable maintenance mode use esxcli system maintenanceMode set.


  • esxcli storage can be used for storage related tasks, use esxcli storage core path list to view attached LUNs, or esxcli storage vmfs upgrade to upgrade VMFS.


  • esxcli network allows us to perform network related tasks, use esxcli network vswitch standard to create a new standard virtual switch.


To exit the ESXi Shell use the exit command. Hopefully this post provides enough to get you started, if you are using ESXi Shell on a regular basis and want to view previously executed commands see this post by William Lam. For details on patching or upgrading ESXi from the command line see the ESXi Command Line Upgrades post.

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.