VMtoday

Archive for November, 2008

Microsoft released version 2 of their Offline Virtual Machine Servicing Tool (OVMSTv2) yesterday.  The updated version of the tool, a component of Microsoft’s Solution Accelerator family of ‘best-practice-meets-tools’ adds integration with System Center Virtual Machine Manager 2008, and support for System Center Configuration Manager 2007 SP1, System Center Configuration Manager 2007 R2, and Windows Server® Update Services 3.0 SP1.  The tool works in much the same way as VMware’s Update Manager product updates Windows guest VM’s. Support for System Center Virtual Machine Manager 2008 obviously means that this product could supplement, replace or conflict with VMware’s Update Manager’s ability to patch Windows guests hosted on a VMware Virtual Infrastructure.

There is not yet much information on this version of the Offline Virtual Machine Servicing Tool.  A MSDN blog post from May 2008 includes some information on the beta version of the product.  The Getting Started guide included in the OVMSTv2 .zip download reveals a bit more about the requirements and footprint required to implement the solution.  The solution requires a good deal of Microsoft software, including (depending on your environment and requirements) Microsoft Active Directory, Windows Server Update Services (WSUS), Configuration Manager 2007, and Virtual Machine Manager 2007, and an appropriately designed Group Policy (GPO) environment.  Another requirement is that the target VM’s have DHCP assigned IP addresses.

I did not read anywhere in the documentation that the OVMSTv2 integrates snapshot capabilities to provide simple roll-back of guests that suffer problems on Patch Tuesday, as VMware Update Manager does.  I also did not see a reference to network isolation capabilites in OVMSTv2.  VMware Update Manager keeps offline VM’s offline during the patching process.  OVMSTv2 has to reach out to a WSUS or Configuration Manager server, so I suspect that the guest is not isolated during that patching process.

I have not had a chance to build up all of the requirements of this tool in the lab, so I don’t have any practical advise for using the tool.  Have any of you used the beta or release versions of the tool?  Post a comment to let everyone know your experiences.

The Microsoft Offline Virtual Machine Servicing Tool v2 could be a good tool to add to your Microsoft patch management arsenal, but the small footprint and simplicity of VMware Update Manager will most likely keep all but the most dedicated Microsoft shops from implementing OVMSTv2.

I began building up a new lab environment with a few old DL380 G3 servers (courtesy of ebay) and pulled down the latest ISO of ESX 3.5 with Update 3 integrated.  The install went well with my only changes to the defaults being some partitioning changes (I more or less follow the recommendations set forth by Rich at VM/ETC for partitioning) and not checking the option for creating a default network for virtual machines – I prefer to set up all my networking manually once I am in the VI client.  I selected the first on-board NIC for my Service Console connection.  The NIC was detected as a BCM5703, but the server really has the Broadcom NC7781 chipset.  I thought it odd, but continued with the install.  After ESX came up the SC had no network connectivity.  The NIC’s appeared but the drivers and TCP/IP stack could not be initialized against them.  I was able to reproduce the same behavior on two different DL380 G3′s.

A quick Google indicated some issues with the DL380 G3 and ESX (enabling hyperthreading causes performance problems, incorrect ACPI configuration in BIOS can cause system instability, etc.).  The NIC firmware was out of date.  Updated NIC firmware yielded the same problems on a re-install.  I didn’t have much time to troubleshoot the issue as I was trying to stage a demo of NetApp’s SnapManager for Virtual Infrastrucuture, so I reinstalled using an ESX 3.5.0 disk.  The install went fine with no network connectivity issues.  I was able to patch the installation to Update 3 using Update Manager without problems.

I don’t want to shoot from the hip, but I suspect the problems may be related to the updated support for Broadcom NIC’s as described in the ESX Update 3 Release Notes.  I’ll try to troubleshoot this out as time allows and will post an update if I uncover anything of great interest.  Or better yet, maybe I’ll start looking around for some better hardware for the lab.  Leave a comment if you have had a similar issue.