VMware VirtualCenter 2.0.1 Patch 2

Released 28-Feb-2007

This document contains the following information:


This update resolves several issues associated with VirtualCenter’s database server; issues related to VirtualCenter 1.x compatibility mode; and memory consumption and reporting issues. This update also includes changes to several database scripts, and requires some preliminary setup. See Before Installing the Patch for details.

This update also includes a significant improvement to how License Server handles license files: In this release, The License Server configuration (which occurs automatically, during the VirtualCenter Server installation process) has been modified to support a directory as the source of license files, rather than a single file. If you don’t want to upgrade to this release (because you do not have performance issues, for example), you can still benefit from the improved license-handling by updating the License Server only, using the separate installer that accompanies this update.

This update includes changes to VirtualCenter 2.0.1 Server and VI Client software. If you upgrade a VirtualCenter Server host using this update, you must also upgrade all VMware VI Client hosts. You can upgrade the Windows client hosts by downloading the software from an upgraded VirtualCenter Server host, or by selecting Virtual Infrastructure Client from the VirtualCenter installation program. Be sure to upgrade all clients, to obtain performance and other improvements.

Resolved Issues

VirtualCenter 2.0.1 Patch 2 (Build 40644) resolves a variety of issues and includes several improvements:


  • VirtualCenter Database Server Deadlock (And Other Performance Issues) Resolved with New, Improved Statistics-Aggregation (Rollup) Procedures.  The database instances (Microsoft SQL Server, Oracle Database Server) supporting VirtualCenter Server have been subject to deadlocks and other performance issues due in part to VirtualCenter’s statistics-aggregation (rollup) process. With this release, the statistics-data aggregation process (implemented as SQL stored procedures) has been improved: statistics data is initially collected 10 minutes after VirtualCenter startup, and then hourly after that, thus preventing deadlocks from occurring. (In previous releases, an entire week’s worth of statistics data accumulated between the initial and the subsequent roll-up, which sometimes led to deadlocks.)

    Other issues related to statistics collection, such as eliminating duplicate entries in the statistics tables and better managing the Microsoft SQL Server tempdb size, have also been resolved.

    The new, improved statistics-rollup procedures also provide several new optional parameters (rollupLevel, rollupType, sleepOnEntity, sleepOnStatId, and backlogIncluded). Using the parameters, you can modify VirtualCenter’s configuration file (vpxd.cfg) to change the frequency and type of rollup, and to put the rollup process in a sleep mode, for example, to reduce resource utilization. See KB 3034858, “Statistics Rollup Stored Procedures—Optional Parameters ” for information about using the new parameters. Note that by default, the rollup is hourly (rollupLevel=1), and that for best results, setting the rollupLevel above 2 is not recommended in this release.

    Note:  If you are using Oracle Database Server for your VirtualCenter Server deployment, you must perform the “Pre-Upgrade Task for Oracle Database Server” prior to upgrading. If you fail to perform the Pre-Upgrade task, the improved stored procedures will not be installed, and you may run into performance problems in the future. Note that the installer does not notify you of the success or failure of the upgraded procedure installation.

  • VirtualCenter Service Can Be Configured to Re-start Automatically. In previous releases, when the VirtualCenter database server went off-line for any reason, the VirtualCenter service shut down with a normal termination signal, and because the termination signal was deemed normal, the Windows Service Control Manager never attempted to restart the VirtualCenter service. With this release, the service recovery options can be configured to restart the VirtualCenter Server service automatically when this type of event occurs. By default, the service is configured to restart once, but you can modify the VMware VirtualCenter Server service control panel’s Recovery settings to restart after second failure and subsequent failures if you like, as follows:
    1. From the Windows Start menu, select Control Panel>Administrative Tools>Services. The Services control panel opens.
    2. Scroll down to select the VMware VirtualCenter Server control panel and double click on it to open the Properties dialog.
    3. Click on the Recovery tab.
    4. Select Restart the Service from the drop-down menu for Second Failure and Subsequent Failure settings.
    5. Click OK to save.
    6. Close the Control Panel.
  • Custom Attributes Are Maintained in the Database After Upgrading. Prior to this release, Custom Attributes (if any had been defined) were not maintained in the database during an upgrade from VirtualCenter 1.3 (or VirtualCenter 1.4) to VirtualCenter 2.0.1. This issue has been resolved.


  • License Server Configuration Modified to Handle Contents of an Entire Directory (Rather than a Single File). In prior releases, the License Server (which is typically installed automatically, during VirtualCenter Server installation) was configured to obtain license information from a single file. This single-file configuration required any additional product licenses to be added manually to the initial license file.

    This release of VirtualCenter includes a modified installation routine for License Server that automatically changes the configuration of License Server so that it obtains license information from an entire directory (rather than a single file). If you upgrade an existing VirtualCenter Server and License Server using this patch, you will obtain the benefit of this new configuration automatically, and will be able to add new licenses for other VMware products or components to the license-file directory location:

    c:\Program Files\VMware\VMware License Server\Licenses

    KB 7252734, “License Server Directory Support for Simplified License Management” discusses the configuration changes in a bit more detail and provides information about making the changes manually if you have need to do so for any reason.


  • Faster (or Otherwise Improved) Client Performance. This release includes several improvements to the VI Client for performance-related issues. For example, List views display faster. Other client changes include more accurate display of timing progress for VM provisioning, and customized display of user interface objects based on permissions—for instance, if user does not have permission to perform a task, the relevant tool bar actions are disabled, and right-click menu options are dimmed.
  • Memory Leak (when using VC 2.x with VC 1.x compatibility mode enabled) and SDK has been resolved. In some custom applications built using the VI SDK and run against VC 2.x (with VC 1.x compatibility mode), memory consumption would increase until the system crashed. This problem has been resolved in this release.
  • All Performance Data Maintained and Displayed. Under certain conditions, performance data for the most recent 7 days only was displayed. With this release, all performance data displays.
  • VM Memory Usage Displayed in VirtualCenter Does Not Match Host Usage.
  • Memory Usage for VMs Running on ESX 2.5.x Incorrectly Register as 0.
  • Intermittent Time-outs When Deploying VMs (based on Templates Cloned from other VMs) Have Been Resolved. Prior to this release, converting a VM to a template and then using that template to create (clone) a new VM could result in a time-out after 15 minutes. Although the template creation was successful, deploying a new VM from the template failed without notification. This issue, specific to NFS datastores, has been resolved.
  • Deploying Virtual Machine to a Different Cluster (Other than Source) from Template No Longer Loses BIOS Settings. Prior to this release, creating a new VM from a template based on a VM from a different cluster resulted in a VM with re-initialized non-volatile RAM (nvram) BIOS settings, rather than the BIOS settings as configured in the template. This issue has been resolved.


  • VirtualCenter Server No Longer Loses Its Connection to VM During Guest OS Restart. Prior to this release, when running VirtualCenter 2.x (with VC 1.x compatibility mode enabled), attempting to restart a VM’s Guest OS (while connected from IBM Virtualization Manager) resulted in "connection lost" error message. This is no longer the case.
  • VMotion Failures Due to Incorrect CPU Resource Calculations Have Been Resolved. In prior VirtualCenter 2.0.1 releases, CPU reservations were incorrect (they were reported as a much larger MHz value than actually supported by the processor), with the result that VMotion between VMs could not be supported unless the reservation values were manually adjusted. The issue has been resolved.
  • Customized VMs Created from Templates (or by Cloning) on Windows 2000 Server, Windows XP, or Windows 2003 Server Using Static IP Address No Longer Lose Network Settings. In previous releases, if a static IP was selected during the process of customizing a VM on these Windows guest OSs, some network configuration settings (such as default gateway, DNS, and WINS IP addresses) were not maintained. The issue could be avoided by configuring virtual machines to use DHCP for network-address-assignment (rather than static IP addresses) for the VM’s NIC (network interface card) device, or by configuring default gateway and alternate gateways. These workarounds are no longer required: Static IP addresses can be used when customizing VMs on Windows 2000 Server, Windows XP, and Windows 2003 Server guest OSs.
  • CPU Extended Features (for ESX Server 2.x hosts Being Managed by VirtualCenter 2.x) Can Be Overridden in the VirtualCenter 2.x Configuration File (vpxd.cfg). VirtualCenter 1.x provided the ability to override CPU feature compatibility by modifying VirtualCenter’s configuration file (config.ini), but VirtualCenter 2.0.1 and VirtualCenter 2.0.1 Patch 1 did not provide this same capability. In this release, you can now set specific CPU features (for an ESX Server 2.x) by modifying vpxd.cfg (the VirtualCenter configuration file). See KB 1993, “Migrations with VMotion Prevented Due to CPU Mismatch—How to Override Masks” for more information.
  • Support for VirtualCenter Server on Clustered Windows Configuration. When installed on Microsoft Cluster Server (MSCS) (or other clustered-Windows configuration), VirtualCenter disseminates its node IP address rather than the cluster’s IP address to managed hosts, which can lead to connectivity issues during fail-over situations. With this release, the correct IP address can be manually set, enabling you to deploy VirtualCenter server on Windows clusters. See KB 2195771, “ Manually Setting Cluster IP Address for Clustered VirtualCenter Server,” for details.

