Prior to running the installation program for VUM, it is necessary to set up a database that will be used by VUM and an Open Database Connectivity (ODBC) data source name (DSN) that VUM will use to connect to the database. If you have a smaller deployment of up to 5 hosts and 50 virtual machines, you can use Microsoft SQL Server Express, which can be installed and configured when you run the installation for VUM. Otherwise, you must create a database with Microsoft SQL Server or Oracle. You can use the following process to create the DSN and database for Microsoft SQL Server:

After you have created the ODBC connection and the database, you should review the database settings for the connection and also ensure that the database is properly maintained. This maintenance should include regular backups and ensure that indexes are regularly rebuilt to optimize database performance. You can then follow this process to install the VUM server component:

To access VUM functionality within the vSphere client, you must enable the VUM client plug-in. This is required on any workstation that will be used to manage VUM. After VUM has been installed, you can use the following procedure to enable the plug-in:

Several configuration options require review before you can begin to use VUM. From the Home page of the vSphere client, select the Update Manager icon to access the VUM screens. Select the Configuration tab to see areas of configuration, as shown in Figure 10.4. The screen displays the ports and hostname used for VUM communication. If any changes are made on this screen, it is necessary to restart the Windows service VMware vCenter Update Manager Service.

Figure 10.4. VMware vCenter Update Manager Configuration options.

If you plan to use VUM just to update your ESXi host, it is worthwhile to edit the Patch Download Sources on the Patch Download Settings screen. By default, VUM downloads patches for ESX(i) 4.x, ESX(i) 3.x, Linux, and Windows, as shown in Figure 10.5. You will also notice a Custom patch type with a download URL of https://hostupdate.vmware.com/software/VUM/PRODUCTION/csco-main-index.xml. This patch download source allows for the downloading of patches for the Cisco Nexus 1000V virtual switch. To conserve space and bandwidth only, the VMware patch type for ESX 4x patches should be left enabled. Click Apply to save your configuration change.

Figure 10.5. Changing patch download settings for VMware vCenter Update Manager.

On the Patch Download Settings screen, you can also add your own third-party patch source and configure or update proxy settings that the VUM service will use to connect to the Internet. On this screen, you can also manually import patches. If you have downloaded an ESXi patch, as was done in the section “Patching ESXi with the vCLI Command vihostupdate,” you can click the Import Patches link and a wizard will guide you through the process of importing the patch into the VUM patch repository. You can also set the VUM service to use a shared repository to obtain patch files should the VUM host not have Internet connectivity. The shared repository is populated by the Update Manager Download Service, which can be installed on a host with Internet access if your security requirements prohibit the VUM host from having direct Internet connectivity. The repository can be a local directory or HTTP URL.

On the Patch Download Schedule screen, you can set a schedule for downloading software patch definitions. When setting the schedule, you can also include a notification e-mail address that is notified when VUM downloads new updates. The notification process is dependent on the e-mail notification setup in vCenter Server that was discussed in Chapter 6, “System Monitoring and Management.” On the Notification Check Schedule screen, you can schedule a job that checks for new patches as well as enables e-mail notification for when new patches are available.

The vApp Settings and Virtual Machines Settings screen relates solely to options for virtual machines and vApps. On the vApp Settings screen, you can check the option Enable Smart Reboot after Remediation. This option will ensure that the virtual machines that are part of a vApp are rebooted in such an order as to maintain startup dependencies. On the Virtual Machines Settings screen, you can control how snapshots are maintained for virtual machines that are going to be patched. The default settings are to take a snapshot of the virtual machine before patches are applied and not to delete the snapshots taken. You can choose not to take snapshots before patches are applied and also set the length of time that snapshots are kept after patches are installed.

The final configuration screen is ESX Host/Cluster Settings. Before a host can be patched, it must be placed in maintenance mode. If the host cannot be placed into maintenance mode, the default settings shown in Figure 10.6 specify that the operation will be retried another three times with a 30-minute delay between attempts. You can change the Failure Response setting to the following:

Figure 10.6. Configuring host and cluster settings for VMware vCenter Update Manager.

