I like using http as the trans­port pro­to­col when patch­ing my vSphere hosts. It’s easy to use and in most cases imme­di­ately avail­able over most net­works. Since I want to use http as the trans­port, we need to make vMA work as a http server.

Start­ing Apache inside vMA

Luck­ily, the Apache http dae­mon is installed, by default, in vMA and to uti­lize it all you have to do is to start it!

Log on to vMA with your favorite SSH client and run the fol­low­ing com­mand to start the Apache HTTP Daemon:

[vi-admin@vMA /]$ sudo service httpd start
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for  ServerName                   [ OK ]
[vi-admin@vMA /]$

Never mind the error mes­sage it dis­plays, for our pur­poses that’s not an issue and we can safely ignore it.

By default the files served by Apache is located in /var/www/html, so we’ll head over there to cre­ate a new directory

[vi-admin@vMA /]$ cd /var/www/html/
[vi-admin@vMA html]$ sudo mkdir repo

We’ve now cre­ated the repo direc­tory inside the Apache doc­root. Now we need to add some patches to that direc­tory, to make it avail­able for the vihos­tup­date or esx­up­date com­mand we can use to patch our hosts.

In my lab, I used the update-from-esxi4.1–4.1_update01 patch bun­dle from vmware.com

To down­load the patch into the new repo direc­tory cre­ated above, run the fol­low­ing commands:

[vi-admin@vMA html]$ cd /var/www/html/repo/
[vi-admin@vMA repo]$ sudo wget https://hostupdate.vmware.com/software/VUM/OFFLINE/release-260-20110127-912579/update-from-esxi4.1-4.1_update01.zip
Password:
--15:34:32--  https://hostupdate.vmware.com/software/VUM/OFFLINE/release-260-20110127-912579/update-from-esxi4.1-4.1_update01.zip
	Resolving hostupdate.vmware.com... 88.221.164.7
	Connecting to hostupdate.vmware.com|88.221.164.7|:443... connected.
	HTTP request sent, awaiting response... 200 OK
	Length: 215820281 (206M) [application/zip]
	Saving to: `update-from-esxi4.1-4.1_update01.zip'
100%[===============================================================================================================>] 

215,820,281  919K/s   in 3m 54s
15:38:26 (901 KB/s) - `update-from-esxi4.1-4.1_update01.zip' saved [215820281/215820281]

This down­loads the patch bun­dle, using the wget com­mand, to the cur­rent directory.

Now, to make sure your down­loaded patch bun­dle is avail­able via the web server, open http://vMA-IP/repo/ and you should see the direc­tory con­tents listed. Your browser should dis­play some­thing sim­i­lar to this:

Before patch­ing a host, power off or migrate any vir­tual machines that are run­ning on the host and place the host into main­te­nance mode.

Scan host for update compatibility

[vi-admin@vMA repo]$ vihostupdate --server 10.0.100.20 --scan --bundle http://10.0.101.14/repo/update-from-esxi4.1-4.1_update01.zip
Enter username: root
Enter password:
The bulletins which apply to but are not yet installed on this ESX host are listed.
 
---------Bulletin ID---------   ----------------Summary-----------------
ESXi410-201101201-SG            Updates the ESXi 4.1 firmware
ESXi410-201101202-UG            Updates the ESXi  4.1 VMware Tools
ESXi410-201101223-UG            3w-9xxx: scsi driver for VMware ESXi
ESXi410-201101224-UG            vxge: net driver for VMware ESXi
ESXi410-Update01                VMware ESXi 4.1 Complete Update 1

Install updates to host

[vi-admin@vMA repo]$ vihostupdate --server 10.0.100.20 --install --bundle http://10.0.101.14/repo/update-from-esxi4.1-4.1_update01.zip
Enter username: root
Enter password:
Please wait patch installation is in progress ...
The update completed successfully, but the system needs to be rebooted for the changes to be effective.
[vi-admin@vMA repo]$

While the update runs, you can also fol­low it’s progress in the vSphere Client

When the patch has com­pleted, and the host has been rebooted you can run the scan com­mand again to make sure all of the patches are installed and no longer required.

Man­age­ment

Now, down­load­ing the patches this way for each vMA instance you have (espe­cially if you have sev­eral remote sites) is not very effec­tive. Sure, you could place a cen­tral repos­i­tory at a cen­tral site and use that as your cen­tral update repos­i­tory. In that sce­nario you might as well just use the VMware vCen­ter Update Man­ager and not have to man­age your updates via vMA at all.

In some cases though, you would want to have the remote hosts install their updates from a local repos­i­tory. One such case might be if you have remote loca­tions with low bandwidth/high latency links that you don’t want to stress with the update downloads.

