Using vMA as a local vSphere Patch Repository

I like using http as the transport protocol when patching my vSphere hosts. It’s easy to use and in most cases immediately available over most networks. Since I want to use http as the transport, we need to make vMA work as a http server.

Starting Apache inside vMA

Luckily, the Apache http daemon is installed, by default, in vMA and to utilize it all you have to do is to start it!

Log on to vMA with your favorite SSH client and run the following command to start the Apache HTTP Daemon:

[[email protected] /]$ sudo service httpd start
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using for  ServerName                   [ OK ]
[[email protected] /]$

Never mind the error message it displays, for our purposes 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 create a new directory

[[email protected] /]$ cd /var/www/html/
[[email protected] html]$ sudo mkdir repo

We’ve now created the repo directory inside the Apache docroot. Now we need to add some patches to that directory, to make it available for the vihostupdate or esxupdate command we can use to patch our hosts.

In my lab, I used the update-from-esxi4.1-4.1_update01 patch bundle from

To download the patch into the new repo directory created above, run the following commands:

[[email protected] html]$ cd /var/www/html/repo/
[[email protected] repo]$ sudo wget
	Connecting to||:443... connected.
	HTTP request sent, awaiting response... 200 OK
	Length: 215820281 (206M) [application/zip]
	Saving to: `'

215,820,281  919K/s   in 3m 54s
15:38:26 (901 KB/s) - `' saved [215820281/215820281]

This downloads the patch bundle, using the wget command, to the current directory.

Now, to make sure your downloaded patch bundle is available via the web server, open http://vMA-IP/repo/ and you should see the directory contents listed. Your browser should display something similar to this:

Before patching a host, power off or migrate any virtual machines that are running on the host and place the host into maintenance mode.

Scan host for update compatibility

[[email protected] repo]$ vihostupdate --server --scan --bundle
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

[[email protected] repo]$ vihostupdate --server --install --bundle
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.
[[email protected] repo]$

While the update runs, you can also follow it’s progress in the vSphere Client

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


Now, downloading the patches this way for each vMA instance you have (especially if you have several remote sites) is not very effective. Sure, you could place a central repository at a central site and use that as your central update repository. In that scenario you might as well just use the VMware vCenter Update Manager and not have to manage your updates via vMA at all.

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

I’m investigating a possible solution for that as well, and I’ll post that as soon as I have working proof of concept up and running.

Another thing to note, is that when you restart vMA the http service will be stopped again. If you want it to autostart each time vMA boots, issue the following command

[[email protected] repo]$ sudo ntsysv

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

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

Installing vSphere Management Assistant (vMA)

The vMA is a Virtual Appliance that you can download from VMware. It’s primary function is to enable command line based management of your ESX/ESXi systems.

Basically this is a pre-packaged virtual machine that  includes vCLI and the vSphere SDK for Perl, which means that you don’t have to build your own management VM or install these tools locally on a management station.

vMA is in many regards seen as a replacement for the ESX Service Console which no longer is  present in ESXi.

Downloading vSphere Management Assistant (vMA)

Basically there are two methods you can use when deploying vMA.

  1. Download the .OVF file to your local machine and upload it to your ESX/ESXi host.
    This is useful if you have already downloaded the vMA appliance and plan on deploying it to several hosts/clusters. This saves you from downloading it several times, and you can even use PowerCLI to automate the deployment of vMA, but I’m not going into that scenario this time around.
  2. Deploy the .OVF file directly from, via the vSphere Client, to your host.

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

Direct Deployment of vMA

Start your vSphere Client and connect to your host or vCenter.

Navigate to “File“, find and select the “Deploy OVF template” option

This starts the OVF deployment wizard. In the “Deploy from a file or URL”  text box, enter the following URL: and click on “Next“.

Note: This URL is valid at the point of writing, but might change at a later date when a new version is released by VMware.

The URL is now validated, and you are presented with the OVF Template Details window, where you can review the settings defined in the OVF file.

Click “Next”  to view and accept the VMware EULA. After reading it throroughly click on “Accept” and then on “Next” again to continue

Next up is the “Name and Location” screen, where you can customize the name of your vMA instance. If you are deploying the several vMA instances to the same host/vCenter, you will need to change this to prevent naming conflicts.

After naming your vMA, click on “Next” again, and you’ll get presented with the “Disk Format” screen. Here you can select between thin provisioned or thick provisioned disks, for this installation I chose to change it to thin provisioned, but the default is thick provisioned disks.

After making your selection, we once again click on “Next” and now we’re nearly there! Review the summary screen to make sure you have selected the right options and  click on “Finish” to finally  start the download and deployment of your vMA.

The download starts, and a nice little progress window shows you how far along you are.

Of course, the time it takes to deploy vMA this way is highly dependant on available bandwidth and download speeds. In this particular environment the download is estimated to take approximately 39 minutes.

Tip: If you want to deploy vMA in this manner, to several hosts, you can place the downloadable vMA .OVF file on an accessible file share or http server and serve your local path or URL to your host via the vCenter Client as well. This is particularly useful in scenarios where your vCenter Client doesn’t have internet access or if you want to speed up deployment by downloading it only once, but without scripting it.

Once the vMA has finished downloading and installing, it will pop up inside your vSphere Client on the host you deployed it to.

vMA Initial Configuration

The first time you start vMA, it fires a configuration wizard to help you configure it.
The wizard guides you through the network setup and setting the vi-admin user password.

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

For details on using vMA and vCLI see the vSphere Management Assistant (vMA) site. You can even add ESX/ESXi and vMA to your Active Directory and use that as an authentication source, but I’ll leave that for another post on another day.