Archive for March, 2012

Finding Vendor specific VIBs on ESXi hosts with PowerCLI

March 30th, 2012 2 comments


Example showing VIBs loaded on a host with a search of the vendor name "VMware"


The other day I was trying to find a list of Custom VIBs (VMware Installation Bundles) that were installed on an ESXi host. The reason was that I just wanted to verify that the VIB had actually installed correctly or not. I threw the query out on Twitter and of course @alanrenouf had a solution in next to no time.

So Alan’s solution is to use the Get-EsxCli cmdlet and specify the host name using the VMHost parameter. After that, he simply uses the code property “software” to gain access to the list of VIBs on the host. E.g.

$ESXCLI = Get-EsxCli -VMHost esxi-01.noobs.local

I have used esxcli on its own before but didn’t realise that PowerCLI had this cmdlet built in to interface with hosts in the same way that esxcli would. This is a great solution and means you can fetch so much more in this regard.

To filter things down a bit more and find the exact match for the Dell OMSA VIB I was looking out for, I used a where clause looking for a match for “dell” on the Vendor property:

$ | Select AcceptanceLevel,ID,InstallDate,Name,ReleaseDate,Status,Vendor,Version | Where {$_.Vendor -match "dell"}

Thanks again to Alan Renouf for pointing out the use of Get-EsxCli and for providing an example!


How to use PoSH or PowerCLI to SSH into network devices – wodSSH [Part 2]

March 26th, 2012 2 comments


In [part 1] of this series of posts, I explored SharpSSH, and how to use this to SSH into network devices via PowerShell or PowerCLI. I found this extremely useful, and managed to automate a process of retrieving some SHA1 SSL fingerprints from a few clusters of ESX hosts in the process. I did however find that loading the dll and functions necessary to get this bit of automation done was a little tedious. I had heard about wodSSH via the get-scripting podcast and decided I would need to take a look at this.


If you are planning on using wodSSH, you should start by downloading it here. Note that you should definitely buy a license if you are going to be using this for your job or day to day automation – the license is not to expensive if you consider the kinds of automation you could achieve with this! For this blog post I am just using the trial version in my lab environment at home to try out – the trial pops up a “nag screen” every now and then to indicate you are unlicensed. Once downloaded, install wodSSH and the libraries will now be available for use on your machine.


Download the script below, or take a look at it in the Syntax Highlighted area below – this is an example of how I was able to SSH into a cluster of ESXi hosts and run a remote command via SSH through PowerCLI. In this example, a table is returned with Host names, along with their SHA1 fingerprint information. It is possible to retrieve this info (as of ESXi 5 I believe) in PowerCLI, but for this example I just wanted to demonstrate the use of SSH and PowerShell / PowerCLI.


Download wodSSH PowerCLI Implementation Script (706)


$login = "root"
$password = "yourrootpassword" 

$Report = @()
$VMHosts = Get-VMHost | Where {$_.ConnectionState -eq "Connected"} | Sort Name

