ESXi 5.0 / ESXi 5.1 Host Backup & Restore GUI Utility (PowerCLI based)

 

This is a little bit of  a fun project I have been working on in bits of spare time I find. It is all written in PowerCLI 5.0 / 5.1 / PowerShell and the GUI was laid out using Primal Forms Community Edition.

 

Updates (17-02-2013) – version 1.3:

  • Hosts are retrieved using a new method (for both backup and restore options)

Updates (29-12-2012) – version 1.2:

  • Added ESX/ESXi host validation into utility – will now test that the host is valid and either connected or in maintenance mode before attempting backup or restore (See the script’s new “Check-VMHost” function for those interested)
  • Minor UI improvements

Updates (29-10-2012) – version 1.1:

  • This utility has been tested on ESXi 5.1 Hosts and confirmed to be able to successfully create a backup archive file of these.
  • Be sure your DNS is working correctly on the system you run the Backup utility on – it relies on DNS to find your ESXi hosts as they are named in the dropdown when you select the host to backup. (See comments for troubleshooting)
  • Restore to new hardware (force restore) option added
  • Fixed labels and connection box label description

 

What it is essentially, is a GUI that allows you to Backup ESXi 5.0 or ESXi 5.1 hosts to a destination of your choice on a local drive. It also allows you to restore ESXi Host configuration bundle backups taken, to other Hosts. I had other plans to integrate cloud storage options in (Amazon S3) as a backup target, but I thought that this doesn’t really offer anything valuable and I would just keep it relatively simple for now – therefore I have disabled this functionality. The PowerCLI script is fairly long – and I know there are plenty improvements I could make to better it and shorten the code, but for now it does the job. I have added various catches for exceptions / errors so you should get visual feedback if you have entered an invalid path, or username for example.

 

Anyway, hopefully this proves useful to some! As always, take care using the backup / restore functionality of this utility. The restore functionality works by first putting the ESXi host into Maintenance mode (if it isn’t already in this mode) and then applying a backup bundle to the host (Restore). The Host will reboot immediately following this. The Backup and Restore is implemented using Get-VMHostFirmware and Set-VMHostFirmware cmdlets so you can read the help descriptions for an idea on how exactly these work. The Host Backup Bundles are stored in a path of your choice and when restoring from a path the cmdlet works by looking for a bundle filename that matches the name of your ESXi host selected to restore to. Note that the file browser module I have implemented here (used to select paths) is a modification of the work done by Ravikanth Chaganti on his PowerShell Help Browser GUI. I simply adapted his code to list the contents of local drives in a tree view instead of PowerShell Help cmdlets. The only limitation here is that I have not implemented code to browse further than one level into the root of each drive. If you can provide this modification yourself, please feel free to contribute in the comments! I have just not spent the extra time to do this myself yet.

 

Here are a couple of quick screenshots of the Utility / GUI:

 

 

ESXi 5.0 Host Backup & Restore GUI Utility & Path Browser

 

Current version (1.3):

(Version 1.3) [download id=”25″]

 

Previous versions:

(Version 1.2) [download id=”21″]

(Version 1.1) [download id=”20″]

(Version 1.0) [download id=”9″]

 

Enjoy!

 

How to see if a Device/Datastore supports VAAI on ESXi 5 using ESXTOP or ESXCLI

Previously, using my home lab environment I had wondered how to check to see if my shared storage was using VAAI (VMware Storage APIs for Array Integration) – this is a technology that provides hardware acceleration functionality for your storage in vSphere, and was first introduced for vSphere ESX(i) 4.1. Essentially, this allows your hosts to offload certain virtual machine and storage management functions to hardware that supports VAAI.

 

The very first way I found I was able to see if VAAI was active on a datastore was by using ESXTOP. Silly – as it is quite a long-winded way of determining this, but it gave me an idea of whether it was in use or not. Anyway, to get to this ESXTOP view, go to your devices screen (press u) and remove a few columns that are taking up room (press F to add/remove columns), toggle all columns except the DEVICE name column, then add the counters we are interested in for VAAI. (press O – for VAAISTATS). Like so:

 

 

Now you can see the VAAI statistics for your datastores/devices in ESXTOP – notice how my HP/LHN P4000 VSA lab iSCSI datastores are showing VAAI stats as expected, whereas my shared NFS Datastores from a FreeNAS appliance are blanked out / not supported in the screenshot below:

 

 

 

