All You Need to Know About vSphere Update Manager – Part 1

Patch management is an integral component of any organization’s security policy. The aim is to mitigate security threats through preventive maintenance. Needless to say, patching up systems in a timely fashion in response to freshly discovered vulnerabilities and ensuing exploits, is vital. Ignore it at your own peril but it’s a safe bet to say that your system will end up compromised sooner or later if you do so.

In part one of this 2-part series, I’ll be discussing VMware’s vSphere Update Manage (VUM) covering both the requirements and deployment models. In part 2, I will take you through the installation steps and a few usage scenarios.

What is vSphere Update Manager (VUM)?

vSphere Update Manager (VUM) is VMware’s take on centralizing patch and version management for ESXi hosts, virtual applications (vApps) and virtual machines. If you’re familiar with patching Microsoft software, you can think of VUM in terms of Windows Server Update Services, the only difference being that VUM is by far more versatile and powerful.

Typical VUM is used for;

• ESXi host compliance and patch baselines
• Upgrading hardware levels for virtual machines
• Upgrading vmtools on virtual machines
• Virtual appliances upgrades
• Installing and upgrading 3rd party software on ESXi hosts

VUM follows a client-server model. Depending on the size of your vSphere environment, the server-side components are either installed on the same computer running vCenter Server or on a dedicated computer. As for the client, VUM readily integrates with the vSphere C# client. Using Plug-in Manager, you’ll download and install the VMware vSphere Update Manager Extension which is made available after VUM server has been installed (Figure 1).

Better still, you’ll find that VUM is enabled automatically when using the vSphere Web Client. This basically means that no user intervention is required to activate it. As per Figure 2, you should see the Update Manager icon visible on the Home screen.

Planning and Installation Requirements

There are a few requirements to consider and planning decisions to take before diving in and installing VUM.  I’ll cover the hardware and software requirements and the process of setting up a database for VUM. I’ll also briefly discuss the Download Service for the more security conscious admins out there.

Hardware Requirements

Let me start by citing VMware’s minimum hardware requirements for installing VUM.

• A processor with 2 logical cores running at 2GHz
• A 10/100/1000Mbit network connection with 1Gbit recommended for best performance
• 2GB RAM if running VUM on a separate computer than vCenter Server
• 8GB RAM if running VUM on the same computer running vCenter Server
• Sufficient disk space for the VUM database and patch repository (see disk capacity planning below)

Software Requirements

The software requirements will vary according to the database approach taken and on whether or not VUM is installed alongside vCenter Server on the same computer. As obvious as it sounds you need to have vCenter Server installed prior to deploying VUM.

Note: VUM should never be installed on a Microsoft Active Directory domain controller.

Supported Operating Systems

Starting with v5.0, installing VUM on a Microsoft Windows 64-bit operating system is strictly required. There’s no two ways about it. Chances are that you’ll be installing VUM v5.5 or a later version. This narrows down options to Windows Server 2008 SP1 / 2008 R2 SP1 64-bit and Windows Server 2012 / 2012 R2 64-bit (see Figure 3). You can refer to this article for further details.

Note: Keep in mind that Microsoft no longer supports Windows Server 2003 Server (or XP for that matter). I’ve grouped these in red in Figure 3. You’ll probably end up deploying one of the VUM versions grouped in green given the availability of v6.0 U1 at the time of writing.

Supported Database Options

A SQL database is required by VUM for its operations using either a Microsoft or Oracle Database solution. I suggest using VMware’s Product Interoperability Matrix to determine which database options are compatible with the VUM version being installed. For instance, you’ll find that VUM v6.0 U1 will run on the various flavors of MS SQL Server 2008, 2012 and 2014 as well as Oracle 11g and 12c.

Choosing your database

The chosen database model and vendor depend on the vSphere environment at hand. The SQL Server 2012 Express edition bundled with VUM will suffice for small vSphere environments which typically consist of 5x ESXi servers hosting at most 50x virtual machines. That said, keep in mind the limitations of SQL Express, namely, a maximum database size of 10GB and a maximum 1GB RAM allocation for the database engine.

Note: Make sure that MSI 4.5 or later is installed on the server when using the bundled SQL Server 2012 Express.