Known Issues

Note these known issues and limitations of the update:

  • Microsoft SQL Server 2005 Deployments Require “SQL Server” ODBC Driver. For Microsoft SQL Server installations supporting the VirtualCenter Center server, the SQL Server driver is the only driver supported (not the native SQL or other drivers). See Pre-Upgrade Tasks for Microsoft SQL Server.
  • Multi-byte Characters Not Allowed in Company- and User-name for Guest Customization Wizard. When using the Guest OS customization wizard, do not use multi-byte characters in the company name, domain, or workgroup entry fields. These entries cannot be supported.

Before Installing the Patch

This update includes modifications to the VirtualCenter database SQL scripts (required to support the changes to the statistics rollup). These changes are mostly transparent and occur during the installation process. However, if you are using an Oracle Database Server for your VirtualCenter system, you (or your organization’s DBA)) must perform the Oracle pre-upgrade task described below. In all cases (whether your VirtualCenter Server host has been configured to use Oracle Database Server or Microsoft SQL Server), as with any upgrade on a production system you should back-up the VirtualCenter database before you install the update.

Pre-Upgrade Tasks for Microsoft SQL Server:

  • Note that for Microsoft SQL Server or Microsoft SQL Server 2005, the SQL Server ODBC driver is the only driver supported for use with VirtualCenter Server. Verify that the ODBC driver configured for the database is the SQL Server driver—if it’s not, you must re-configure using the SQL Server driver prior to attempting to upgrade or install this update, or the installation will not succeed.
  • If you implemented the "VirtualCenter Performance Stats Rollup Workaround" (a VMware support document that provides instructions for setting up three scheduled SQL Server jobs to circumvent the deadlock issue), you must remove these jobs from the Microsoft SQL Server job scheduler (using SQL Server Enterprise Manager) prior to installing this update. If you did not configure scheduled jobs as a workaround, you can disregard this pre-upgrade task. However, be sure to backup your database prior to upgrading.

