Whenever you need to install a new box with ESX, there’s the struggle with matching physical ports to VMware devices. Which network adapter becomes vmnic0?, Which hostbus adapter becomes vmhba1?, etc. Especially when you have a lot of network adapters this can be confusing and you can’t connect to the device over the network unless you have the right patching and physical switch port configuration. For the record my last box had 10 nics!

First thing to understand is that it’s important to know the PCI bus numbering, because ESX numbers the devices in ascending PCI bus number order. The network adapter with the lowest PCI number will become eth0/vmnic0.

How to do this:

• Use the hardware vendor’s specification sheet and learn which expansion slot has which PCI bus number. If you have a network adapter with multiple ports, the lowest port number will be the first device detected. From here sort everything in ascending PCI bus number order.
• Use the VMware provided tool “vmkvsitools“. Go to the console and issue the command “vmkvsitools lspci“. This command returns a list of all PCI devices in your system, equal to just running the “lspci” command, but adds the VMware device name at the end of each line.
  
  vmkvsitools also displays PCI numbers in decimal format.

If you are only concerned about network adapters, you could also use “esxcfg-nics“. Go to the console and issue the command “esxcfg-nics -l“. This command generates a list of network adapters and their PCI number.

Whenever I need to install a new type of hardware I use the vmkvsitools method to document my host before it’s going into production. There’s nothing more important than having your documentation 100% in place. I know it’s quite some work to document everything, but whenever a problem arises you don’t need to search for information and this relieves stress J

The PowerCLI way

Since VMware is moving away from the Service Console I was wondering how I could use PowerCLI to retrieve that information for me.

For the host bus adapter this can be achieved quite easily using this one-liner

Get-VMHost -Name "esx01" | Get-VMHostHba | Select Pci, Device, Model

For the network adapters you could use something similar using the Get-VMHostNetworkAdapter cmdlet instead.

Get-VMHost -Name "esx01"| Get-VMHostNetworkAdapter –Physical

However the PowerCLI object that is returned doesn’t contain the PCI information. So we have to do this one the SDK way.

The SDK way

To retrieve the full API object we need to use the Get-View cmdlet. By exploring the HostSystem object in the vSphere API reference, we learn that the required information can be found in the .Config.Network.Pnic property. This results in the following one-liner

Get-View -ViewType HostSystem -Filter @{"Name" = "esx01"} | %{$_.Config.Network.Pnic | Select Pci, Device}

Of course you could also use the API object to report on the host bus adapter. This information can be found in the .Config.StorageDevice.HostBusAdapter property, which leads to this onliner

Get-View -ViewType HostSystem -Filter @{"Name" = "esx01"} | %{$_.Config.StorageDevice.HostBusAdapter | Select Pci, Device, Model}

The PowerCLI 4.1 way

In PowerCLI version 4.1 there are two new cmdlets called New-VIProperty and Remove-VIProperty. Together with the new ExtensionData property, which exposes the API object that corresponds to the returned PowerCLI object, these cmdlets open new possibilities. Using these new cmdlets you can access the API object the PowerCLI way. Have a look at Lucd’s post PowerCLI 4.1 brings the New-VIProperty cmdlet for more information on using these new cmdlets.

Remember when I wanted to access the PCI information on the network adapter earlier? This information wasn’t exposed by the PowerCLI object. Using the New-VIProperty cmdlet I can now expose this information myself. Let’s have a look at the code:

New-VIProperty -Name Pci -ObjectType PhysicalNic -ValueFromExtensionProperty 'pci'
Get-VMHost -Name "esx01"| Get-VMHostNetworkAdapter –Physical | Select Pci, DeviceName

The Full Report

Besides network- and host bus adapters we could also report on other PCI devices using the API object. PCI information is stored in the .Hardware.PciDevice property. The following one-liner would generate a full report on all PCI devices similar to using the “lspci” command in the service console

Get-View -ViewType HostSystem -Filter @{"Name" = "esx01"} | %{$_.Hardware.PciDevice | Select Id, VendorName, DeviceName}

