VMware

VMware VirtualCenter 2.0.2 Update 4 Release Notes

Check back frequently for additions and updates to these release notes.

VMware VirtualCenter 2.0.2 Update 4| 30 May 2008 | Build 89601

Last Document Update: 30 May 2008

What's in the Release Notes

VirtualCenter 2.0.2 Update 4 release includes all the fixes from the VirtualCenter 2.0.2 Update 3 release and also includes fixes for certain virtual machine management issues.

This maintenance release includes changes to the VirtualCenter Server and the VI Client software. If you upgrade a VirtualCenter Server host using this maintenance release, you must also upgrade all VI Client installations. You can upgrade the VI Client by downloading the software from an upgraded VirtualCenter Server host, or by selecting VI Client from the VirtualCenter installation startup page.

These release notes cover the following topics:

Resolved Issues

VirtualCenter 2.0.2 Update 4 resolves previous issues with the following virtual machine management enhancements:

  • The hostinfo.pl Script Reports Same Set of Values for Both VirtualCenter Server and Managed ESX Server Hosts
    This release fixes an issue where, if an ESX Server host is managed by a VirtualCenter Server, the hostinfo.pl script sometimes reports different values for the rebootrequired property for the managed ESX Server host and the VirtualCenter Server.
  • Templates Can Be Cloned to DRS Clusters That Have Their Automation Level Set to Be Fully Automated
    This release fixes an issue where cloning a template, when the destination of the cloned template is a DRS cluster that has its automation level set to Fully automated might fail with an error message similar to following:
    A Specified Parameter was not correct.
  • Non Alpha Numerical Characters Are Supported in Annotations of Virtual Machines and ESX Server Hosts
    This release fixes an issue where, if non alpha numerical characters are used in the Notes text box while adding annotations to virtual machines or the ESX Server hosts, the VirtualCenter Server stops responding and logs an entry similar to the following in the vpxd.log file:
    Unhandled exception: not well-formed (invalid token).
  • VirtualCenter Server Remains Responsive When a Scheduled Task Is Modified
    This release fixes an issue where, if the time of execution of a scheduled task is rescheduled to an earlier time, although the scheduled task performs successfully, the VirtualCenter Server crashes at the time the task was originally scheduled.
  • VirtualCenter Server Supports Templates That Are Registered Directly from an ESX Server Host
    This release fixes an issue where, if the name of the template that is registered directly from the ESX Server host (using the vmware-cmd -s command) is identical to any other template name in the datacenter, the VirtualCenter Server stops responding.
  • Socket-Related Errors No Longer Disconnect ESX Server Hosts from VirtualCenter Server
    This release fixes an issue where, if a VirtualCenter Server sends email alerts, the socket connections to the email server do not close, and the SMTP ports remain in the CLOSE_WAIT state for long periods of time, thus disconnecting the ESX Server host from the VirtualCenter Server. Starting with this release, the SMTP connections are terminated locally and the socket connection to the email server close after the VirtualCenter Server sends email alerts.
  • Virtual Machine Templates Remain Associated with Managed ESX Server Host
    This release fixes an issue where, templates of virtual machines show up as orphaned when the vmware-vpxa service of the managed ESX Server host is restarted.
  • VirtualCenter Server Remains Responsive When a Search Operation Is Performed in a Large Active Directory Domain
    This release fixes an issue where, if a VirtualCenter Server is used with an Active Directory that has large number of username entries and if a search operation is performed on the usernames in the Active Directory Domain, the VI Client disconnects from the VirtualCenter Server and the VirtualCenter service stops responding.
  • Web Browsers Retain Fully Qualified Domain Names When Using VI Web Access
    This release fixes an issue where, if a fully qualified domain name is used to log in to VI Web Access to access a VirtualCenter Server, Web browsers truncate the fully qualified domain name in the address bar to the hostname of the VirtualCenter Server.
  • VirtualCenter Server Sends Property Update Notifications When the Datastore Attribute Changes at the Compute Resource Level
    Starting with this release, the VirtualCenter Server sends property update notification when any datastore change at the compute resource level is detected. Client applications receive update notification, if a property filter is created to receive notification for any changes to the datastore attribute at the compute resource level.

Known Issues

Please review the known issues associated with the previous releases. Except for the issues listed in the Resolved Issues section of these release notes, all known issues are the same as with previous releases. See the VirtualCenter 2.0.2 Release Notes and the VirtualCenter 2.0.2 Update 3 Release Notes for more information.

Before Installing VirtualCenter 2.0.2 Update 4

Back up the VirtualCenter database before you install this maintenance release.

Before you begin the installation process, complete the following preinstallation tasks relevant to your Virtual Infrastructure configuration:

Managed ESX Server 3.0.x Preinstallation Tasks

Before upgrading VirtualCenter Server, all ESX Server 3.0.1 hosts must have patch ESX-1002083 and all ESX Server 3.0.2 hosts must have patch ESX-1002088. Without this patch, those hosts might appear in the "disconnected" state after the VirtualCenter upgrade because the required VirtualCenter Agent update on that host might fail. See KB 1002083 and KB 1002088 to download the patches, and KB 4478241 for more background on this issue.

