Home > VCAP, Virtualisation, VMware > VCAP-DCA Study notes–5.2 Complex Update Manager environments

VCAP-DCA Study notes–5.2 Complex Update Manager environments

February 15th, 2011 Leave a comment Go to comments
Print Friendly

Most people have used Update Manager to some degree so this objective is probably one of the easier ones to cover. The VUM Administration Guide covers pretty much everything on the VCAP-DCA blueprint and should be your first stop for study (apart from this blog obviously!).

Not listed in the blueprint (at least in this section) is the PowerCLI cmdlets for using Update Manager. Section 8 only lists ‘Installing the Update Manager PowerCLI cmdlets’ but if you have time it’s probably worth giving them a spin.

Knowledge

  • Identify firewall access rules for Update Manager

Skills and Abilities

  • Determine use case for, install and configure Update Manager Download Service
  • Configure a shared repository
  • Configure smart rebooting
  • Manually download updates to a repository
  • Perform orchestrated vSphere upgrades
  • Create and modify baseline groups
  • Troubleshoot Update Manager problem areas and issues
  • Generate database reports using MS Excel or MS SQL
  • Upgrade vApps using Update Manager

Tools & learning resources

Update Manager basics (VCP revision)

The exam topics assume a certain amount of knowledge as Update Manager is on the VCP syllabus. A quick recap;

  • Installs as a plugin to vCentre
  • Downloaded as part of the vCentre package
  • Once the server component is installed you have to add the plugin to any VI client installations you use.
  • Distinguishes between ‘patches and security updates’ vs ‘product upgrades’.NOTE: With the recent release of vSphere v4.1 U1 it’s clear that the distinction between a ‘patch’ and an ‘upgrade’ is rather hazy. Upgrading a host from v4.0 to v4.1 requires a ‘host upgrade’ baseline whereas upgrading a host from v4.1 to v4.1 U1 requires a ‘patch’ baseline.  You can read more in this article at Jason Boche’s website.
  • Patching guest OSs requires an agent to be installed to the guest. This is done automatically the first time a guest is scanned for patch compliance or can be done manually if required.
  • Patches are downloaded accordingly to a defined schedule (default once a day)

Typical lifecycle;

  1. Download patches (from centralised repository or Internet)
  2. Create baselines
  3. Scan hosts (and/or guest OS)
  4. View compliance reports
  5. Remediate (apply patches)

Can patch;

  • ESX/ESXi hosts
  • Virtual hardware
  • VMware Tools
  • Virtual appliances
  • Guest OSs (Windows and Linux)
  • Third party components such as the Cisco Nexus 1000v distributed switch, Xsigo HCA drivers, and EMCs PowerPath.
New features in v4.1
  • When installing for vSphere v4.1 you’ll have to create a 32bit DSN (vCentre 4.1 requires a 64bit OS but VUM is a 32bit app). See VMware KB1010401 for details of how to do this.
  • Patch recalls, actionable alerts, and new fixes are checked (and notified) via another defined schedule (default once an hour)
  • Now supports host upgrades (as opposed to updates). Add upgrade binaries to VUM;

image

Misc
  • Be careful when patching a host containing your virtual vCenter server. Prior to vSphere 4.1 this could cause remediation to fail. Still requires DRS enabled for automatic remediation.
  • VMs need to be powered on to report VMtools status correctly.
  • Quite a few VMs may show as ‘incompatible’. This can happen when no VMtools are installed or not managed via vSphere (appliances, virtual ESX hosts with no VMtools packages etc)

Firewall access rules for VUM

  • Firewall ports: 8084 (SOAP), 9084 (patch repository)
  • See the VUM Administration Guide (p.68) or VMwareKB1004543 (which differs slightly from the admin guide)

Managing the patch repository

Four ways to populate VUM with patches;

  1. Directly from VMware/Shavlik via the Internet (default)
  2. Third party patch repositories (Cisco for example)
  3. Via a manual patch download (offline bundle)
  4. From a shared (Update Manager Download Service (UMDS)) repository

NOTE: Some drivers are provided as an offline bundle which can be deployed with VUM, but some need to be manually added to an ESX host using esxupdate or (PowerCLI). See this post about Broadcom drivers at Julian Wood’s site for a good example.

Using third party patch repositories

Add a third party URL using the ‘Add Patch Source’ button on the VUM Configuration tab (see screenshot). See Chad Sakacc’s YouTube video of using VUM to install EMC PowerPath/VE.