However this doesn’t show the associated VMware device names like the “vmkvsitools lspci” command. I’ve created the following function to return the host’s PCI devices and their associated ESX device names.

function Get-VMHostPciDevice {
<#
.SYNOPSIS
  Returns the ESX(i) host's PCI Devices
.DESCRIPTION
  This function returns the ESX(i) host's PCI devices en their associated ESX devices
.NOTES
  Author:  Arnim van Lieshout
.PARAMETER VMHost
  The ESX(i) host entity for which the PCI devices should be returned
.EXAMPLE
  PS> Get-VMHostPciDevice -VMHost (Get-VMHost "esx01")
.EXAMPLE
  PS> Get-VMHost "esx01" | Get-VMHostPciDevice
#>

	Param (
	[parameter(valuefrompipeline = $true, mandatory = $true,
	HelpMessage = "Enter an ESX(i) host entity")]
	[VMware.VimAutomation.Types.VIObject[]]$VMHost)

	Begin {
# Create PCI class array
		$PciClass = @("Unclassified device","Mass storage controller","Network controller","Display controller","Multimedia controller","Memory controller","Bridge","Communications controller","Generic system peripheral","Input device controller","Docking station","Processor","Serial bus controller","Wireless controller","Intelligent controller","Satellite communications controller"," Encryption controller","Signal processing controller")
	}

	Process {
		if($VMHost) {
			$VMHostView = $VMHost | Get-View
		}
		else {
			$VMHostView = $_ | Get-View
		}

# Get the PCI Devices
		$VMHostView | % {
			$PciDevices = @()
			foreach ($dev in $_.Hardware.PciDevice) {
				$objDevice = "" | Select Pci, ClassName, VendorName, DeviceName, EsxDeviceName
				$objDevice.Pci = $dev.Id
				$objDevice.ClassName = $PciClass[[int]($dev.ClassId/256)]
				$objDevice.VendorName = $dev.VendorName
				if ($dev.DeviceName -notmatch "Unknown") {
					$objDevice.DeviceName = $dev.DeviceName
				}
				$PciDevices += $objDevice
			}

# Find associated ESX storage devices
			foreach ($hba in $_.Config.StorageDevice.HostBusAdapter) {
				$PciDevices | ? {$_.Pci -match $hba.Pci} | % {$_.EsxDeviceName = "["+$hba.device+"]"}
			}

# Find associated ESX network devices
			foreach ($nic in $_.Config.Network.Pnic) {
				$PciDevices | ? {$_.Pci -match $nic.Pci} | % {$_.EsxDeviceName = "["+$nic.device+"]"}
			}
		}
	}

	End {
    	$PciDevices| Sort-Object -Property Pci
	}
}

PCI Device Classes

Instead of the PCI id, I’ve included the PCI class name. The PCI id is a 2byte id, where the first byte refers to the PCI class and the second byte refers to the PCI subclass. The following table shows the PCI classes which I defined in the $PCIClass array.

Related posts:

1. PowerCLI: Match VM and Windows harddisks – Part 2
2. List HBA WWPNs and LUNs using Powershell
3. Installing ESX 4.0 on VMware Fusion

Watching the twittersphere for vExpert announcements, I was intrigued by the need for people to be on a list. A lot of people contacted me that they were missing from the vExpert twitter avatar list on my vExpert 2010 post. I also saw many people ask Maish Saidel-Keesing to include them on his VMware vExpert 2010 Twitter list and even people contacted William Lam to include a link to their own vExpert post in William’s vExpert 2010 Crew.

This made me decide to create another list and dedicate a page to it. May I present to you the VMware vExpert 2010 Directory.

Related posts:

1. Are you a VMware vExpert?
2. VMware vExpert 2010
3. VMworld Europe 2010 – Copenhagen here we come

Today I woke up and found out that I was rewarded as a VMware vExpert 2010. I’m deeply honored to be designated for this award and to become part of this selected group of great minds. I want to thank VMware and the vExpert judges for selecting me. A special Thank You goes to John Troyer, the man who puts an enormous effort into making this vExpert program a reality.

