• Home
• Install and configure vCenter update manager - VCP-410 Prep

Install and Configure vCenter Update Manager

Software patches are, unfortunately, a fact of life in today's IT departments. Most organizations recognize that it is impossible to create 100 percent error-free code and that software patches will be necessary to correct problems or flaws or to add new features. Fortunately, VMware offers a tool to help automate this process for vSphere. This tool is called vCenter Update Manager (VUM).

vCenter Update Manager Overview

VUM is a tool designed to help VMware administrators automate and streamline the process of applying updates-which could be patches or upgrades to a new version-to their vSphere environment. VUM is fully integrated within vCenter Server and offers the ability to scan and remediate ESX/ESXi hosts, virtual appliances, virtual machine templates, and online and offline virtual machines running certain versions of Windows, Linux, and some Windows applications. VUM can also upgrade VMware Tools and upgrade virtual machine hardware. Further, VUM is the vehicle used to install and update the Cisco Nexus 1000V third-party distributed virtual switch.

VUM also does the following:

• Integrates with VMware Distributed Resource Scheduler (DRS) for non-disruptive updating of ESX/ESXi hosts. Here "updating" means both applying software patches, as well as upgrading to new versions of ESX/ESXi.

• Can apply snapshots prior to updating VMs to pnahlp rollhack in thp pvpnt of a prohlpm

• Identifies VMs with outdated VMware Tools and assists in upgrading them

• Fully integrates configuration and administration into VMware vCenter and the vSphere Client

To help keep ESX/ESXi hosts and guest operating systems patched and up-to-date, VUM communicates across your company's Internet connection to download information about available updates, the products to which those updates apply, and the actual updates themselves. Based on rules and policies that are defined and applied by the VMware administrator using the vSphere Client, VUM will then apply updates to hosts and guest operating systems. The installation of updates can be scheduled and even offline virtual machines can have updates applied to the guest operating systems installed on them.

Putting VUM to work in your vSphere deployment involves installing and configuring VUM, setting up baselines, scanning hosts and guest operating systems, and applying patches.

vCenter Update Manager Installation

VUM installs from the vCenter Server Installer and requires that at least one vCenter Server instance is already installed. You will find that installing VUM is much like installing vCenter Server, which you saw in the previous chapter.

Perform the following general steps to install VUM:

1. Configure the separate database server for VUM.

2. Create an Open Database Connectivity (ODBC) data source name (DSN) for VUM.

3. Install VUM.

4. Configure the VUM services to support Windows authentication.

5. Install the VUM plug-in for the vSphere Client.

Let's examine each of these steps in a bit more detail

Configuring the Separate Database Server

Like vCenter Server, VUM requires a separate database server. Where vCenter Server uses the separate database server to store configuration and performance statistics, VUM uses the separate database server to store patch metadata. I will use the term separate database server simply to refer to a database application that is configured and managed independently of any of the VMware vCenter products.

VUM can use an instance of SQL Server 2005 Express Edition for small installations, up to 5 hosts and 50 virtual machines. SQL Server 2005 Express Edition is included on the VMware vCenter media, and the VUM installation will automatically install and configure this SQL Server 2005 Express instance appropriately. No additional work is required outside of the installation routine. However, as you learned from my discussion of vCenter Server in Chapter 3, SQL Server 2005 Express Edition does have some limitations, so plan accordingly. For the rest of my discussion here, I'll assume that you are not using SQL Server 2005 Express Edition. If you do plan on using SQL Server 2005 Express Edition, you can skip ahead to the next section.

If you've decided against using SQL Server 2005 Express Edition, you must now make another decision: where do you put the VUM database? Although it is possible for VUM to use the same database as vCenter Server, it is strongly recommended that you use a separate database, even if you will keep both databases on the same physical computer. For environments with fewer than 30 hosts, it's generally safe to keep these databases on the same computer, but moving beyond 30 hosts or 300 virtual machines, it's recommended to separate the vCenter Server and VUM databases onto different physical computers. When you move beyond 100 hosts or 1,000 virtual machines, you should be sure to use separate database servers for both the vCenter Server database and the VUM database as well as separate servers for vCenter Server and the VUM server software. Other factors, such as high availability or capacity, may also affect this decision.