For larger vSphere environments, a fully-fledged Microsoft or Oracle DBMS solution running on a dedicated computer(s) is a must. VMware also recommends that you do not place the VUM database on the same database computer hosting the vCenter Server database. I personally think this recommendation to be somewhat subjective as it should be viewed in context of the computing resources allocated to the database server(s) used and current workload.

Oracle is not my forte, so I’ll be covering Microsoft SQL Server as part of the deployment process. There are a number of steps you need to undertake when preparing the VUM database, which I briefly list below, assuming the reader is familiar with managing Microsoft SQL Server.

Note: These steps are carried out automatically should you choose to use the bundled SQL Server Express edition. 

1. Setting up the VUM database. You’ll need to;

• Create a blank database using SQL Server Management Studio. Let’s call it VUM. The database is automatically populated during the VUM installation process.
• Create an SQL user. Grant it DBO rights and sysadmin / db_owner roles on the VUM and MSDB databases.
• Check the type of SQL Server Authentication in use, i.e. either Windows or Mixed authentication mode.

2. Create a 32-bit data source name (DSN) as per Figure 5 by running C:\Windows\SysWOW64\odbcad32.exe on the computer where VUM will be installed. This is required since VUM is fundamentally a 32-bit application albeit 64-bit compatible.

   

3. Configure the OBDC connection. Basically you’ll edit the 32-bit DSN just created specifying the database name (VUM) together with the SQL user account information required to access it.

If you’re using an Oracle database instead, you’ll find the relevant steps documented here. The process is slightly more involving as it requires you to create and configure database resources using SQL statements.

Disk Capacity Planning

For large vSphere deployments, you’ll probably want to estimate the disk space allocated to the patch repository and database files. This could matter – in terms of disk space availability – if you’re hosting the VUM database on the same computer running VUM (All-in-one model). Thankfully, VMware’s VUM Sizing Estimator makes disk space planning a piece of cake.

The tool basically consists of a two sheet Excel file. The first sheet lays down the details on how to use the tool. On the second sheet, details pertaining to your vSphere environment are entered, based on which, an indication of the initial and future monthly disk utilization is given. Depending on the size of your environment, the tool will also advise on the server and database deployment model you should use.

An example of the tool’s usage is provided in Figure 6.  Note that I specified a vSphere environment consisting of 10 ESXi 6.0 hosts running a total of 5 vApps and 250 virtual machines. Based on the figures supplied, the tool returned the following:

• An initial 150MB of disk space taken up by the VUM database with an anticipated median growth of 60MB
• An initial 3098MB of disk space taken up by the patch repository with an anticipated growth of 1.2GB
• The VUM database can be run alongside the vCenter Server database – on the same database server
• VUM can be installed on the same computer running vCenter Server

You can thus easily plan ahead. Let’s say you want to calculate the disk space consumed over a period of say 2 years based on the figures above.

Database:            150 MB + (24 * 60) MB = 1.6 GB
Repository:         3.1 GB   + (24 * 1.2) GB = 31.9 GB

This adds up to 33.5GB of disk space and even though this is insignificant given today’s low disk cost per GB and high availability, it nevertheless serves the example.

TIP: Personally, I prefer to set aside a dedicated disk for the patch repository and the database more so if both are hosted on the same physical or virtual machine. This allows for better management and troubleshooting. If you’re running VUM off a virtual machine, then it is just a matter of adding space to the dedicated vmdk and expanding it in Windows.

Choosing a security model

VUM provides an optional component called the Update Manager Download Service (UMDS). Think of UMDS as being a proxy server the role of which is to download and recall updates on behalf of a VUM server. De-coupling the process of downloading updates from the actual distribution may be enforced by an organization’s security policy. In this scenario, a UMDS server is placed in a DMZ (an Internet facing perimeter network) with the VUM server placed on a “safe” internal network. Network traffic between the two is regulated via firewall rules and policies.

VMware calls the DMZ implementation the Air-gap model. On the other hand, the Internet-connected model is used to represent a VUM server with full Internet access.

Full details on how to set up and configure UMDS may be found here.

Conclusion

This concludes part one of this series dedicated to VUM and the role it plays in securing your vSphere environment. We’ve also looked at the various requirements, some capacity planning and deployment models.

In the upcoming second post from this series, we’ll look at how to install VUM and how to use it to keep our vSphere environments in top shape.