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).

Figure 1 - vSphere C# Client VUM Integration

Figure 1 – vSphere C# Client VUM Integration

 

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.

Figure 2 - vSphere Web Client VUM Integration

Figure 2 – vSphere Web Client VUM Integration

 

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.

Figure 3 - VUM & Microsoft OS compatibility matrix

Figure 3 – VUM & Microsoft OS compatibility matrix

 

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.

Figure 4 - Using the Product Interoperability Matrix to determine database options

Figure 4 – Using the Product Interoperability Matrix to determine database options

 

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.

 

  1. 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.

    Figure 5 - 32-bit DSN

    Figure 5 – 32-bit DSN

  1. 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.

Figure 6 - VMware vSphere Update Manager sizing Estimator

Figure 6 – VMware vSphere Update Manager sizing Estimator

 

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.

[the_ad id=”4738″][the_ad id=”4796″]

 

Altaro VM Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

27 thoughts on "All You Need to Know About vSphere Update Manager – Part 1"

  • Jeff Bernstein says:

    Does the vSphere Update Manager installation affect the vCenter Server database in any way? We want to take a look at VUM but would like the option to back it out if we decide not to use it. We’re on vSphere 5.5 Update 1.

    Thanks!

    • Jason Fenech says:

      Hi Jeff,

      VUM uses its own database, DSN, etc, and I’ve never came across any documentation that states that changes are made to the vCenter database. I’ve removed VUM without any problems a number of times so you should be safe. Having said that, if you’re running a virtualized vCenter Server, make sure to back it up first and take a snapshot. If you’re running the vCenter database on a dedicated SQL server, take a full database backup prior to installing VUM. Other than that, you should be good to go.

      regards

      Jason

  • Mike says:

    In an environment where the vSphere server and the Platform Services are installed on separate servers, which server should the Update Manager be installed on?

    • Jason Fenech says:

      Hi,

      If you have a windows license to spare, I’do go for a dedicated box with an extra disk for updates, patches, etc. This imho makes for pain-free management and/or decommissioning. If licensing is an issue, either existing server should do. Just remember you’ll need extra disk space for the patch repository.

      Regards

      Jason

  • Quintus du Bruyn says:

    Hi Jason,

    Thanks for the info!

    Quick question: Can you run 1 VUM on a dedicated server for various VC environments? I.E, we have 4 VCenters each running its own environment. Can I have 1 Update manager to update all those VC’s, hosts, etc., or do I need one VUM per environment?

    Regards

    • Jason Fenech says:

      Hi,

      Thanks for your comments. I’m afraid you have to have a VUM instance for every single vCenter Server instance. Similarly, I think it would be great if one could service multiple vCenter Server using one VUM server but I don’t think this is going to happen anytime soon. I’ve included a couple of links for you;

      VMware Documentation
      VMware Forum

      regards

      Jason

  • Carlos says:

    Thanks, Jason

    One question about VUM: in low version for vmware you could manage updates for the SO (Windows, Linux, etc), do you know this possibility with version 6? Do you know any source to add to VUM for MS Updates? Tahnks so much.

  • Rohit says:

    Do you have videos demonstrating these steps too?

  • Chris says:

    Hi Jason,

    If we put it on a separate SQL Server instance, do you happen to know what the minimum MIN/MAX RAM settings for the instance are? (i.e. this is set inside SQL Server for the max amount that SQL will consume from the OS). For example, if I have a 12 GB Windows Server with SQL running on it, I can safely set MIN 2GB and MAX 8 GB within SQL server, and this would be safe relative to the OS memory. Do you happen to know from experience what the lowest would be (e.g. would 2/4GB work for Min/Max?)

  • Ben says:

    Hi Jason,

    Great post. Quick question:
    Is it possible to install the SQL database on the same server as the VUM?
    What would be the implications?

    Thanks

  • Patrick says:

    I see lots of articles about updating vmtools using update manager, but nothing about how to update the vmtools repository in update manager. Using 6.5, I get an error that the ISO doesn’t exist. When I look in update manager admin view, I can’t edit the predefined repositories and the last update was in 2013, so I have lots of VMs running vmtools from 5.0 and no way to update them. Do you know how to do this?

    • Jason Fenech says:

      Hi,

      Download the latest vmtools or the one you need from my.vmware (note that support for older operating systems may have been dropped) and overwrite the contents of /vimages/tools-isoimages. You can then use something like winscp to upload the files. Once you do that, right click on the VM, and select Upgrade VMware Tools from the Guest OS menu.

      Afaik, there is no way you can automate this using update manager but I’ll definitely look into it. That said, you can patch vmtools on ESXi via the tools-light VIB using update manager.

      regards

      Jason

  • Noor says:

    Great in depth explanation Thanks a lot

  • Hahn says:

    How are you?

    Nice to be part of your community.

Leave a comment

Your email address will not be published. Required fields are marked *