The VMware vExpert Award is given to individuals who have significantly contributed to the community of VMware users over the past year. vExperts are book aut.hors, bloggers, VMUG leaders, tool builders, and other IT professionals who share their knowledge and passion with others. These vExperts have gone above and beyond their day jobs to share their technical expertise and communicate the value of VMware and virtualization to their colleagues and community.

Also congratulations to all other vExperts 2010

This list is not complete. If you’re missing please leave a comment.

Related posts:

1. Are you a VMware vExpert?
2. VMworld Europe demoted to October 2010
3. Voted #29 top blogger on vSphere-land.com

Vizioncore just released the newest version of the vEcoShell (Virtualization EcoShell). As a user and developer of VMware PowerCLI scripts I almost use the vEcoShell on a daily basis. The amazing thing about the vEcoShell is that you don’t need any scripting experience to use PowerCLI scripts and examples found on the web. If you haven’t done so, give it a try. You will like it! That’s a promise!

Starting with the 1.2.6 release of vEcoShell, it will no longer be referred to as beta! vEcoShell is finally an officially sanctioned product from Vizioncore. The product is still a Freeware offering with online community support only.

The landing page now also includes a link to the Community PowerPack for even more power. This Community PowerPack demonstrates the full potential of the vEcoShell and gives the virtualization administrator a crucial tool for administering the virtual environment. It has a wide range of nodes for every aspect of your virtual environment. If you find anything missing or want to contribute code, just let us know.

What’s New with 1.2.6

• Completely rewritten PowerPack to support VMware PowerCLI 4.0 Update 1 and its ability to manage connections to multiple $viServer objects.
• Ability to copy and paste code from “PowerShell Code” tab directly into standalone PS1 files (Will still need to Add-PSSnapin and Connect-VIServer for script to function).
• Ability to copy and paste code snippets from the internet and they will work without needing to add our $managedHost.connection code everywhere.

About vEcoShell

vEcoShell is a freeware desktop application that simplifies the daily administration of increasingly complex virtual environments. Powered by PowerGUI by Quest Software, vEcoShell leverages Windows PowerShell and VMware PowerCLI to enable administrators to easily administer their environments with virtualization PowerShell scripts.

vEcoShell currently supports the following hypervisors:

• VMware VI3 / VirtualCenter 2.5
• VMware vSphere / vCenter 4.0
• Microsoft Hyper-V

Related posts:

1. The VESI – Getting it up and running
2. PowerShell Plus™ 3.1 out now
3. PowerCLI: Reset CPU and Memory Limits

Today I noticed a memory limit on a vm. After investigating my environment using the vEcoShell and the Community PowerPack, I found more vms with memory limits set. It turned out that there was a template which had the limit set. I could easily reset all limits using the GUI, but I thought I rather do it with PowerCLI. 

Alan Renouf did a post already on a oneliner to reset all cpu and memory limits back in july 2009. After trying that code I found it rather slow. If you want to speed up things in PowerCLI you need to use the Get-View cmdlet. After some digging in the vSphere API Reference, I came up with a different peace of code that is much faster. 

First Alan’s code:

Get-VM VM001 | Get-VMResourceConfiguration | Set-VMResourceConfiguration -MemLimitMB $null

This took 18.43 seconds to complete in my environment 

My code:

$spec = new-object VMware.Vim.VirtualMachineConfigSpec
$spec.MemoryAllocation = New-Object VMware.Vim.ResourceAllocationInfo
$spec.MemoryAllocation.Limit = -1
$vm = get-view -ViewType VirtualMachine -Filter @{"Name"="VM001"}
$vm.ReconfigVM_Task($spec)

This took only 1.10 seconds to complete. 

You may notice that my code doesn’t wait for the task to complete (async) while Alan’s code does (sync), but completing the task took only 4 seconds. That makes my code still 14 times faster. 

Now since the report node is already available in the Community PowerPack, I thought it would be nice to add some actions to the PowerPack to reset the limits. 

Extending the Community PowerPack

