Solution provider's takeaway: Avoid the trouble involved with manually patching hosts and virtual machines (VMs)...
for your customers by taking advantage of vCenter Update Manager. Check out the steps to follow when undergoing Update Manager installation and configuration.
When it comes to patching and updating ESX and ESXi hosts and VMs, solution providers have several options. Remote and local command line utilities are used to update hosts and VMs, and standalone applications, such as the vSphere Host Update Utility and vCenter Update Manager, are also helpful.
While command line utilities are just as effective as standalone applications, many customers prefer to use application clients for hosting and patching. Using command line utilities can be tedious, and solution providers must know proper syntaxes to use them properly. On the other hand, application clients are easier to use and have more features, such as the ability to schedule when updates are applied.
The vSphere Host Update Utility is bundled with the vSphere Client that is used to patch ESXi hosts. Solution providers can also use the utility with vSphere to upgrade ESX 3.x hosts to ESX 4.x hosts. However, with the recently released vSphere 4.1, the Host Update Utility is no longer bundled with the vSphere Client. This leaves vCenter Update Manager as the only application client available to patch your customer's vSphere environment.
VCenter Update Manager is not a separate product and requires that you have a licensed vCenter Server. It is a plug-in for vCenter Server, adds additional patching capabilities to vSphere and is included in all vSphere editions. Solution providers can use vCenter Update Manager for VMs running Windows or Linux operating systems (OSes).
By using a baseline and then installing patches and updates on hosts and VMs that need them, vCenter Update Manager is also able to automate patching for solution providers and functions. It can scan and remediate VMs and templates in any power state (on, off or suspended) and can do the same for any host that is powered on. Snapshots are taken of VMs prior to upgrading so those machines can be reverted back in case there is a problem with the applied patches.
Solution providers can run vCenter Update Manager on Windows workstations, and the Update Manager consists of several components, including the plug-in component to the vSphere Client, a Windows service that can run on the vCenter Server and a database that stores patch metadata and other information.
vCenter Update Manager requirements and installation
The requirements for vCenter Update Manager are fairly simple: a dual core CPU with a minimum of 2.0 GHz, 2 GB of RAM if running on a standalone server, 4 GB if running on the vCenter Server, 10/100 network connection (gigabit preferred) and a SQL or Oracle database. The database used by Update Manager (either SQL or Oracle) is different from the one used by vCenter Server, and you can use any formats that are also supported by vCenter Server. You can also use the SQL Server 2005 Express edition, which can be installed with Update Manager, but VMware recommends using one of the other databases for larger production environments.
To install vCenter Update Manager, you have to first install the Update Manager's Windows service component. By default, the service component is not installed with vCenter Server and must be installed either on the vCenter Server or on a separate server. If vCenter Server does not have enough resources, it is recommended to install the service component on a separate server. The installation media for Update Manager is on the vCenter Server install media. If you execute autorun, you will see a menu where you can choose to install vCenter Update Manager (Figure 1).
Figure 1: Solution providers can install vCenter Update Manager through the VMware vCenter Installer screen.
After running the Update Manager installer, a screen will appear asking which vCenter Server to connect to. Enter the IP address and the login information for a valid admin user on the local or remote vCenter Server. Next, you will be prompted to either create a new database using SQL Server 2005 Express or an existing database.
If your customer has a large environment, using SQL Server 2005 Express is not recommended. For smaller environments (up to 5 hosts and 50 VMs) where vCenter Server uses SQL Server 2005 Express, you can use that existing instance when installing Update Manager on the vCenter Server. Solution providers that use the existing vCenter Server database can select the existing Open Database Connectivity (ODBC) connection, otherwise they will have to create a new ODBC connection to which ever database is in use.
Next, you will have to choose which port to use for Update Manager; normally, the defaults are fine and you don't want to change them. The SOAP port (8084) is used for Update Manager client (plug-in) to server communication. The Web port (9084) is the listening port for the Update Manager server and provides host access to the patch depot, and the SSL port (9087) is the encrypted port that can be used if needed.
These ports will not conflict with vCenter Server ports if you install them at the same time.
Finally, you will be prompted for a location to install the Update Manager application along with a separate location to use for patching and updating storage. Accumulated patches and updates can take up quite a bit of room, so ensure there is a minimum of 20 GB of free disk space available. Once the product is installed, you will see two new items in the list of VMware Update Manager services (Figure 2). One is the main application service and the other is a supplemental service used for mounting the disks of powered off VMs so they can be patched.
Figure 2: The Update Manager Windows services will appear after you install Update Manager.
Now that the server component is installed, it's time to install the client component. To do this, use the vSphere Client and connect to the vCenter Server for which you configured the Windows service component. Once you are connected to vCenter Server, select Plug-ins from the top menu, then click Manage Plug-ins.
In the list under Available Plug-ins, you will see the vCenter Update Manager plug-in. Click the Download and Install link to begin installing the plug-in into the vSphere Client. Note that this is specific to the vSphere Client instance that you are currently using and you will need to repeat this process on any other workstations that have the vSphere Client.
The client setup wizard will load and detect the path to the vSphere client installation, and by clicking Install, the installation will begin. Once it finishes, close the Plug-in Manager window, click the Home button and a new section will appear on the homepage called Solutions and Applications, which is where plug-ins are displayed. The Update Manager link will be displayed there (Figure 3).
Figure 3: The Update Manager icon will display in the vSphere Client once you install the plug-in.
After you launch Update Manager, several tabs across the top of the vSphere Client will perform the following functions:
- Getting Started – Displays useful help information and links.
- Baselines & Groups – Baselines are created for hosts, VMs and virtual appliances. Baseline groups are made from existing baselines and can contain one upgrade baseline per type and one or more patch baselines, or a combination of multiple patch baselines.
- Configuration – Allows you to set options for VM and host settings, adjust how frequently updates are downloaded and change Internet connection and port settings.
- Events –Shows you all the events that have taken place that are associated with Update Manager.
- Notifications –Contacts VMware to download information (notifications) about patch recalls, new fixes and alerts. These can be informational or actionable alerts. (New to vSphere 4.1.)
- Patch Repository – Lists all available patch metadata including VMware hosts and VM guest OSes. Solution providers can filter this list to display only the patch information they want to see.
- Host Upgrade Releases – New to vSphere 4.1, this is where you upload host upgrade files (.iso and .zip). These are uploaded when baselines are created.
There are a few steps involved with setting up Update Manager initially to patch hosts. The first step is to download patches; the settings and schedule for this are located on the Configuration tab. Next, you must create baselines, which are either upgraded baselines for newer vSphere versions or patch baselines that contain a collection of one or more patches, service packs and bug fixes. Once you have configured baselines, scan hosts and VMs to evaluate them against baselines and baseline groups to determine their level of compliance.
Missing patches are not considered in compliance with the baseline, so the final step is to remediate them. Remediation installs the missing patches and upgrades to your hosts and VMs. For ESXi hosts, updates are all-inclusive because ESXi consists of a single image file. Therefore, the most recent update contains the patches from all previous releases.
For ESX hosts, if a patch is dependent on another patch, Update Manager will install it with the required patch. Patches that conflict with each other are automatically not installed, or they are uninstalled if another patch supersedes the conflicting patch.
In the example below, we will upgrade an ESX host from version 4.0 to version 4.1. This is considered an upgrade, not a patch, and you need to download the 4.0 to 4.1 upgrade .zip file from the VMware website (Figure 4). The .zip file bundles are typically used for minor point release upgrades. If you were upgrading from ESX 3.x to ESX 4.x, you would instead download the complete ISO file.
Figure 4: The ESX 4.1 upgrade .zip file is on VMware's vSphere download website.
Now that you have the upgrade file, select the Host Upgrade Releases tab and click the Import Upgrade Release link. This will launch a wizard that allows you to select the upgrade file you downloaded (Figure 5). You can select multiple upgrade files to create a bundle, which allows for multiple upgrade options. For example, you could select the 4.0 to 4.1 .zip file as well as the ESX 4.1 ISO file so you could upgrade ESX 3.x and 4.0 hosts to 4.1 (Figure 6). You can select ESXi upgrade files as well to make a complete upgrade bundle to version 4.1.
Figure 5: Select and add upgrade files to create an upgrade bundle.
Once you select your files, click Next to begin the upload. The files will be moved to the Update Manager server.
Figure 6: Selected upgrade files are uploaded to the Upgrade Manager server.
Once the files are uploaded, your bundle will be displayed and the types of hosts that can be upgraded with it will be checked (Figure 7).
Figure 7: A partial upgrade bundle is shown that contains files that upgrade ESX 3.x or ESX 4.0.x hosts to version 4.1.
As shown in Figure 7, only ESX 4.0 and ESX 3.x hosts can be upgraded to 4.1 because we only uploaded those files. To change our bundle from partial to full, we would have to add the files to upgrade ESXi 3.x and ESX 4.0 hosts as well.
Now that we have the files uploaded, we need to create a baseline for version 4.1, which we can attach to our host to have it upgraded from 4.0 to 4.1.
On the baseline tab, click the Create link under Baselines and a wizard will launch. On the New Baseline page (Figure 8), give your baseline a name and choose the Host Upgrade type.
Figure 8: Create a new Host Upgrade baseline type to upgrade hosts to vSphere 4.1.
Next, select the Host Upgrade Release bundle that you created (Figure 9).
Figure 9: Select a Host Upgrade Release that contains the necessary upgrade files to upgrade the host to vSphere 4.1.
Then, for ESX hosts only, select a location for the Service Console VM. Solution providers should use the recommended setting that uses a local datastore (Figure 10). Using a shared datastore can cause problems if that datastore becomes unavailable.
Figure 10: For ESX Hosts only, choose a datastore location for the Service Console disk (vmdk) file.
Finally, select the Post-Upgrade Options (Figure 11), which includes rolling back if the upgrade fails and running scripts once the upgrade completes (ESX 3.x to ESX 4.x only).
Figure 11: It's important to set baseline post upgrade options for rolling back if the upgrade fails and running scripts after the upgrade completes.
Once your baseline is complete, attach it to a host that you want to upgrade (Figure 12).
Go back to the Hosts and Clusters view and select a host. You will see a new Update Manager tab displayed. Select that tab and click the Attach link and a window will appear allowing you to choose a baseline or baseline group. Select the baseline that you just created and click the Attach button.
Figure 12: Select an existing baseline to attach to a host.
Now that our baseline is attached, we want to scan the host (Figure 13) to determine if it is in compliance with the baseline. Since the baseline was created for upgrading to ESX 4.1 and our host is currently running ESX 4.0, it will not be compliant.
Figure 13: Select the Upgrades option and click Scan.
Once the scan completes, it will show that our host is not in compliance with the baseline that we attached to it. To bring the host into compliance, we need to remediate it, which will upgrade it using the upgrade files that are assigned to the baseline.
Doing a remediation will put the host into Maintenance Mode, which evacuates all the virtual machines to other hosts using VMotion. Any VMs that cannot be moved will be powered down. To reduce the amount of time that the host is down, stage the update files to the host first, which is normally done as part of the remediation. When you stage the update files, it downloads the upgrade files to the host before it goes into Maintenance Mode. When you're ready to remediate the host and begin the upgrade, click the Remediate button (Figure 14).
Figure 14: Here's the Upgrade Manager showing host baseline compliance status.
After the remediation wizard is launched, select your baseline and click Next (Figure 15).
Figure 15: Remediate a host by choosing a baseline to upgrade it with.
Next, accept the licensing agreement, and at the ESX 4.x upgrade screen, select options that only apply if you are upgrading from ESX 3.x to ESX 4.x. The Host Remediation Options screen (Figure 16) allows you to schedule the upgrade or run it immediately. Solution providers can also specify maintenance mode options, such as VM behavior and retry options.
Figure 16: Host remediation options include scheduling and options for maintenance mode.
At the Cluster Remediation Options screen (Figure 17), you can disable cluster features, such as Distributed Power Manager, high availability and fault tolerance, while the upgrade is being performed.
Typically you would disable these features while the host is being upgraded if you do not have enough spare capacity on other hosts for those features to work effectively.
Figure 17: Use this screen for setting cluster remediation options that disable Distributed Power Management, fault tolerance and high-availability features while remediation occurs.
Once the remediation begins, tasks appear in vCenter Server as it prepares the host for upgrade, performs the upgrade and then brings the host back online (Figure 18).
Figure 18: Tasks created in the vSphere Client relate to the remediation process.
After remediation completes, the host will show as compliant on the Update Manager tab as it is now running ESX 4.1, which was defined in the baseline (Figure 19).
Figure 19: Update Manager screen shows that the host is compliant with its baseline.
Update Manager makes patching hosts and VMs a much easier process through automation and an easy-to-use interface. For VMs, you can also patch Windows and Linux OSes, as well as upgrade VM hardware and VMware Tools.
There is more to Update Manager then I have covered in this tip. For more information on using Update Manager, read through the Update Manager Administration Guide that is available on VMware's website.
About the expert
Eric Siebert is a 25-year IT veteran whose primary focus is VMware virtualization and Windows Server administration. He is one of the 300 vExperts named by VMware Inc. for 2009. He is the author of the book VI3 Implementation and Administration and a frequent TechTarget contributor. In addition, he maintains vSphere-land.com, a VMware information site.