Oracle Database Server Preinstallation Tasks
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 in 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 10.2.0.1.0 - 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 10.2.0.1.0 - 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 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

C:\oracle\product\10.2.0\10gR2_Home\BIN>

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
CREATE SMALLFILE TABLESPACE "VIRTUALCENTER"
DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TECHPUBS\virtualcenter'
SIZE 500M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

ALTER DATABASE DEFAULT TABLESPACE "VIRTUALCENTER";

CREATE USER "VPXADMIN" PROFILE "DEFAULT"
IDENTIFIED BY "*******"
DEFAULT TABLESPACE "VIRTUALCENTER"
TEMPORARY TABLESPACE "TEMP"
ACCOUNT UNLOCK;
GRANT "CONNECT" TO "VPXADMIN";
GRANT "RESOURCE" TO "VPXADMIN";
GRANT "CREATE VIEW" TO "VPXADMIN";
GRANT "EXECUTE ON DBMS_LOCK" TO "VPXADMIN";

Microsoft SQL Server Preinstallation Tasks
If your current VirtualCenter installation is configured to use an ODBC System Data Source Name (DSN) that points to the master database, perform the following tasks:
  1. Create a new database for the VirtualCenter Server.
  2. Stop the VirtualCenter Server service.
  3. Migrate all VirtualCenter-related data from the master database to the new database. Database objects associated with a VirtualCenter installation start with VPX. It is advisable that the data migration be performed by a qualified database administrator (DBA).
  4. Modify the ODBC System DSN used by your VirtualCenter installation to point to the new database.

For a fresh install of VirtualCenter, perform the following tasks:

  1. Create a new database for the VirtualCenter Server.
  2. Create an ODBC System DSN that points to this database.

For information on using SQL Server 2005 as a VirtualCenter Server database, see KB 6565318.

Installing VirtualCenter 2.0.2 Update 4

VirtualCenter software maintenance releases comprise a complete software installation (rather than being supplemental software or "patches"). 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.

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

  1. Back up your VirtualCenter database (as recommended above).
  2. Download the software installation file from http://www.vmware.com/download/vi/.
  3. Stop the VirtualCenter Server service.
  4. Use autorun.exe to start the installation. Select VirtualCenter Management Server from the VMware VirtualCenter Installer startup page.
  5. Select Yes to upgrade an existing Installation.
  6. Note: If you are using Microsoft SQL Server as your database server, using the "master" database for VirtualCenter Server tables is not a supported configuration. If your previous VirtualCenter Server installation was configured to use the "master" database instead of a specific database created for VirtualCenter Server, a warning message is displayed stating that your current configuration is not supported and that it has to be manually corrected. This warning message is displayed in a GUI-based installation only.

  7. 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 and enter the VirtualCenter database user name and password.
  8. After upgrading the VirtualCenter Server, you must also upgrade all Windows host systems to the upgraded VI Client software. Use the autorun.exe again to start the installer but select Virtual Infrastructure Client from the VMware VirtualCenter Installer startup page.

Note: If the existing installation of VirtualCenter service fails to shut down gracefully by releasing all the system resources, the upgraded installation of VirtualCenter service will be prevented from starting. In this case, you must reboot the VirtualCenter Server machine.

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

Installing Language Packs on the ESX Server Host

If you want German or Japanese language support when using VI Web Access or the VI Client with your ESX Server host, you must install language packs.

To install language packs:

  1. Locate the language pack ZIP file in the langpack directory on the ESX Server installation CD, or download the language pack ZIP file from http://www.vmware.com. The file has the name VMware-esxlangpack-2.0.2-build#.zip.
  2. Extract the contents of the ZIP file into a temporary directory.
  3. Copy the files from the ESX-LangPack/hostd/ directory to the hostd installation directory on your ESX Server host (usually usr/lib/vmware/hostd/).

    cp -pr ESX-LangPack/hostd/locale /usr/lib/vmware/hostd

  4. Copy the files from the ESX-LangPack/webAccess/ directory to the VI Web Access installation directory on your ESX Server host (usually /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/webapps/).

    cp -pr ESX-LangPack/webAccess/webapps/ui /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/webapps/
    cp -pr ESX-LangPack/webAccess/webapps/WEB-INF /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/webapps/ui/
    cp -pr ESX-LangPack/docroot /var/lib/vmware/hostd/

  5. Edit the /etc/vmware/hostd/config.xml file to enable the correct default language:

    For German, add the following lines to the config.xml file:

       <locale>
          <DefaultLocale>de_DE</DefaultLocale>
       </locale>

    For Japanese, add the following lines to the config.xml file:

       <locale>
          <DefaultLocale>ja_JP</DefaultLocale>
       </locale>

  6. Type the following commands to restart VI Web Access and host agent services:

    service mgmt-vmware restart
    service vmware-webAccess restart