1. Start the vEcoShell and expand the VMware Community PowerPack node 
2. Expand the Virtual Machines node 
3. Select the Reservations / Shares / Limits node 
4. Rightclick in the Actions windows on the right and select New->Script Action 
5. Enter “Reset Memory Limit” as the name for this new action 
6. Click on the “Display Configuration” button 
7. Click on the “Use Custom” Button under the Category section and enter “Resource Utils” as the new category name
    
8. Click “OK” to close the display configuration properties window 
9. Delete all sample code that is displayed on the Command tab and paste the following code:

   if ($global:defaultviservers) {
   	$Answer = [System.Windows.Forms.MessageBox]::Show("You are about to reset the Memory limits of all selected virtual machines`nClick OK to continue","Warning",[System.Windows.Forms.MessageBoxButtons]::OKCancel,[System.Windows.Forms.MessageBoxIcon]::Warning)
   	Switch ($Answer) {
   		"OK" {
   			$input | ForEach-Object {
   				$spec = new-object VMware.Vim.VirtualMachineConfigSpec
   				$spec.MemoryAllocation = New-Object VMware.Vim.ResourceAllocationInfo
   				$spec.MemoryAllocation.Limit = -1
   				$vm = get-view -ViewType VirtualMachine -Filter @{"Name"=$_.vmname}
   				$vm.ReconfigVM_Task($spec)
   			}
   		}
   		"Cancel" {}
   	}
   }
   Else {
   	[System.Windows.Forms.MessageBox]::Show('You must connect to one or more hosts before you can use this node. Please click on the ''Managed Hosts'' node of the VMware PowerPack, connect to one or more of the servers you have configured there, and then try again.','Connection not established',[System.Windows.Forms.MessageBoxButtons]::OK,[System.Windows.Forms.MessageBoxIcon]::Information) | Out-Null
   }
   

10. Click “OK” to save our script action

When you now select one or more VMs from the results window, you can reset the memory limit by simply clicking the “Reset Memory Limit” Action.

I also modified the code to reset CPU limits. Just follow the procedure above to create a “Reset CPU Limit” script action and paste the following code instead:

if ($global:defaultviservers) {
	$Answer = [System.Windows.Forms.MessageBox]::Show("You are about to reset the CPU limits of all selected virtual machines`nClick OK to continue","Warning",[System.Windows.Forms.MessageBoxButtons]::OKCancel,[System.Windows.Forms.MessageBoxIcon]::Warning)
	Switch ($Answer) {
		"OK" {
			$input | ForEach-Object {
				$spec = new-object VMware.Vim.VirtualMachineConfigSpec
				$spec.CpuAllocation = New-Object VMware.Vim.ResourceAllocationInfo
				$spec.CpuAllocation.Limit = -1
				$vm = get-view -ViewType VirtualMachine -Filter @{"Name"=$_.vmname}
				$vm.ReconfigVM_Task($spec)
			}
		}
		"Cancel" {}
	}
}
Else {
	[System.Windows.Forms.MessageBox]::Show('You must connect to one or more hosts before you can use this node. Please click on the ''Managed Hosts'' node of the VMware PowerPack, connect to one or more of the servers you have configured there, and then try again.','Connection not established',[System.Windows.Forms.MessageBoxButtons]::OK,[System.Windows.Forms.MessageBoxIcon]::Information) | Out-Null
}

Related posts:

1. PowerCLI: Match VM and Windows harddisks – Part 2
2. The VESI – Getting it up and running
3. PowerCLI: Get WMI info from isolated guests

If you are looking for migrating your Windows-based computer to a virtual environment (P2V), vice versa (V2P) or even to another hardware platform (P2P), you might want to have a look at Virtualization Manager 9.5 Personal edition from Paragon software.

Virtualization Manager 9.5 Personal allows you to:

• Migrate a Windows-based computer to a virtual environment (P2V)
• Migrate from a virtual environment to physical (V2P)
• Virtualize system from its backup image (P2V)
• Migrate from one virtual environment to another (V2V)
• Recover the OS startup ability after system migration to a different hardware or unsuccessful virtualization by a 3rd party tool (P2P and P2V Adjust)
• Clone a partition or an entire hard disk
• Exchange data between your physical environment and the virtual one, or between a virtual disk and its snapshots
• Accomplish virtual drive partitioning (create, format, delete, move, resize etc.)