Aside from knowing which database server you'll use, the decision to use a single computer vs. multiple computers won't affect the procedures described in this section. In either case, whether hosting the VUM database on the same computer as the vCenter Server database or not, there are specific configuration steps that you'll need to follow, just as you did when installing vCenter Server. You'll need to create the database, assign ownership, and grant permissions to the MSDB database. Be sure to complete these steps before trying to install VUM, because this information is required during installation.

vCenter Update Manager Installation

Now that you have met all the prerequisites-at least one instance of vCenter Server running and accessible across the network, a separate database server running and configured appropriately, and an ODBC DSN defined to connect to the preconfigured database-you can start the VUM installation. Before you begin, make sure that you have a note of the ODBC DSN you defined earlier and, if using SQL authentication, the username and password configured for access to the database.

The VUM installation differs from the vCenter Server installation here with regard to the use of Windows authentication. When installing vCenter Server, you needed to log in as the user under whose context the vCenter Server services should run. In other words, if the vCenter Server services should run in the context of the user vcenter, then you needed to log in as vcenter when you ran the installation. This is not the case with VUM. Instead, if you are using Windows authentication, you'll need to manually switch the account under which the services run after installation.

After installing VUM, you might think that is all there is needed for the updates. But it is not quite ready to run. Remember that you've configured VUM to use Windows authentication. Before you can actually use VUM, you must first configure the VUM services and the user account under which those services will run.

Configuring the VUM Services

As I noted earlier, VUM supports using either SQL authentication or Windows authentication for connecting to the separate database server. In environments using SQL authentication, the VUM installer prompts for SQL credentials, and upon the completion of installation, VUM is ready to use. In environments using Windows authentication, there's an additional step. You must specify the user account under which the VUM services will run. If you do not, these services will run as the LocalSystem account. The LocalSystem account, however, has no way of authenticating across the network, and therefore VUM will fail to operate because it cannot authenticate to the separate database server. To prevent this situation, you must change the user account under which the services nm. Before you begin this procedure, be sure you know the username and password of the account under which the services should run (this should be the same account that was configured for ownership of the database).

After following the steps in the lab, you have installed VUM. You have no way to manage it. In order to manage VUM, you must install the VUM plug-in for vCenter Server and the vSphere Client, as discussed in the next section.

Installing the vCenter Update Manager Plug-In

The tools to manage and configure VUM are implemented as vCenter Server plug-ins and are completely integrated into vCenter Server and the vSphere Client. However, to access these tools, you must first install and register the plug-in in the vSphere Client. This enables the vSphere Client to manage and configure VUM by adding an Update Manager tab and some extra context menu commands to objects in the vSphere Client. vSphere Client plug-ins are managed on a per-client basis; that is, each installation of the vSphere Client needs to have the plug-in installed in order to access the VUM administration tools.

To install VUM as a Plug-in, follow the steps in the accompanied lab. After going through the steps and installing VUM plug-in, you need to remember that the VUM plugin is per instance of the vSphere Client, so you need to repeat this process on each installation of the vSphere Client. After that is done, you are ready to configure VUM for your environment.

Configure vCenter Update Manager

After you have installed and registered the plug-in with the vSphere Client, a new Update Manager icon appears on the vSphere Client home page. In addition, when in the Hosts And Clusters or VMs And Templates inventory view, a new tab labeled Update Manager appears on objects in the vSphere Client. From this Update Manager tab, you can scan for patches, create and attach baselines, stage patches to hosts, remediate hosts and guests, and perform all the other tasks involved in configuring and managing VUM. Clicking the Update Manager icon at the vSphere Client home page takes you to the main VUM administration screen.

Baselines and Groups

Baselines are a key part of how VUM works. In order to keep ESX/ESXi hosts and guest operating systems updated, VUM uses baselines.

VUM uses several different types of baselines. First, baselines are divided into host baselines, designed to be used in updating ESX/ESXi hosts, and VM/VA baselines, which are designed to be used to update virtual machines and virtual appliances. Baselines are further subdivided into patch baselines and upgrade baselines. Patch baselines define lists of patches to be applied to an ESX/ESXi host or guest operating system; upgrade baselines define how to upgrade an ESX/ESXi host or virtual appliance. Because of the broad differences in how various guest operating systems are upgraded, there are no upgrade baselines for guest operating systems. There are upgrade baselines for virtual appliances (VAs) and for other VM-related items, as you will see shortly.