Pre-Upgrade Task for Oracle Database Server: The schema used to manage the VirtualCenter objects must be able to use Oracle’s DBMS_LOCK built-in package, which means it requires execute privileges on the package. Prior to installing the upgrade on an existing system, you (or your Oracle database administrator (DBA) must log on to the Oracle Database server as the sysdba and grant the privilege, as follows:

sqlplus system/<password>@<systemname> as sysdba
grant execute on dbms_lock to vpxadmin;

Note that the [@<systemname>] is relevant for a remote database host connection only. For example, assuming a database instance installed on the same host as the VirtualCenter server system, the session might look as follows:

C:\oracle\product\10.2.0\10gR2_Home\BIN>sqlplus system/techpubs as sysdba
SQL*Plus: Release - Production on Fri Jan 5 10:01:51 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release - Production
With the Partitioning, OLAP and Data Mining options

SQL> grant execute on dbms_lock to vpxadmin;

Grant succeeded.

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release - Production
With the Partitioning, OLAP and Data Mining options


For a fresh install of VirtualCenter on an existing Oracle Database Server, you must create the schema and grant it the appropriate privileges prior to VirtualCenter installation. Here’s an example of a SQL*Plus schema-creation session for an Oracle Database Server 10gR2 instance, from a Windows console:

sqlplus system/<password>[@<systemname>] as sysdba



Installing the Patch

VirtualCenter software updates comprise a complete software installation (rather than being supplemental software or “patches” in the strict sense.) As with a fresh install, the VirtualCenter installation program examines the local system, identifies any existing VirtualCenter installation, and guides you through the installation (or upgrade) process.

If VirtualCenter components are already installed on the host machine, the installation program prompts for confirmation that you want to upgrade.

  1. Backup your VirtualCenter database (as recommended above).
  2. Download the software installation file.
  3. Run the executable. Select VirtualCenter Management Server from the VMware VirtualCenter Installer startup page.
  4. Select "Yes" to upgrade an existing Installation.
  5. Step through the VirtualCenter Install Wizard, which guides you through several configuration details, including identifying your database instance. You will need to select your existing VirtualCenter database instance and enter the VirtualCenter database schema username and password.
    When prompted to over-write your existing database DSN (data source name), be sure to select No. The prompt reads as follows:
    "The DSN '<DSN name>' points to an existing VMware VirtualCenter repository. Would you like to overwrite the data?"
    • Selecting No modifies the table structure without over-writing any existing data in the tables.
    • Selecting Yes modifies the table structure, but also over-writes all existing data in the database tables. Do not select Yes unless you really want to do this.
  6. After upgrading the VirtualCenter Server, you must also upgrade all Windows host systems to the upgraded VI Client software. Use the same executable that you used to upgrade your VirtualCenter server host, but select Virtual Infrastrucure Client from the VMware VirtualCenter Installer startup page.

If you continue to have database-related performance issues after upgrading to this release, you can modify some of the new parameters discussed above, in VirtualCenter Database Server Deadlock (And Other Performance Issues) Resolved with New, Improved Statistics-Aggregation (Rollup) Procedures.

Checking Microsoft SQL Server Index- and Table-Fragmentation

For best results, index and table fragmentation should not exceed 30%. To check fragmentation, use the database consistency checker commands (one at a time):

If index fragmentation is above approximately 30%, you (or the system’s DBA) should set up a nightly or weekly maintenance plan (using Enterprise Manager’s Maintenance Plan Wizard).

Note: For VirtualCenter Server deployments that use Microsoft SQL Server database (configured for the “full” recovery model)—In addition to backing up the database, you must also regularly back up the transaction log. Failure to do so may result in “transaction log full” errors. See Microsoft SQL Server administration guides for information about “full” versus “simple” recovery models and to determine the model best suited for your environment.

For complete information about installing or upgrading VirtualCenter, see Installing and Upgrading the VirtualCenter Product.