Key Usage Scenarios:

This software, normally priced at $29.95, can now be obtained free of charge from Paragon Free portal starting Friday May 21, 09:00 AM (EST) till Monday May 24, 09:00 AM (EST).  Please note that it requires registration.

Grab your copy now before it’s too late!

Related posts:

1. VMware virtualization – Where do I start?

Before upgrading my Virtual Center 2.5 server to vCenter Server 4.0, I decided to temporarily disable HA and DRS. This is just a precaution taken to avoid waiting for cluster reconfigurations right after the upgrade. Because I hate doing things more than once by hand, I used PowerCLI for this.

Although no rocket science you can use the following PowerCLI oneliner to disable HA and DRS on all clusters:

Get-Cluster | Set-Cluster -HAEnabled:$false -DrsEnabled:$false -Confirm:$false

Warning:

Disabling DRS will delete any resource pool on the cluster without warning!!!
(Thanks to Daniel M (@dmVI) for pointing this out in the comments)

To enable HA and DRS again use:

Get-Cluster | Set-Cluster -HAEnabled:$true -DrsEnabled:$true -Confirm:$false

Related posts:

1. List HBA WWPNs and LUNs using Powershell
2. PowerCLI: Match VM and Windows harddisks – Part 2
3. Match VM and Windows harddisks using PowerCLI

On April 8th we had a very good DutchVMUG meeting, which was totally dedicated to using PowerCLI and The VESI (Virtualization EcoShell Initiative). Although setting up the environment is straightforward, I wanted to do a small write-up which leads you through the install process and includes all download links needed.

Installation Overview

The complete setup of the PowerCLI/The VESI environment includes 3 steps:

1. Installation of Windows PowerShell
2. Installation of VMware PowerCLI
3. Installation of The Virtualization EcoShell

It’s important that these steps are executed in this specific order. For a complete overview of download links and other interesting PowerShell/PowerCLI links, please visit my PowerCLI page.

Step 1 – Installation of Windows PowerShell

Windows XP, Windows Vista, Windows Server 2003 en Windows Server 2008

• First install the Microsoft .NET framework. I advice to install .NET framework 3.5 Service Pack 1, because this is needed if you want to use the out-gridview cmdlet.
  http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=AB99342F-5D1A-413D-8319-81DA479AB0D7
• Next install Windows PowerShell 2.0, which is part of the Windows Management Framework
  http://support.microsoft.com/kb/968929

Windows 7 en Windows 2008 R2

• No installation required, because Windows PowerShell is already pre-installed with these Windows versions.

Step 2 – Installation of VMware PowerCLI

The installation of VMware PowerCLI is very straightforward, just follow the next, next saga.
http://www.vmware.com/download/download.do?downloadGroup=sdkwin40u1

For security reasons PowerShell doesn’t allow for the execution of scripts at all by default. This mode is the “Restricted” execution policy, in which PowerShell operates as an interactive shell only. In order to execute scripts we need to change this execution policy to “RemoteSigned” to allow for the execution of our own scripts and downloaded (or remote) scripts only if they are digitally signed by a trusted publisher.

• Start PowerCLI. Go to Start > Programs > VMware > VMware vSphere PowerCLI > VMware vSphere PowerCLI
  
• Set the execution policy to “RemoteSigned” by running the following in a PowerShell prompt
  Set-ExecutionPolicy RemoteSigned


Step 3 – Installation of The Virtualization EcoShell

To install The Virtualization EcoShell just follow the next, next saga again.
http://thevesi.org/servlet/KbServlet/download/2352-102-4064/VESI.1.2.0.154.msi

Before you can run scripts inside the Virtualization EcoShell you have to add one or more managed hosts. This can be a vCenter server or just a standalone ESX server.

• Select Start>Programs>Virtualization EcoShell> Virtualization EcoShell
  
• Expand the VMware node
• Select Managed Hosts
  
• Select Add Connection
  The “Add Connection” window is displayed.
  