foreach ($vmhost in $VMHosts) {
	$hostname = $vmhost
	$ssh = New-Object -ComObject "weOnlyDo.wodSSHCom.1"
	$ssh.Hostname = $hostname
	$ssh.Login = $login
	$ssh.Password = $password
	$ssh.Blocking = 1
	$ssh.Protocol = 4
	$ssh.Timeout = 25
	$ssh.WaitFor("regex:[$%#>] $")
	$cmdresult = $ssh.Execute("openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout -fingerprint`r`n","regex:[~#]")
	$temp = $cmdresult | select-string -pattern "SHA1 Fingerprint="
	Write-Host $cmdresult -ForegroundColor Green
	$row = New-Object -TypeName PSObject -Property @{
		SHA1 = $cmdresult
		HostName = $vmhost
	$Report += $row


You will notice that on line 09, we load the wodSSH library using the New-Object cmdlet. After this we continue to setup some properties for our $ssh connection object. A regex check is used to determine when are connected to a host and have an SSH shell prompt ($ssh.WaitFor(“regex:[$%>;] $”).  We then use $cmdresult to capture the result of running an SSH command via our connection to our current ESXi host. To finish capturing the output of the command on our remote host, we use a regex check again (“regex:[~#]”). You’ll notice that the actual command is also on this line, i.e. line 18 (openssl). After the result is captured, we disconnect our SSH session, then proceed to build our small report array. At the end of the script, we output the $Report array to the screen.


Results of the above script in PowerCLI


As far as I can see, the wodSSH library can open up a whole new world of automation for you in the data centre. Think of the possibilities – you could automate just about everything, from switches, routers, Linux/Unix hosts / ESXi Hosts to iLO / DRAC and other management cards. Essentially, anything that accepts commands via SSH! If you have any automation stories using wodSSH, or just PowerShell or PowerCLI in general, I would love to hear about them – so feel free to drop a comment or two on this post.



Review: PHD Virtual Backup & Replication 5.4

March 22nd, 2012 No comments




PHD Virtual Backup & Replication is as the name would suggest, a complete, all-in-one backup and replication package. It is available in both VMware and Citrix XenServer flavours. I have long been a user of other Virtualization Backup Solutions and up until recently, never had the chance to play with PHD’s offering. A couple of weeks ago, PHD Virtual asked  me to take a look at their Backup offering and put down my thoughts in the form of a sponsored review. That being said, I got the appliance installed in my lab environment and set about putting down my thoughts and observations about the product whilst using it for various backup, recovery, and replication tasks in my lab over the last two weeks.


Thoughts and Observations


Getting PHD Virtual Backup and running in my Virtual Lab environment was an absolute pleasure. Let’s just say the product definitely does what it says on the tin – installation was as simple as deploying the downloaded OVF file with the vSphere client (File -> Deply OVF Template), powering up the “Virtual Backup Appliance” and setting up some basic network settings. I would say the longest part of the installation for me was finding the line in the installation steps that said “Press CTRL + N to enter the network settings in the console” (which wasn’t long at all)! After entering my network settings, I had the choice of either browsing to the IP address of my appliance, or running the PHDVB_Install.exe file to get the Virtual Appliance “Management” console installed. I simply ran the installer and within 8 minutes or so (from start to finish) I had PHD Virtual Backup & Replication up and running in my vSphere lab.



The product supports VMware and Citrix (XenServer) in terms of hypervisor platforms. As stated above, in this review I will be working with a VMware vSphere 5.0 environment, and have therefore put the VMware edition to the test.


The observation I liked this far into my experience was that I didn’t have to make the choice as to whether I should be running my backup solution on a physical or virtual machine – its simple – the product is a Virtual Appliance. You deploy the initial appliance, and if needed, scale by deploying more virtual appliances. This means you don’t need to worry about managing a separate physical server(s) for your backup solution. This is just one of the reasons why PHD Virtual Backup is so easy to deploy.

The Virtual Appliance is pre-configured with the following specifications:

  • 1 vCPU
  • 1GB RAM
  • 8GB disk
In terms of actual backup storage, you do of course have a few options.
  • Add a Virtual Disk to the Appliance itself (VMDK)
  • Configure Network storage (which could be):
    • a CIFS target
    • an NFS target


I chose to use a separate NFS mount on a Virtual Appliance I use for general purpose storage and backup in my lab, so I simply opened the appliance management console (right click in vSphere Client -> PHD Virtual Backup -> Console) and went to “Backup Storage” under “Configuration” to configure my NFS datastore as a backup target. You can also set up a couple of thresholds for warning / stop levels in terms of free disk space on your target, as well as enable/disable backup compression at this stage.

Access to the management console is simple via right-click in the vSphere Client


Configuring Backup Storage for the VBA



Backing up VMs


As the virtual appliance integrates in with the vSphere client, dealing with configuration tasks and actually setting up backups for your VMs is simple. No need to remote to another server or open up a console to your backup appliance VM. For my testing I configured a couple of different backup jobs – one to backup my VC, Update Manager and other VI VMs and one to backup a couple of general purpose VMs in my lab.

Backup speeds themselves were of a good level and on par with what I would expect from a product that utilises the VMware vStorage APIs for Data Protection (VADP). My first job that I ran took a little while to do the first initial (full) backup, but after this the subsequent runs of the backup job correctly used CBT (Change Block Tracking) to pick up on only changed blocks and copy these up, significantly reducing backup times of my VMs. VMware Hotadd is also utilised to help with quicker VM Backup times. Each job that runs gives you some detailed information on statistics such as:


  • Dedupe Ratios (Per VM and Per individual VM Disk)
  • Job average speed
  • Dedupe Ratios (Per Job)
  • Total amount of Data Written (useful for tracking how well CBT is working for example)
  • CBT Enabled/Not
  • Scheduling / Time details


Job details view


A nice feature I found at this stage was the ability to look at a detailed job log right from the console. Let’s say you have a job or VM in a job that gave a warning or error message for some reason, and you wished to find out the cause. All you need to do is right-click the job name and select “View Log”. This pops up a window with a detailed, timestamped job log, allowing you to dig in to each step of the backup process and see what happened at each stage of the particular backup job.


Detailed job log view


File Level Restore


Restoring files is also a simple task. From the main console, there is a “FLR” (File Level Recovery) section which handles this process. I tested restoring files from within two different VMs using this console. Both were Windows Guests (one Server 2003 Standard and one Server 2008 R2 Standard VM). The process went as follows:

  • Under “Backup Catalog” where your previous backup jobs are listed, select the VM / VM Disk you would like to restore from.
  • Click the “FLR” button.
  • Go  through the “Backup to Share” wizard and tick on the option to “Add target to iSCSI Initiator on this computer”.
  • Finish Wizard, and the VM Disks are mounted on the local machine and are now accessible.

Select VM Disk to initiate FLR from under Backup Catalog.


Following the Wizard through to mount the VM Disk/s on local machine for File Level Restore





Disks for two different VM disks are now mounted and ready to be accessed.


If you take a look at the Microsoft iSCSI Initiator tool you can see the two targets that have been mounted…



Incidentally, doing file-level restores from Linux/Unix based VMs can also be done by PHD VB. You just need to supplement the restore process with a third-party tool such as “Ext2explore”. You will follow the same process to mount the VM disks using the FLR wizard, but then just use Ext2explore to actually browse the mounted disk/s instead of Windows Explorer.


Restoring full VMs


I must say that I really like the features available in PHD Virtual Backup & Replication when it comes to doing full/partial restores of VMs. The wizard you use is nicely laid out and functional. You also get some great restore options such as; appending a “_restored” tag to the end of your restored VM name, auto-generation of a new MAC address for the restored VM, and changing of the default VM network (portgroup).

These are all great features  when it comes to restoring VMs. Especially if you are restoring back into a production environment alongside the original VM and would like to ensure that there are no network conflicts for example. I have a dedicated, isolated VM network for testing (no vSwitch uplinks to physical adapters) so the option to change the default network on the VM to restore was perfect for me to test with.


Selecting VMs to restore by Latest or by backup date/time order


The excellent array of restore options available when doing full/partial VM restores


VM Replication


PHD Virtual Backup also has replication functionality. Ideally you will want to have more than one VBA (Backup Appliance) running. For example, one in your DR Site, and one in your Production site. The appliance in your DR site will essentially connect in to the Backup Storage at your production site and hook into your backup jobs done there to find the latest changes of the VM backups done to replicate. So ideally when you set up a particular replication job, you should schedule it to start a short while after the relevant backup job completes. This ensures you get the latest changes replicated. The replication job will fetch only the changes since the last run. To enable replication, you just need to complete a once off configuration task using the PHD VB Console – adding a Replication Datastore. All this is, is pointing the appliance to an existing PHD VB Backup storage area – this can be a CIFS, NFS or VMDK Disk store that you are currently using for backups. As with VM Restores, you also get some useful options when replicating to change VM networks (VM portgroups) or auto-generate new MAC addresses for replicated VMs. I should also mention that you are also able to do replication even with just one VBA.

From the PHD Console, you are able to test your replicated VMs. This is quite a handy feature and after putting a replicated VM into “TESTING” mode, you can then use the vSphere client to power up your replicated VM and perform any testing and validation you might require. A snapshot is added to the VM to ensure that the state of the VM pre-testing is preserved. Once testing is complete, you simply just click “Stop Test” in the console. The VM is powered down and changes are rolled back to the pre-testing state.


Testing replicated VMs with the console






  • “All in one” backup solution (everything you need in one Virtual Backup Appliance).
  • Simple and quick to deploy (or scale by adding more VBAs).
  • Good feature set (VM Backup, File Level Restore, Full VM restore, and Replication).
  • Easy to work with – simple/logical User Interface.
  • Integrates with the vSphere client for quick and easy access to Configuration, Backup, Restore and Replication options.
  • Great File-level restore – quick and easy access to files within VM backups (Windows or Linux/Unix).
  • Nice features available to change networking settings on restored VMs for testing or running alongside existing VMs.
  • Configurable VM Backup retention settings
  • Processing of multiple VMs at once in a backup job – allows VMs to be backed up in multiple streams instead of a “serial” fashion.




  • No network “fine tuning” options – example: fine tuning deduplication ratios when backing up over a WAN or LAN as opposed to direct disk storage. This would essentially allow you to have quicker backups for local storage jobs (albeit larger) or longer backups, but with smaller sizes to transmit over WAN links.
  • A couple of small caveats when using Replication (such as VM configuration changes are not replicated when changing settings on the original source VM, to the replicated VM).
  • No automation options – this would be nice to have in terms of backup, restore, replication or reporting automation. (A PowerShell module would be nice to have).




At the end of the day, PHD Virtual Backup is a great integrated Backup and Recovery product, with a little bit of room for improvement to add some extra “nice to have” features. The VBA (Virtual Backup Appliance) is dead easy to deploy and manage, and so is managing your backup, restore and replication processes. I think these are the best parts of the appliance. Whilst using it I found that each of the various Backup and DR processes I needed were easy to use through the combination of a well laid out UI and interface that “just works”. Access to files in VM Backups via the file-level restore wizard was a highlight for me – it didn’t take long at all to get at historic files and restore them using the “FLR” Wizard.

The appliance offers a good selection of options, but these could be bettered by offering some form of automation (perhaps PowerShell access) and some more advanced settings for power-users. My thought was that some more advanced backup job options could be made available for power users to fine tune compression or deduplication ratios.

A free trial of the product is available and I would definitely encourage you to take a look at this – as mentioned above, being so easy to deploy and manage it won’t be long before you are up and running. This Backup & Replication product does offer everything you need to handle DR for your VMware Virtual Environment.


Useful resources:


Installing PHD Virtual Backup & Replication for VMware vSphere


PHD Virtual Backup & Replication 5.4 Trial


How to use PoSH or PowerCLI to SSH into Devices & retrieve information (Gathering SHA1 Fingerprints)

March 15th, 2012 No comments


I was listening to GetScripting podcast #29 the other day. The guest was Pete Rossi (PoSH Pete), and in the discussion he discussed data centre automation. Part of the automation he has set up involves wrapping SSH with PowerShell, and by doing so he is able to automate various functions on devices that can be SSH’d onto. This got me thinking of potential use cases. Soon enough I already had a couple of use case scenarios that could do with automating using SSH and PowerCLI. Pete mentioned he mainly uses an SSH component by a company called “WeOnlyDo Software”, however Alan Renouf also mentioned having heard of “SharpSSH”. I decided I wanted to try both out and figure out how to use both, so with that I set out figuring out how to get them working with PowerShell and PowerCLI. In this post (Part 1) I will cover using the SharpSSH DLL. In Part 2 I will go into the (easier in my opinion) wodSSH component (also paid for) method.


SharpSSH (based on Tamir Gal’s .NET library)


I believe Tamir Gal originally created this library, however it seems to now be maintained by others.


First of all, for SharpSSH to work with PowerShell or PowerCLI, you’ll need to get the relevant DLL that will be loaded by your script. I found a version of SharpSSH being actively worked on and improved by Matt Wagner on Bitbucket. I downloaded this version (called SharpSSH.a7de40d119c7.dll) to get started. To load the functions that we’ll be using to SSH in to devices, I used the following PowerShell function. Just be sure to reference in the correct path of the SharpSSH DLL that you downloaded above in this function. Download the function below:


Download SharpSSH Functions (834)


Then as long as the functions are loaded in your PoSH session, you should be able to run the example below.


How to SSH into ESXi hosts and retrieve SHA1 Fingerprints using PowerCLI and SharpSSH


Example output after running the script detailed below against multiple ESX hosts



Now, first off I’ll say that this isn’t necessarily the best way of retrieving SSL Fingerprints from your ESXi hosts in terms of security – you’d want to do this from the DCUI of the ESXi hosts to confirm the identity of each host is as you expect. (See this blog post and comments over at Scott Lowe’s blog for more detail on the security considerations). With that being said, here is my implementation of SharpSSH, used to SSH into each ESXi host (from a Get-VMHost call) and retrieve the SHA1 Fingerprints. The script will create and output a table report, listing each ESX/ESXi host as well as their SHA1 Fingerprint signatures.


Background for the Script


I believe this is actually quite an easy bit of info to collect using PowerCLI and the ExtensionData.Config properties on newer hosts / vSphere 5, but in my environment I was working with, all my ESX 4.0 update 4 hosts did not contain this Fingerprint info in their ExtensionData sections when queried with PowerCLI. Therefore I automated the process using SSH as I could use the command “openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout -fingerprint” to generate the Fingerprint remotely on each host via SSH. So with that in mind, here is the script that fetches this info. Note it will prompt for root credentials on each host that is connected to – this could probably be easily changed in the Function (downloaded from above). So here is the final script which will list all ESXi hosts and their SHA1 Fingerprints:


$Report = @()
$VMHosts = Get-VMHost | Sort Name

foreach ($vmhost in $VMHosts) {
	New-SshSession root $vmhost
	if (Receive-SSH '#')
		Write-Host "Logged in as root." -ForegroundColor Green
		$a = Invoke-SSH "openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout -fingerprint" 'SHA1'
		$temp = $a | select-string -pattern "SHA1 Fingerprint="
		$row = New-Object -TypeName PSObject -Property @{
			SHA1 = $temp
			HostName = $vmhost
		$Report += $row
		$rootlogin = $true
		Write-Host "Output complete." -ForegroundColor Green
	if ($rootlogin -eq $true)
		Write-Host "Exiting SSH session."
		Send-SSH exit
	Write-Host "Terminating Session."



Well, I hope this helps you out with a way to automate SSH access to devices to retrieve information or change settings. This could easily be adapted to send SSH commands to any other kind of device that accepts SSH as a method of login. Switches, Routers, linux servers, you name it! In my next blog post I will be showing you how to use the wodSSH library (We Only Do Software) to do SSH in PowerShell or PowerCLI – I have found this method to be a bit easier to use when compared with SharpSSH! So look out for my next post coming soon!

Figuring out what build of ESX or ESXi VMware Tools maps to for VMs using PowerCLI

March 8th, 2012 6 comments


This evening I was spending a bit of extra time checking through various components of a vSphere 4 installation to see what was compatible with ESXi 5 and what was not. As you would expect VMware Tools and Hardware needs to be checked for Virtual Machine compatibility with ESXi 5. There are plenty of scripts in PowerCLI out there that will show you how to determine the VMware Tools version, but this is always reported back as a four digit “cryptic” number, which doesn’t make much sense unless you go look it up.


In my quest to make this easier, I wrote a quick PowerCLI Function that will report back with some (hopefully) helpful information – it lists the Virtual Machine, Virtual Machine Tools version number as well as what version of ESX or ESXi + the update level that version of VMware Tools maps to. In my quest to make this easier for myself, I stumbled across this VMware Version mapping-file. Within it, contained the answers to the various VMware Tools version “codes” that were easy enough to retrieve with PowerCLI. My function simply does a quick check to see if the Tools number on a VM matches any of these codes and then lists the mapped version of ESX(i) corresponding to the code next to the VM.


So without going on in any further detail, here is an example of the output from a cluster I ran my function on (interesting I spot an ESX 3.5 VMware Tools VM in there!):



I think this will be a very useful little Function to have handy for these kinds of checks – especially larger infrastructures where VM tools are not known to be 100% up to date! The great thing about this is you can pipe in VMs. In the example above, I have grabbed all the VMs in a certain cluster and checked those using Get-Cluster and Get-VM, piping the output of those cmdlets to my Get-VMToolsMapped Function. Here is the script download:


Download Get-VMToolsMapped PowerCLI Function (809)


# Mapping file found at:
# Content of mapping file as of 08/03/2012:

Function Get-VMToolsMapped() {

 Get-VMToolsMapped -VM MYVMNAME

PS F:\> Get-VMToolsMapped MYVMNAME

PS F:\> Get-VM | Get-VMToolsMapped

PS F:\> Get-Cluster "CLUSTERNAME" | Get-VM | Get-VMToolsMapped


Created by: Sean Duffy
Date: 08/03/2012

[Parameter(Position=0,Mandatory=$true,HelpMessage="Specify the VM name you would like to query VMware Tools info for.",

process {

$Report = @()
New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine -ValueFromExtensionProperty '' -Force

$VMInfo = Get-VM $VM | Select Name, ToolsVersion
Switch ($VMInfo.ToolsVersion) {
	8389 {$ESXMapping = "esx/5.0u1"}
	8384 {$ESXMapping = "esx/5.0"}
	8300 {$ESXMapping = "esx/4.1u2"}
	8295 {$ESXMapping = "esx/4.1u1"}
	8290 {$ESXMapping = "esx/4.1"}
	8289 {$ESXMapping = "esx/4.1"}
	8288 {$ESXMapping = "esx/4.1"}
	8196 {$ESXMapping = "esx/4.0u4 or esx/4.0u3"}
	8195 {$ESXMapping = "esx/4.0u2"}
	8194 {$ESXMapping = "esx/4.0u1"}
	8193 {$ESXMapping = "esx/4.0"}
	7304 {$ESXMapping = "esx/3.5u5"}
	7303 {$ESXMapping = "esx/3.5u4"}
	7302 {$ESXMapping = "esx/3.5u3"}
	default {$ESXMapping = "Unknown"}

$row = New-Object -Type PSObject -Property @{
   		Name = $VMInfo.Name
		ToolsVersion = $VMInfo.ToolsVersion
		ESXMapping = $ESXMapping
$Report += $row
return $Report



PS – big thanks to @alanrenouf and @jonathanmedd for pointing out the much more efficient PowerShell “Switch” statement – I have updated the script above to use this and saved quite a few lines of code in the process.


Windows Server 8 first impressions (running in VMware Workstation 8)

March 2nd, 2012 No comments


I enjoy trying out new Operating Systems as soon as they are released, so naturally I had to download Windows Server 8 Beta Evaluation last night when I had an hour or so to spare.


I have installed it in a VM running on VMware Workstation 8.0. The requirements don’t seem to be too high with the most notable resource requirement to me being 512MB RAM. Not much has changed there since 2008 R2 then. The VMware set up was as simple as I imagined – no need to follow any guides, I just went with my gut and created a new VM as a Windows Server 2008 R2 – 64 bit machine, gave it a couple of GB RAM and vCPUs then told it I would install the OS later. After this I added the ISO for the Beta and Powered Up. The Windows 7 desktop wallpaper “fish” makes an appearance on first load and soon you are in the installer. The OS edition I installed is the “Datacenter edition”. I went with the GUI version, as I decided to check the Core edition out another time. Installation is of course very straight forward not too much has changed since 2008 R2. Within 7 or 8 minutes I was up and running at the logon screen.


Installation of Windows Server 8 Datacenter Edition is very straight forward.


Windows 8-esq Login Screen


Things I like so far are –

  • The new design – clearly all stylised to fit in with the Windows 8 and Windows Phone 7 style etc…
  • New Server Manager – manage multiple servers from one area and create Server Groups.
  • Roles and Features guide seems to give you more detail on some roles (such as Active Directory for example)
  • Task Manager improvements – information is easier to read in my opinion – especially the resources / performance data


Annoying things –

  • Server Manager always pops up every time you start up – I’m sure there would be a switch to disable this like Server 2008 though.
  • Start Menu was a little difficult to locate at first! Found it after hunting around a bit though.


The new Server Manager


Of course I had to jump into PowerShell and check it out quickly- I also used PowerShell to quickly join my Server 8 VM to the lab domain.

Add-Computer -Domain domainname -Credential domainname\adminaccount


PowerShell 3.0


Task Manager in the Server 8 Beta


Well overall my first impressions are it looks good, and seems to run well in VMware Workstation. I’m pretty sure it’ll work fine under vSphere 5 and Fusion too. (Of course probably not officially supported yet as it is Beta etc…) I’m looking forward to exploring the new OS in more detail in the coming weeks.