Finally, baselines are divided once again into dynamic baselines or fixed baselines. Dynamic baselines can change over time ("all the patches released since January 1, 2009, for Windows XP Professional"), but fixed baselines remain constant ("include .NET Framework 3.5 Service Pack 1").

VMware provides a few baselines with VUM when it's installed. The baselines that are present upon installation include the following:

• Two host patch baselines named Critical Host Patches and Non-Critical Host Patches

• Two VM patch baselines named Critical VM Patches and Non-Critical VM Patches

• Four VM/VA upgrade baselines named VMware Tools Upgrade to Match Host, VM Hardware upgrade to Match

Host, VA Upgrade to Latest, and VA Upgrade to Latest Critical

Although these baselines provide a good starting point, many users will need to create additional baselines that better reflect their organizations' specific patching policy or procedures. For example, organizations may want to ensure that ESX/ESXi hosts are kept fully patched with regard to security patches, but not necessarily critical non-security patches. This can be accomplished by creating a custom dynamic baseline.

You can now use this baseline to determine which ESX/ESXi hosts are not compliant with the latest security patches by attaching it to one or more hosts.

Groups, or baseline groups, are simply combinations of non conflicting baselines. You might use a baseline group to combine multiple dynamic patch baselines, like the baseline group. By attaching a baseline group to your ESX/ESXi hosts, you would be able to ensure that your hosts had all available patches installed. For example, there might be a specific fix for your ESX/ESXi hosts, and you want to ensure that all your hosts have all the critical patches-easily handled by the built-in Critical Host Patches dynamic baseline-as well as the specific fix. To do this, create a fixed baseline for the specific patch you want included, and then combine it in a baseline group with the built-in Critical Host Patches dynamic baseline.

Configuration

The bulk of the configuration of VUM is performed on the Configuration tab. From here, users can configure the full range of VUM settings, including network connectivity, patch download settings, patch download schedule, virtual machine settings, ESX/ESXi host settings, and vApp settings. These are some of the various options that you can configure: Network Connectivity Under Network Connectivity, you can change the ports on which VUM communicates. In general, there is no need to change these ports, and you should leave them at the defaults.

Patch Download Settings

The Patch Download Settings area allows you to configure what types of patches VUM will download and store. If you want to use VUM primarily as a mechanism for patching ESX/ESXi hosts but not virtual machines, you can save bandwidth and disk storage by deselecting the patch sources for virtual machines. You can also add custom URLs to download third-party patches. The Patch Download Settings area is also where you would set the proxy configuration, if a proxy server is present on your network. VUM needs access to the Internet in order to download the patches and patch metadata, so if a proxy server controls Internet access, you must configure the proxy settings here in order for VUM to work.

Note that VUM does support a distributed model in which a single patch repository downloads patches, and multiple VUM servers all access the shared repository. Setting

VUM to use a centralized download server is done with the Use A Shared Repository radio button.

Patch Download Schedule

The Patch Download Schedule area allows you to control the timing and frequency of patch downloads. Click the Edit Patch Downloads link in the upper-right corner of this area to open the Schedule Update Download Wizard, which allows you to specify the schedule for patch downloads as well as gives you the opportunity to configure email notifications.

Virtual Machine Settings

Under Virtual Machine Settings, vSphere administrators configure whether to use virtual machine snapshots when applying patches to virtual machines.

Snapshots provide the ability to capture a virtual machine's state at a given point in time and then roll back to that captured state if so desired. Having the ability, via a snapshot, to undo the installation of a series of patches is incredibly valuable. How many times have you run into the situation where applying a patch broke something else? By allowing VUM to integrate snapshots into the patching process, you are providing yourself with a built-in way to undo the patching operation and get back to a known good state.

ESX Host Settings

The ESX Host Settings area provides controls for fine-tuning how VUM handles maintenance mode operations. Before an ESX/ESXi host is patched or upgraded, it is first placed into maintenance mode. When the ESX/ESXi host is part of a cluster that has VMware Distributed Resource Scheduler (DRS) enabled, this will also trigger automatic VMotions of virtual machines to other hosts in the cluster. These settings allow you to control what happens if a host fails to go into maintenance mode and how many times VUM retries the maintenance mode operation. The default settings specify that VUM will retry three times to place a host in maintenance mode.