You may also want to check the option Temporarily Disable Any Removable Media Devices That Might Prevent a Host from Entering Maintenance Mode. If your host is part of a vMotion-capable cluster, a virtual machine may not be able to migrate if it is configured with a virtual floppy or CD-ROM device that is not available on the destination host. If you check this option, those devices will be disabled, which will allow the virtual machine to be migrated to another host.

To allow a host to enter maintenance mode, it may also be necessary to disable certain features of the cluster. For example, in a High Availability (HA) cluster, the Admission Control policy may not allow a host to be placed in maintenance mode, as there would then be insufficient failover capacity in the cluster. Thus it is necessary to disable Admission Control temporarily while the host is being remediated. After the patch process is complete, Admission Control can then again be enabled. The following cluster options can be disabled to allow hosts to enter maintenance mode successfully:

VUM uses baselines to keep hosts and virtual machines up-to-date with patches, updates, and extensions. A baseline is a collection of one or more patches, service packs, extensions, or upgrades. You can create either a host baseline or one for virtual machines and appliances. Host baselines can be one of three types: patch, upgrade, or extension. When you create baselines, you can also specify whether the baseline will be fixed or dynamic. A fixed baseline for patching an ESXi host would include a specific patch or patches and would not change over time. A dynamic baseline would include patches based on a defined criteria and change over time. As you typically want to run the latest patches on your ESXi hosts, creating a dynamic baseline is the best option for your hosts.

VUM comes with a number of predefined fixed and dynamic baselines for both host and virtual machines. For hosts, this includes the baselines Critical Host Patches and Non-Critical Host Patches. As you begin to use VUM, you may find that it is necessary to create some additional baselines, as the defaults may not meet your needs. To create a new baseline that includes only ESXi patches, use the following process:

After you have created a baseline, you will be able to attach the baseline to various vCenter objects to determine which hosts are noncompliant and require patching. You will also have noticed the Baseline Groups section on the Baselines and Groups tab. Groups can be used to create a set of nonconflicting baselines. The group can then be assigned to vCenter objects to allow you to scan and remediate multiple baselines at the same time. If you create a group with both the default baselines of Critical Host Patches and Non-Critical Host Patches when that baseline group is applied on an ESXi host, it will ensure that all patches are installed to that host.

To attach a baseline to a vCenter object, you use the Update Manager tab for that object. You can attach a baseline to a specific host, but it is more efficient to attach the baseline at the cluster, datacenter, or vCenter Server levels. If you are using vCenter Server in vCenter Server Linked Mode, you will attach baselines and baseline groups to the vCenter Server with which VUM is registered. Baselines and groups are specific to the VUM instance that is registered with a specific vCenter Server. Use the following process to attach the baseline that you created at the vCenter Server level:

After a baseline has been attached to your hosts, the next step is to scan the hosts for compliance. You can initiate this scan manually or schedule it to run at a more convenient time. After the scan has been completed, you can determine which hosts will need to be patched. As an optional step, you can stage patches to your ESXi host. This essentially copies the patches to the host and does not require the host to be in maintenance mode to copy the patches locally. Once the host is being patched, the process will complete more quickly, as the patches are already stored locally on the ESXi host. Remediation is the final step in patching your ESXi hosts. Again, this step can be manually started or scheduled to occur at an appropriate time.

To scan your hosts manually, you can follow these steps:

You can also right-click on the vCenter object and select Scan for Updates. If you have attached a baseline on the Update Manager tab of a parent object, any child objects to which the baseline will apply also show the baseline on the Update Manager tab as well as the status for any child objects. After the scan is complete, the Update Manager tab displays the compliance status for the hosts that you have scanned, as shown in Figure 10.9. Two of the three hosts listed are shown as being compliant. In the case of one of the hosts, it was already up-to-date with patches. The second compliant host was running ESX 4.0 and thus none of the patches in the baseline was applicable. If you are running a mixed environment of ESXi and ESX hosts, you should carefully set up your baselines so that you do not create such a false positive.

Figure 10.9. Reviewing patch compliance on the Update Manager tab.

