Another update! ESXi Host Backup & Restore GUI Utility (PowerCLI based) updated to 1.3

The other weekend I managed to get some spare time to do another update to my ESXi 5.0 / 5.1 Host Backup & Restore GUI utility, this time it has been updated to version 1.3. I didn’t post up the changes as it was done by special request from one of my blog readers (thanks Flavio!) However, after receiving more comments with a few others having a similiar issue to what Flavio had, I thought I should definitely post the updated version here, which should hopefully solve the issues some people are seeing.

 

The changes are based on feedback received in the comments I have received about the utility relating to exceptions received when users in some circumstances try to backup their host configurations. Specifically the exception message “Exception caught: Get-VMHost VMHost with name ‘xxx’ was not found using the specified filter(s).

You can check the utility out over on it’s page here.

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

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

 

A function to lookup Host System friendly name by MoRef using PowerCLI

In a recent blog post, I showed a simple method of outputting a list of hosts with their friendly names, as well as their MoRef (Managed Object Reference) names alongside eachother, enabling you to match up which host belongs to which MoRef. I wanted to take that a little further, with a function that is able to return the friendly name of a host’s MoRef that is input into the function. I have used this is a larger reporting script, where I can only get the MoRef of a host via it’s property within a cluster object. Basically, I look for any Failover hosts (admission control policy), which is an array, and the hosts are listed as indexed objects of this array. They are also only displayed as MoRef names, so at this point, instead of inserting the MoRef into my results, I insert the MoRef into this function, return the friendly name, and input this instead. Which allows the person reading the report to easily identify the host! $cluster.ExtensionData.Configuration.DasConfig.AdmissionControlPolicy.FailoverHosts <- In this example, $cluster is a particular cluster using the “specify a failover host” policy, and “FailoverHosts” is the array, with each object within containing a host MoRef. For example FailoverHosts[0].Value would be one instance, and may equate to “HostSystem-host-28” for example.   So here is the function. It takes two mandatory parameters: -MoRef (the MoRef of the host in question of course), and -Cluster (the name of the Cluster to do the lookup in) – the function loops through each host in this cluster to look for a host that matches the input MoRef.

Function Get-VMHostByMoRef() {

<#
.SYNOPSIS
Fetches host name by input MoRef and Cluster to look in

.DESCRIPTION
Fetches host name by input MoRef and Cluster to look in

.PARAMETER MoRef
The MoRef of the host system

.PARAMETER Cluster
The name of the cluster to do the lookup in

.EXAMPLE
PS F:\> Get-VMHostByMoRef -MoRef HostSystem-host-28 -Cluster MyCluster01

.LINK
http://www.shogan.co.uk

.NOTES
Created by: Sean Duffy
Date: 22/02/2013
#>

[CmdletBinding()]
param(
[Parameter(Position=0,Mandatory=$true,HelpMessage="Specify the Host MoRef name you would like to query for it's friendly name.",
ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)][String]$MoRef,[Parameter(Position=1,Mandatory=$true,HelpMessage="Specify the Cluster to search hosts in.",
ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)][String]$Cluster
)

process {

$AllHosts = Get-Cluster $Cluster | Get-VMHost
$thehost = $AllHosts | Where {$_.ExtensionData.MoRef -match $MoRef} | Select-Object -Property Name

return $thehost

}
}