Here is a useful list of ESXTOP counters that are explained in detail if you are wondering what each of these shows exactly: http://communities.vmware.com/docs/DOC-11812 – Section 4.2.9 shows ZERO statistics specifically, which is one of the features VAAI can help hosts offload to hardware.

 

So now, for a slightly easier / clearer way of viewing whether VAAI is active or not – we can use esxcli!

 

Connect up to an ESXi 5 host using SSH or the DCUI and issue the following command (Where the device identifier is specified after -d) – remember to find the device identifier applicable to the device you want to check for VAAI status on – one way of doing this is to identify the datastore using your vSphere client – Hosts & Clusters view -> Select ESXi host -> Configuration -> Storage -> Devices View tab -> Look for device identifier in the name column. Once you have your device ID, issue the command below:

 

esxcli storage core device list -d naa.6000eb3afd81276200000000000000bd

 

You will get a list out of the device along with various settings and feature statuses. We are specifically looking for “VAAI Status” – if it is enabled, we will see “VAAI Status: enabled” as in the example below.

 

 

Brian Ragazzi has also showed an even easier method (thanks Brian!) to get a list of devices along with their VAAI feature support listed using:

 

esxcli storage core device vaai status get

 

using “esxcli storage core device vaai status get” to get VAAI status for devices

 

Interestingly, whilst researching this, I came across a blog post by Jason Langer who also explains the first method I showed above of checking VAAI status – in his case he was using Netapp storage and found some other interesting caveats along the way in terms of getting VAAI enabled on his hosts with his particular device. Well, I hope this post helps and as always, if you spot anything out of place – feel free to chime in on the comments section!

 

vSphere 5 & HA Heartbeat Datastores

 

I was busy updating my vSphere lab from 4.1 to 5 and ran into a warning on the first ESXi host I updated to ESXi 5.0. It read: “The number of vSphere HA heartbeat datastores for this host is 1, which is less than required: 2”. The message itself is fairly self-explanatory, but prompted me to find out more about this as I immediately knew it must be related to new functionality.

 

The Configuration Issue message

 

Pre-vSphere 5.0, if a host failed, or was just isolated on its Management Network, HA would restart the VMs that were running on that host and bring them up elsewhere. (I have actually seen this happen in our ESX 4.0 environment before!) With vSphere 5.0, HA has been overhauled and I believe this new Datastore Heartbeat feature is part of making HA more intelligent and able to make better decisions in the case of the Master HA Host being isolated or split off from other hosts. This Datastore Heartbeat feature should help significantly in the case of HA initiated restarts, allowing HA to more accurately determine the difference between a failed host and a host that has just been split off from the others for example.

 

vCenter will automatically choose two Datastores to use for the Datastore Heartbeat functionality. You can see which have been selected, by clicking on your cluster in the vSphere client, then choosing “Cluster Status”. Select the “Heartbeat Datastores” tab to see which are being used.

 

Cluster Status - viewing the elected HA Heartbeat Datastores

 

Without going into too much detail, this mechanism works with file locks on the datastores elected for this purpose. HA is able to determine whether the host has failed or is just isolated or split on the network by looking at whether these files have been updated or not. After my lab upgrade I noticed a new folder on some of my datastores and wondered at first what these new files were doing there! If you take a look at the contents of the Datastores seen your Heartbeat Datastores tab, you should see these files that HA keeps a lock on for this functionality to work.

 

Files created on HA Heartbeat Datastores for the new functionality

 

So, if you notice this configuration issue message, chances are your ESXi 5 host in question simply doesn’t have enough Datastores – this is likely to be quite common in lab environments, as traditionally we don’t tend to add many (well at least I don’t!) In my case this was a test host to do the update from 4.1 to 5 on, and I only had one shared datastore added. After adding my other two datastores from my FreeNAS box and an HP iSCSI VSA, then selecting “Re-configure for HA” on my ESXi host, the message disappeared as expected. I believe there should be some advanced settings you could also add to change the number of datastores required for this feature, but I have not looked into these yet. Generally, it is also always best to stick with VMware defaults (or so I say) as they would have been thought out carefully by the engineers. Changing advanced settings is also usually not supported by VMware too. However, if you find you are short on Datastores to add and want to get rid of the error in your lab environment, then this shouldn’t be a problem to change.