You can also easily schedule a periodic scan to ensure that all hosts are up-to-date. Use the following process:

After your scans have been completed and you have identified the hosts that require patching, you can choose to stage the patches to the host before remediation happens. The process of staging the patches to the host essentially copies the patches to the host in advance so you can minimize the patch time later on. The host does not have to be in maintenance mode to have patches staged to it. To stage patches to a host, you can follow these steps:

Several staging tasks are initiated for each host that the process will affect. After the patches have been copied to the ESXi hosts, the tasks should display a Completed status, as shown in Figure 10.11. The patches are uploaded to /tmp/updatecache on the hosts. If you examine the file location on your host after the staging is complete, you will find that only the most recent patches for the host have been staged. As mentioned previously, VUM does not apply any patches for ESXi that have been superseded by a newer version.

Figure 10.11. Staging tasks with a Completed status.

The final step in patching your ESXi hosts is to run the remediation process. You can initiate this process manually on the Update Manager tab or by right-clicking on a vCenter object and selecting Remediate. You can also schedule remediation using a process similar to the one used to schedule scanning for your hosts. To remediate the ESXi hosts that the Update Manager tab displays as being noncompliant, use the following steps:

A number of tasks are generated to begin the installation of patches. Any impacted hosts are placed in maintenance mode. After the patches have been installed and the host rebooted, the remediate task takes the hosts out of maintenance mode. If the patches have been completed successfully, the Update Manager tab should now show the impacted hosts as compliant with the patch baseline that you created.

As mentioned earlier, it is also possible to schedule a remediation task. Select Home > Management > Scheduled Tasks and then click New Task to start the wizard to create a new scheduled task. Select a type of remediation and the wizard that is used will be the same that you used to start the previously described remediation process manually. You should note that unlike the Scan task, which can be scheduled to occur regularly, when you create a remediation task, it can be scheduled to run only once.

The vSphere Host Update Utility

The Host Update Utility was included with the vSphere client installation for versions 3.5 and 4.0. This utility could be used to connect directly to an ESXi 3.5 or 4.0 host and apply patches as shown in Figure 10.13. The tools could also be used to upgrade an ESXi host from version 3.5 to 4.0. This utility is no longer included with the vSphere client. You can use vihostupdate from the vCLI as an alternative for patching standalone ESXi hosts.

Figure 10.13. The vSphere Host Update Utility.

The Install-VMHostPatch cmdlet can be used to install patches that are located on your management server, on a Web server, or on the filesystem accessible to your ESXi hosts. When you use the -LocalPath or -WebPath options, the patch contents are copied to your ESXi host. Your host may not have sufficient free space for the largest ESXi patches, so it is best to upload the patch to a datastore and then use the -HostPath parameter.

In the following example, an ESXi host is updated from version 4.0 Update 1 to Update 2 with the patch copied to a datastore accessible by the host:

If you’re patching a number of hosts, you can easily embed these commands into a single script to patch all your hosts. If you’re not using a DRS cluster, you can use the Move-VM cmdlet to migrate virtual machines between hosts with vMotion.

The vCenter Update Manager PowerCLI provides a number of cmdlets for managing your VUM installation. The VUM PowerCLI is available for download from http://www.vmware.com/go/powercliupdate. Both PowerShell and PowerCLI must be installed before you run the installation. The cmdlets included with vSphere 4.1 are listed in Table 10.1.

In the following example, a new baseline will be created to patch ESXi hosts in a cluster called Cluster01:

Once you execute the remediation task, you will find a number of new tasks in vCenter Server, including reconfiguring the cluster, putting the host in maintenance mode, and patching the host. After the process is complete, the host and cluster are returned to their prior states.

In some cases you may have hosts at remote sites with low bandwidth connections. It may not be desirable to send patches to those hosts during business hours. vCenter Server does not currently include the capability to schedule a stage patch job, but you can schedule Stage-Patch with a third-party tool. The main parameter for Stage-Patch is -Entity and this can be a host, cluster, or datacenter. The cmdlet also accepts the parameters -Baseline which you can use to filter the patch baselines that should be used, and -ExcludePatch to specify which patches to exclude from staging.