Using offline bundles

An offline bundle (in .ZIP format) can be downloaded from VMware (typically linked to a VMware KB article) and imported manually. Use the ‘Import Patches’ button on the VUM Configuration tab (see screenshot);

image

Shared Repository (UMDS)

Sometimes the VUM server doesn’t have Internet access (due to security restrictions, infrastructure limitations etc). Two deployment models for Update Manager;

· Air gap model (Update Manager is isolated from other networks)

· Semi air gap model – Update Manager doesn’t have internet connectivity but is connected to a server which does.

The Update Manager Download Service (UMDS) can address both these situations.

Installation

  • Like VUM, install a database before running install. Requires a 32bit DSN if on 64 bit server. For lab installs you can use the bundles SQL Express 2005 (no prior db creation required).
  • Installed on a separate Windows server to VUM. Can be x32 or x64 Windows OS.
  • Install from vCenter install DVD, /umds directory. Run VMWARE-UMDS.EXE (not the .msi)
  • Configured via the command line (no GUI). Default install path is C:\Program Files\VMware\Infrastructure\VMware Update Manager\vmware-umds.exe.

Post installation steps

1. Configure patches to download;

# long syntax
vmware-umds –-set-config –-enable-host 1 –-enable-win 0 –-enable-lin 0

#abbreviated syntax
vmware-umds -s -h 1 -w 0 -l 0
  • NOTE: Unlike VUM, UMDS actually downloads all the chosen patches immediately rather than waiting for a remediation action. Mine downloaded 10Gb of patches (host patches only).NOTE: You can’t specify via the command line the version of ESX that you want patches for (3.x, 4.x, ESX/ESXi etc) so the patch repository may be significantly larger than the VUM equivalent. Downloading all these patches can also take significant time depending on your internet connection. You can exclude VI3 patches by following VMware KB1015663.

2. Download patches

# long syntax
vmware-umds –-download
# abbreviated syntax
vmware-umds –D
  • NOTE: Quite a few of the patches didn’t download first time for me. VMware KB1026154 describes how to use an undocumented switch to increase timeouts. Run this regularly (as a scheduled Windows job) to ensure patches are up to date

3. Export patches. I couldn’t get this step to work so I’m not sure why you can’t just put the downloaded patches on a webserver. Still, it’s what the guide says to do…

vmware-umds –-export –-export-store <directory/URL>
  • NOTE:Can be exported to a directory (C:\UMDSData) or a webserver (http://server/folder). VMware KB1019288 gives details for configuring Apache or IIS to work as a remote source Of VUM patches (or use the Admin Guide p158-160).

Optional configuration

Change patch download location;

vmware-umds.exe –-set-config –-patch-store <directory path>
    See chapter ten of the VUM Admin guide for full details of installing and configuring UMDS.

Orchestrated upgrades and baseline groups

An orchestrated upgrade is simply a baseline group which contains multiple upgrade baselines. VUM is smart enough to apply them in the correct order and reboot accordingly;

  • Upgrade VMTools to match host
  • Upgrade virtual h/w to match hostNOTE: You can’t use an Orchestrated upgrade on VMs where VMtools isn’t installed or is managed by a third party (virtual appliances, virtual ESX hosts etc).

vApps (upgrading and smart reboot)

Smart rebooting is simply the ability for vCentre to restart vApps in a defined order, typically used when one server has a dependency on another (webserver and db server for example);

  • Restarting individual VMs based on the vApp priority settings
  • Configured via VUM Admin view, Configuration, vApp Settings
  • ON by default

Reporting using VUM

There is no built in reporting so you’ll have to use either SQL queries or Excel to produce reports. I could follow the example in the admin guide but it didn’t produce an overly meaningful report – I suspect you need reasonable SQL skills to do this any justice in the real world;

  • Create an ODBC DSN (pointing to the VUM database) on the machine with Excel installed (any version)
  • In Excel go to Import -> External Data source (pre 2010) or Data tab, select ‘From Other Sources’ and then either ‘From SQL server’ or ‘from Microsoft Query’ (Excel 2010).
  • image

Troubleshooting

Chapter 18 of the Update Manager Administration Guide lists a variety of troubleshooting steps you can take. General troubleshooting steps;

  • Check the VMware Update Manager service is started (restart if necessary)
  • Re-enable the plugin via the VI client. Sometimes you have to disable and reenable.
  • Generate VUM log bundles from the host running VUM;

image

*