• Click the selection icon
  The “Select Values” window is displayed.
  
• Enter the IP address or the fully qualified domain name of a vCenter server or an ESX server.
• Click Add followed by OK
• Close the “Add Connection” window by clicking OK.

Using this procedure you can add multiple Managed Hosts. After adding Managed Hosts we need to connect to one or more before we can run a script.

• Select the Managed Host
• Click Connect
  The “Windows PowerShell Credential Request” window is displayed.
  
• Log in using a user account that has permissions on the selected Managed Host.
• After successfully connecting to the Managed Host, the “Connected” property is set to “True”.
  

PowerPack Installation

To use the full potential of the Virtualization EcoShell you have to install a PowerPack. The included VMware PowerPack already contains some powerful scripts, but there’s another mandatory PowerPack in your Virtualization EcoShell installation and that is the VMware Community PowerPack. This new PowerPack was announced on the PowerCLI/TheVESI DutchVMUG meeting by Alan Renouf and it’s the new version of his former Virtu-Al.Net PowerPack.
http://www.powergui.org/servlet/KbServlet/download/2551-102-4110/Virtu-Al.net%20Scripts.powerpack

• Select File>PowerPack Management
  
• Click Import
• Select the “Virtu-Al.net Scripts.Powerpack” file
• Click Open
  The PowerPack and its version information is shown in the “PowerPack Management” window. From here the PowerPack can also be updated when the new version becomes available.
• Click Close to close the “PowerPack Management” window.

On the left side there’s now a new “VMware Community PowerPack” node, which can be expanded to explore all those great scripts inside. Just click on a script to execute it and have it reveal that valuable information from your virtual infrastructure.

Have Fun!

Related posts:

1. PowerShell / PowerCLI linkage
2. PowerCLI: Match VM and Windows harddisks – Part 2
3. PowerShell Plus™ 3.1 out now

Everybody backups their environment, but how many do actually test if the backup can be restored? When you do, you know how time consuming this process is and even when you do a test restore, you are actually only testing that particular backup. You can’t possibly test every backup in your environment.

Veeam, an industry leader in backup technology, has come to the rescue. Today they introduced their latest SureBackup technology. This SureBackup technology will allow you to verify the recoverability of every backup, for every virtual machine, every time.

How does it work

The actual contents of the backup files are presented to an ESX host as a NFS datastore, which is automatically connected to the ESX host. VMs are created in an isolated environment and run directly from the backup. There is no need to extract the backup first. Each VM is then started and checked. A report is generated that shows if the OS is running fine and even if applications are functioning properly and data is intact.

It also supports multiple scripting languages that are available to the VM’s OS for incorporating custom scripts for verification. The differences files for the VMs can be stored on any available ESX datastore, which can be defined during the setup using the SureBackup wizard.

Universal application-item recovery

This new technology enables you to recover any virtualized application. Because of the image level backup, it’s fully OS agnostic. No special backup agents are required. It doesn’t matter which OS or even which (custom) application you are running. You can just start your VM from a backup and retrieve the items you need. Because the complete environment is started, you can use the application’s native management tools.

Availability

This new technologies will be delivered in Veeam Backup & Replication version 5.0. This is version due to be released in Q3 2010, so we have to be patient for a little while.

Visit http://www.veeam.com/surebackup for the latest developments in SureBackup technology.

Related posts:

1. VEEAM’s Free Holiday Gift
2. Setting custom attributes with VMware PowerCLI
3. Unattended upgrade of HP management agents

In my post Unattended upgrade of HP mgmt agents – Part 2 you could read about my script for an unattended installation of the HP Management agents on ESX3.5. In this part I’ll share my next version of the script for installing the HP Management agents on ESX4.0 and ESX4.0 U1.

In the ESX4 installation, the location of the smhpd.xml file is changed and a reboot is necessary afterwards instead of upfront. Simon Long did a write-up on installing and configuring HP management agents on ESX4 a couple of weeks ago, but unfortunately this was the manual way. I like automation!.

Here’s my new version of the unattend script for ESX4.0