I’m inves­ti­gat­ing a pos­si­ble solu­tion for that as well, and I’ll post that as soon as I have work­ing proof of con­cept up and running.

Another thing to note, is that when you restart vMA the http ser­vice will be stopped again. If you want it to autostart each time vMA boots, issue the fol­low­ing command

[vi-admin@vMA repo]$ sudo ntsysv
Password:

This brings up a screen where you can choose which dae­mons should start at boot time inside of vMA.

Find httpd, select it and hit the OK but­ton. The next time vMA boots, the Apache web server starts with it.

Chris­t­ian Mohn

The vMA is a Vir­tual Appli­ance that you can down­load from VMware. It’s pri­mary func­tion is to enable com­mand line based man­age­ment of your ESX/ESXi systems.

Basi­cally this is a pre-packaged vir­tual machine that  includes vCLI and the vSphere SDK for Perl, which means that you don’t have to build your own man­age­ment VM or install these tools locally on a man­age­ment station.

vMA is in many regards seen as a replace­ment for the ESX Ser­vice Con­sole which no longer is  present in ESXi.

Down­load­ing vSphere Man­age­ment Assis­tant (vMA)

Basi­cally there are two meth­ods you can use when deploy­ing vMA.

1. Down­load the .OVF file to your local machine and upload it to your ESX/ESXi host.
   This is use­ful if you have already down­loaded the vMA appli­ance and plan on deploy­ing it to sev­eral hosts/clusters. This saves you from down­load­ing it sev­eral times, and you can even use Pow­er­CLI to auto­mate the deploy­ment of vMA, but I’m not going into that sce­nario this time around.
2. Deploy the .OVF file directly from vmware.com, via the vSphere Client, to your host.

In this post, I’ll focus on how to deploy vMA using method 2 — Direct Deployment

Direct Deploy­ment of vMA

Start your vSphere Client and con­nect to your host or vCenter.

Nav­i­gate to “File”, find and select the “Deploy OVF tem­plate” option

This starts the OVF deploy­ment wiz­ard. In the “Deploy from a file or URL”  text box, enter the fol­low­ing URL: http://download3.vmware.com/software/vma/vMA-4.1.0.0–268837.ovf and click on “Next”.

Note: This URL is valid at the point of writ­ing, but might change at a later date when a new ver­sion is released by VMware.

The URL is now val­i­dated, and you are pre­sented with the OVF Tem­plate Details win­dow, where you can review the set­tings defined in the OVF file.

Click “Next”  to view and accept the VMware EULA. After read­ing it thro­r­oughly click on “Accept” and then on “Next” again to continue

Next up is the “Name and Loca­tion” screen, where you can cus­tomize the name of your vMA instance. If you are deploy­ing the sev­eral vMA instances to the same host/vCenter, you will need to change this to pre­vent nam­ing conflicts.

After nam­ing your vMA, click on “Next” again, and you’ll get pre­sented with the “Disk For­mat” screen. Here you can select between thin pro­vi­sioned or thick pro­vi­sioned disks, for this instal­la­tion I chose to change it to thin pro­vi­sioned, but the default is thick pro­vi­sioned disks.

After mak­ing your selec­tion, we once again click on “Next” and now we’re nearly there! Review the sum­mary screen to make sure you have selected the right options and  click on “Fin­ish” to finally  start the down­load and deploy­ment of your vMA.

The down­load starts, and a nice lit­tle progress win­dow shows you how far along you are.

Of course, the time it takes to deploy vMA this way is highly depen­dant on avail­able band­width and down­load speeds. In this par­tic­u­lar envi­ron­ment the down­load is esti­mated to take approx­i­mately 39 minutes.

Tip: If you want to deploy vMA in this man­ner, to sev­eral hosts, you can place the down­load­able vMA .OVF file on an acces­si­ble file share or http server and serve your local path or URL to your host via the vCen­ter Client as well. This is par­tic­u­larly use­ful in sce­nar­ios where your vCen­ter Client doesn’t have inter­net access or if you want to speed up deploy­ment by down­load­ing it only once, but with­out script­ing it.

Once the vMA has fin­ished down­load­ing and installing, it will pop up inside your vSphere Client on the host you deployed it to.

vMA Ini­tial Configuration

The first time you start vMA, it fires a con­fig­u­ra­tion wiz­ard to help you con­fig­ure it.
The wiz­ard guides you through the net­work setup and set­ting the vi-admin user password.

And there it is. Now you can use your favorite SSH client (Putty) to con­nect to the vMA, or by using the con­sole in the vSphere Client.

For details on using vMA and vCLI see the vSphere Man­age­ment Assis­tant (vMA) site. You can even add ESX/ESXi and vMA to your Active Direc­tory and use that as an authen­ti­ca­tion source, but I’ll leave that for another post on another day.

Chris­t­ian Mohn