vApp Settings

The vApp Settings allow you to control whether VUM's "smart reboot" feature is enabled for vApps. vApps are teams, if you will, of virtual machines. Consider a multitier application that consists of a front-end web server, a middleware server, and a back-end database server. These three different virtual machines and their respective guest operating systems could be combined into a vApp. The smart reboot feature simply restarts the different virtual machines within the vApp in a way that accommodates inter-VM dependencies. For example, if the database server has to be patched and rebooted, then it is quite likely that the web server and the middleware server will also need to be rebooted, and they shouldn't be restarted until after the database server is back up and available again. The default setting is to leverage smart reboot.

Events

The Events tab lists the events logged by VUM. The Events tab lists actions taken by administrators as well as automatic actions taken by VUM. Administrators can sort the list of events by clicking the column headers, but there is no functionality to help users filter out only the events they want to see. There is also no way to export events from here.

Patching Hosts and Guests

VUM uses the term remediation to refer to the process of applying patches to an ESX/ESXi host or guest operating system instance. As described in the previous section, VUM uses baselines to create lists of patches based on certain criteria. By attaching a baseline to a host or guest operating system and performing a scan, VUM can determine whether that host or guest operating system is compliant or noncompliant with the baseline. Compliant with the baseline means that the host or guest operating system has all the patches included in the baseline currently installed and is up-to-date; noncompliant means that one or more patches are missing and the target is not up-to-date.

After compliance with one or more baselines or baseline groups has been determined, the vSphere administrator can remediate-or patch-the hosts or guest operating system. Optionally, the administrator also has the option of staging patches to ESX/ESXi hosts before remediation. Attaching-or detaching-baselines is the first step, then, to patching ESX/ESXi hosts or guest operating systems. Let's start by taking a closer look at how to attach and detach baselines.

Attaching and Detaching Baselines

Before you patch a host or guest, you must determine whether a host or guest operating system is compliant or noncompliant with one or more baselines or baseline groups.

Defining a baseline or baseline group alone is not enough. To determine compliance, the baseline or baseline group must be attached to a host or guest operating system. After it is attached, the baseline or baseline group becomes the "measuring stick" that VUM uses to determine compliance with the list of patches included in the attached baselines or baseline groups.

Attaching and detaching baselines is performed in one of vCenter Server's Inventory views. To attach or detach a baseline or baseline groups for ESX/ESXi hosts, you need to be in the Hosts And Clusters view; for guest operating systems, you need to be in the VMs And Templates view. In both cases, you'll use the Update Manager tab to attach or detach baselines or baseline groups.

In both views, baselines and baseline groups can be attached to a variety of objects. In the Hosts And Clusters view, baselines and baseline groups can be attached to datacenters, clusters, or individual ESX/ESXi hosts. In VMs And Templates view, baselines and baseline groups can be attached to datacenters, folders, or specific virtual machines. Because of the hierarchical nature of the vCenter Server inventory, a baseline attached at a higher level will automatically apply to eligible child objects as well. You may also find yourself applying different baselines or baseline groups at different levels of the hierarchy; for example, there may be a specific baseline that applies to all hosts in the environment but another baseline that applies only to a specific subset of hosts.

Performing a Scan

The next step after attaching a baseline is to perform a scan. The purpose of a scan is to determine the compliance-or noncompliance-of an object with the baseline. If the object being scanned matches what's defined in the baseline, then the object-be it an ESX/ESXi host or guest operating system instance-is compliant. If there's something missing from the host or guest as, then it's noncompliant. You may perform scans on ESX/ESXi hosts, online virtual machines with a guest operating system installed, offline virtual machines with a guest operating system installed, and some powered-on virtual appliances.

Staging Patches

If the target of remediation-that is, the object within vCenter Server that you are trying to remediate and make compliant with a baseline-is an ESX/ESXi host, an additional option exists. VUM offers the option of staging patches to ESX/ESXi hosts. Staging a patch to an ESX/ESXi host copies the files across to the host to speed up the actual time of remediation. Staging is not a required step; you can update hosts without staging the updates first, if you prefer.