#!/bin/sh
# +-----------------------------------------------------+
# | HP Insight Manager Agents unattend install Script   |
# |                                                     |
# | Version : 3.0                                       |
# | Author  : Arnim van Lieshout                        |
# +-----------------------------------------------------+

# version 3.0
# ==========
# This script only supports HP management agents 8.3.1 for VMware ESX4.0 and ESX4.0U1

# +-----------------------------------------------------+
# | Setting some variables                              |
# +-----------------------------------------------------+

HPPACKAGE=hpmgmt-8.3.1-vmware4x.tgz
HBAPACKAGE=qlapi_vmw-v4.00build26.tgz
HPVERSION=831
HPCONFIG=hpmgmt${HPVERSION}.conf
HPSMHCONFIG=smhpd${HPVERSION}.xml

# +-----------------------------------------------------+
# | Warn about the reboot                               |
# +-----------------------------------------------------+

SETCOLOR_YELLOW="echo -en \\033[1;33m"
SETCOLOR_RED="echo -en \\033[0;31m"
SETCOLOR_WHITE="echo -en \\033[0;39m"

$SETCOLOR_YELLOW
echo "This update requires a reboot! "
echo -n "Do you wish to continue (y/n) "
	read answer
	if [ "$answer" != "y" ]; then
		echo "Action cancelled by user"
		$SETCOLOR_WHITE
		exit
	fi
$SETCOLOR_WHITE

# +-----------------------------------------------------+
# | Check if host is in Maintenance mode                |
# +-----------------------------------------------------+

if [ `vimsh -n -e hostsvc/runtimeinfo | grep -i "inMaintenanceMode = false" | wc -l` == 1 ]; then
	$SETCOLOR_RED
	echo -e "\nHost must be in Maintenance Mode, exiting...\n\n"
	$SETCOLOR_WHITE
	exit
fi

# +-----------------------------------------------------+
# | Download files                                      |
# +-----------------------------------------------------+

/usr/sbin/esxcfg-firewall --allowOutgoing

lwp-download http://repository.mydomain.com/hpagents/$HPPACKAGE /tmp/$HPPACKAGE
lwp-download http://repository.mydomain.com/hpagents/$HBAPACKAGE /tmp/$HBAPACKAGE
lwp-download http://repository.mydomain.com/hpagents/$HPCONFIG /tmp/$HPCONFIG
lwp-download http://repository.mydomain.com/hpagents/$HPSMHCONFIG /tmp/$HPSMHCONFIG

/usr/sbin/esxcfg-firewall --blockOutgoing

# +-----------------------------------------------------+
# | Unpack archives                                     |
# +-----------------------------------------------------+

cd /tmp
tar -zxvf $HPPACKAGE
mkdir /tmp/hbaapi
tar -C /tmp/hbaapi -zxvf $HBAPACKAGE
mkdir /opt/hp
mkdir /opt/hp/hp-agents-config
cp /tmp/$HPSMHCONFIG /opt/hp/hp-agents-config/smhpd.xml

# +-----------------------------------------------------+
# | Uninstall old packages                              |
# +-----------------------------------------------------+

cd /tmp/hpmgmt/$HPVERSION
echo -e 'y\ny' | ./install${HPVERSION}vibs.sh --uninstall
cd /tmp/hbaapi
./Remove.sh

# +-----------------------------------------------------+
# | Install new packages                                |
# +-----------------------------------------------------+

cd /tmp/hbaapi
./Install.sh
cd /tmp/hpmgmt/$HPVERSION
./install${HPVERSION}vibs.sh --silent --inputfile /tmp/$HPCONFIG

# +-----------------------------------------------------+
# | Reboot host as requested by the HP agents installer |
# +-----------------------------------------------------+
shutdown -r now "System shutdown to complete HP agents installation"

You can also download a copy of the script here.

Always test this in a test environment first before using it in production. I don’t take any responsibilities for things that might happen to your ESX servers due to using this script.

Related posts:

1. Unattended upgrade of HP mgmt agents – Part 2
2. Unattended upgrade of HP management agents
3. Monitor ESX datastores using Hostmonitor