Here is a quick sample of the output when called directly from the PowerCLI prompt (note the MoRef of “host-22” used to find the real host name of “esxi02.homelab.local”: Hopefully this may be of use to some – add it to your PowerCLI script/function toolkit or throw it into your PowerShell $profile for easy access in the future!

Setting up vCenter 5.0.x Inventory Service wrapper.log rotation

I noticed a trend recently on one of our vCenter servers where the disk space on the C:\ drive kept running low. The OS being run is Windows Server 2008 R2. Eventually if the disk fills up, the vCenter service will fail and stop.

 

 

I used the free utility “TreeSize” to inspect the drive and see where all the disk space was being used up – the culprit was the C:\ProgramData\VMware\Infrastructure\Inventory Service\Logs\wrapper.log file – sitting at a massive 16GB in my case.

By default this log file seems to be configured to have no limits in size. I am not sure what caused the log file to grow so rapidly over the course of a week or so, but I’m sure closer inspection of the contents of the log file will reveal more detail.

For now, I will just point anyone having a similiar issue to the steps required to enable log rotation and file size limit on this wrapper.log file, which will prevent your vCenter server from running out of disk space. These steps are taken from a VMware KB article, which I will link to below.

 

High level process is as follows:

 

  • Stop vCenter service
  • rename the wrapper.log file to something else (e.g. wrapper.log.bak) – after everything is up and a new log file is in place, this could be compressed and stored away, or deleted
  • open up the configuration file at C:\Program Files\VMware\Infrastructure\Inventory Service\conf and locate the wrapper.conf
  • edit the following two lines to change to:
    • wrapper.logfile.maxsize=100m (original value is 0)
    • wrapper.logfile.maxfiles=2 (original value is 0)
  • Save the file and close it
  • Start the vCenter service again

The actual VMware KB article details the above process.

 

Troubleshooting the Autolab vCloud Director 1.5.1 installation

I have had this issue twice now, where deploying vCD via the Autolab PXE boot option on the vCD VM fails. As far as I can tell, the process seems to fail on the Oracle Express DB installation, due to the RPM not being a valid package.  The vCloud Director steps seem to be the same for Autolab 1.0 or 1.1, so the following applies to both.

error: /root/oracle-xe-11.2.0-1.0.x86_64.rpm: not an rpm package (or package manifest)

You can see the error I was getting in the screenshot I captured during boot time below. I had checked the RPM file and everything else to ensure it was in place, and indeed it was. Even vCD installs via the script, although it of course does not work due to the database not being there.

 

 

Here is the process I used to correct my vCD install.

  • Allow VM to finish booting, even with the missing oracle DB.
  • Use PuTTy to SSH to the vCD VM (either direct from your VC or DC VM, or if you have the route setup, from your host machine (in the case you are using VMware Workstation for example). Default credentials are in the Autolab setup guide document
  • Open up the “Build” share on the NAS VM, and location the vcd-install script. Default location: \\192.168.199.7\Build\Automate\CentOS\vcd-install (open this with a text editor)
  • Locate the method for each section of the install script. There is a section for each process in the script. For each method, copy out the entire block, paste it into a new text document, and remove any exclamation marks from any “echo” parts of the script. I found that manually tracking through this script using PuTTy gave me issues with the exclamation marks being misinterpreted by the shell, so I removed these. You’ll need to get a script block for the following sections and do this:
    • verify() {}
    • installOracle() {}
    • configureOracle() {}
    • generateCertificates() {}
    • installvCD() {}
    • configurevCD() {}
  • Remember to copy the whole block, including the start and end braces {} – paste these into a new text document, remove the exclamation marks, then copy-paste them back into your shell open in PuTTy. Hit enter, and the method will be entered and ready for use.
  • Once all the methods have  been copied in, you can simply type the name of the method, followed by enter to execute them. By doing it this way, you can manually step through the process and figure out where any potential remaining issues may be. This script is normally executed during the PXE boot installation process so you don’t really get a chance to slowly track through it.
  • Type each method in until you reach and complete the last “configurevCD” one
    • verify
    • installOracle
    • configureOracle
    • generateCertificates
    • installvCD
    • configurevCD
  • You may find that the generateCertificates and installvCD methods complete and echo out that they had already been completed prior – this is fine.
  • After configurevCD finished, all being well, you should now have vCD started, and you should be able to browse over to https://vcd.lab.local and finish the initial configuration via the vCD web page.

 

Other tips to try would be to:

  • MD5 hash check the RPM of the Oracle Express database that you download and place in your Build share – make sure it is not a corrupted file
  • Ensure you have the correct version of vCD and the Oracle Express database downloaded