VMware

VMware ESX Server 3.5 Update 3 Release Notes

 

VMware ESX Server 3.5 Update 3 | 6 Nov 2008 | Build 123630

Last Document Update: 9 Dec 2008

 

These release notes include the following topics:

Note: In many public documents, VMware ESX Server 3.5 is now known as VMware ESX 3.5, and VMware ESX Server 3i version 3.5 as VMware ESXi 3.5. These release notes continue to use the previous convention to match the product interfaces and documentation. A future release will update the product names.

What's New

The following information provides highlights of some of the enhancements available in this release of VMware Infrastructure 3:

Note: Not all combinations of VirtualCenter and ESX Server versions are supported and not all of these highlighted features are available unless you are using VirtualCenter 2.5 Update 3 with ESX Server 3.5 Update 3. See the ESX Server, VirtualCenter, and VMware Infrastructure Client Compatibility Matrixes for more information on compatibility.

New features and supported I/O devices:

  • Increase in vCPU per Core Limit — The limit on vCPUs per core has been raised from 8 (or 11 for VDI workloads) to 20. This change only raises the supported limit but does not include any additional performance optimizations. Raising the limit allows users more flexibility to configure systems based on specific workloads and to get the most advantage from increasingly faster processors. The achievable number of vCPUs per core depends on the workload and specifics of the hardware. It is expected that most deployments will remain within the previous range of 8-11 vCPUs per core. For more information, see VI3 Performance Best Practices and Benchmarking Guidelines.
  • HP BL495c support — This release adds support for the HP Blade Server BL495c with all Virtual Connect and I/O Options allowing 1 or 10Gb connection to the network (upstream) and 1Gb connections only to the servers (downstream).
  • Newly Supported NICs —  This release adds support for the following NICs:
    • Broadcom 5716 1Gb
    • Broadcom  57710 10Gb Adapters
    • Broadcom 57711 10Gb Adapters at 1Gb speed only
    Note: iSCSI/TOE hardware offloads available with these adapters are not supported with ESX Server 3.5.
  • Newly Supported SATA Controllers— This release adds support for the following SATA controllers:
    • Broadcom HT1000 (supported in native SATA mode only with SATA hard drives and Solid State Disk devices)
    • Intel ICH-7 (supported in IDE/ATA mode only with SATA CD or DVD drives)
    Note: Storing VMFS datastores on drives connected to these controllers is not supported.
  • Newly Supported Guest Operating Systems — Support for the following Guest Operating Systems has been added by VMware during the ESX 3.5 Server Update 3 release cycle:
    • Ubuntu 8.04.1
    • RHEL 4.7
  • Updated: Internal SAS networked storage controllers — This release enables the Intel Modular Server MFSYS25 SAS Storage Control Modules (SCMs). The system is pending ESX Server certification. Once ESX Server certification is complete, the system will be listed on the VMware Storage HCL, and be fully supported by VMware. For known issues with this platform and workaround, see SAS Link and Port Failovers with the Intel Modular Server Running Update 3 and Later Versions of ESX 3.5 and ESXi 3.5 (KB 1007394).
  • Interrupt Coalescing (IC) for Qlogic 4Gb FC HBAs — Introduced in this release, the feature reduces CPU utilization (and CPU cost per I/O) and improves throughput of I/O intensive workloads by generating a single interrupt for a burst of Fibre Channel frames, when received in a short period of time, rather than interrupting the CPU each time a frame is received. The feature is enabled by default.
  • Experimental Support for the VMDK Recovery Tool — This release adds support for the VMDK Recovery tool, a script intended to help customers to recover VMFS and VMDK datastores from accidental deletion of a datastore or physical disk corruption. For more information, see VMDK Recovery Tool (ESX 3.5 Update 3) (KB 1007243).
  • Small Footprint CIM Broker —  Updated SFCB to version 1.3.0
  • IBM SAN Volume Controller — SVC is now supported with Fixed Multipathing Policy as well as MRU Multipathing Policy.

Top of Page

Prior Releases of VMware Infrastructure 3

Features and known issues from prior releases of VMware Infrastructure 3, which include ESX Server 3.x and VirtualCenter 2.x releases, are described in the release notes for each release. To view release notes for prior releases of VMware Infrastructure 3 components, click one of the following links:

Top of Page

Before You Begin

Note: If you are installing this release from anything other than physical CD media, see the knowledge base article Filenames over 64 characters in ESX Server ISO image may get truncated during content extraction (KB 1005283) for important information on a known installation issue.

ESX Server, VirtualCenter, and VMware Infrastructure Client Compatibility

The ESX Server, VirtualCenter, and VMware Infrastructure Client Compatibility Matrixes document provides details on the compatibility of current and previous versions of VMware Infrastructure 3 components, including ESX Server, VirtualCenter, and the VI Client.

Hardware Compatibility

See the ESX Server Compatibility Guides before installing this software. You must verify that your server, I/O, storage, guest operating system, management agent, and backup software are compatible. These guides also address minimum requirements and scaling limits associated with this release. To view a guide, click one of the following links:

New: Documentation

All the documentation for ESX Server 3.5 Update 2 applies to ESX Server 3.5 Update 3 as well. However, the title pages of the documents refer only to ESX Server 3.5 Update 2 and VirtualCenter 2.5 Update 2. For a complete list of manuals and other documentation, see VMware Infrastructure 3 Documentation.

Installation and Upgrade

Read the Installation Guide for step-by-step guidance on installing and configuring ESX Server and VirtualCenter.

Although the installations are straightforward, several subsequent configuration steps are essential. In particular, read the following:

Upgrading or Migrating to ESX Server 3.5 Update 3 or ESX Server 3i version 3.5 Update 3

This release of ESX Server 3.5 Update 3 allows upgrades only from previously supported versions. The ESX Server 3.5 Update 3 Installer prompts you to perform an upgrade only when a previously supported version of ESX Server is found. See the Installation Guide for installation requirements.

To upgrade your ESX Server host to ESX Server 3.5 Update 3, follow one of these supported upgrade paths:

Upgrade type ESX Server 2.5.4
and 2.5.51
ESX Server 3.0.1 2 ESX Server 3.0.22 ESX Server 3.5 ESX Server 3.5 Update 1 ESX Server 3.5 Update 2
Tarball Yes Yes3 Yes4 Yes Yes Yes
ISO image Yes Yes Yes Yes Yes Yes
  1. For ESX Server 2.5.1, ESX Server 2.5.2, and ESX Server 2.5.3, upgrade first to ESX Server 2.5.4 and then upgrade to ESX Server 3.5 Update 3. Alternatively, upgrade to ESX Server 3.5 and then upgrade to ESX Server 3.5 Update 3.
  2. For ESX Server 3.0.0, upgrade first to ESX Server 3.0.1 or higher, and then upgrade to ESX Server 3.5 Update 3 by using an ISO image. Alternatively, upgrade to ESX Server 3.5 and then upgrade to ESX Server 3.5 Update 3.
  3. For ESX Server 3.0.1, Patch ESX-1003519 (see KB 1003519) must be applied before performing an upgrade that uses the tarball.
  4. For ESX Server 3.0.2, Patch ESX-1003525 (see KB 1003525) must be applied before performing an upgrade that uses the tarball.

For more information on installation and upgrade methods, see the Upgrade Guide.

Updated RPMs and Security Fixes

For a list of RPMs updated in ESX Server 3.5 Update 3 , see Updated RPMs and Security Fixes. This document does not apply to the ESXi products.

Top of Page

Patches Contained in this Release

This release contains all patches for the ESX Server software that were released prior to the release date of this product. See the ESX Server 3.5 Patches download page or click on the name of a patch for more information on the individual patches.

ESX Server 3.5 Update 3 contains the fixes contained in all of the following patches:

New Patches in Update 3 (6 Nov 2008 | Build 123630 )

Previously Released Patches


Top of Page

Resolved Issues

This release resolves issues in the following subject areas:

Backup

  • VirtualCenter displays incorrect information about VMware Tools after running VCB command for Windows 2003 guest
    Running a VMware Consolidated Backup command (file-level or full backup) on 32-bit or 64-bit Windows 2003 virtual machines displays a VMware Tools Not Running message in the Summary tab of VirtualCenter, even though VMware Tools is still running. This issue is resolved in this release.

CIM and API

  • New: The time returned by do_gettimeofday() appears incorrect
    The time reported by do_gettimeofday() is the number of seconds since boot. The value returned from do_gettimeofday() should be the number of seconds since 1970. This issue is resolved in this release.
  • New: On some servers, incorrect PECI temperature sensor readings might be reported. Incorrect values are shown in the VI Client and in the NominalReading property of CIM_Sensor instances for CPU PECI tic for Processor sensors. This issue is resolved in this release.
  • VMware_Identity takes too long to access large NIS databases
    The CIM_Identity provider has been disabled for this release because enumerating VMware_Identity takes too long on ESX systems that are configured to access large NIS databases. Therefore, if you request instances of VMware_Identity, VMware_Account, CIM_Identity, or CIM_Account, no instances will be returned.
  • Mandatory property MaxReadable,NominalReading,NormalMax, NormalMin and PollingInterval in class CIM_NumericSensor shows incorrect values
    The instances of CIM_NumericSensor have the following set of properties: MaxReadable, NominalReading, NormalMax, NormalMin. When the actual sensor does not support values of these properties, the values are displayed as 0 in CIM responses. This issue is resolved in this release.
  • Reporting of service.wbem status on port 5888
    On systems with ESX Server 3.5 Update 2 installed, SLP reports that "service:wbem" is available on port 5888. However, the default firewall settings prevent access to port 5888, and you have to unblock the port in the firewall configuration. This issue is resolved in this release. Starting with ESX Server 3.5 Update 3, the httpLocalOnly configuration option was introduced to determine whether or not the server advertises that it is listening on the HTTP port. If you unblock the HTTP port in the firewall, you must add httpLocalOnly=false to the cimserver_planned.conf configuration file.

Guest Operating Systems

  • The vmxnet module fails to load or build on 64-bit Ubuntu guest operating systems
    When installing or upgrading VMware Tools in 64-bit Ubuntu guest operating systems, the installer encounters an error that states that it could not load vmxnet into the running kernel. The VMware Tools installer attempts to build the module and fails to load the module and the vmxnet module is not copied to the module directory. This issue is resolved in this release.

VMware High Availability (HA)

  • The VI Client might show the host as "Not responding" during HA-DRS cluster operations
    During HA-DRS cluster operations like adding or removing a host from a DRS cluster or applying DRS recommendations, the VI Client might show the host as "Not responding," even when the host IP can be reached. This issue is resolved in this release.
    Workaround
    Disconnect the host from the HA-DRS cluster and reconnect it. This refreshes the system, and the VI Client reflects the configuration changes that you have made. If the VI Client again shows the host as "Not responding," disconnect the host from the HA-DRS cluster, remove the host, and add the host back to the same cluster.

Migration with VMotion

  • New: SNMP traps generated during VMotion
    During VMotion, SNMP trap power OFF messages are generated in the source ESX Server host, and SNMP trap power ON messages are generated in the target ESX Server host. This issue is resolved in this release. The traps will not be generated during VMotion on hosts with this Update installed.

Networking

  • New: Service Console Might Lose Network Connectivity on a Server with More than 128GB of Memory Installed (KB 1005375)
  • New: Network connectivity Might be Lost When Network Teaming Policy is Based on Port Id.
    Network connectivity might be lost when using network teaming, and the teaming policy is based on Port Id. The following error message might be logged in VMkernel:
    Aug 6 23:27:07 [hostname] vmkernel: 0:02:33:07.052 cpu0:1024)Net: L2Sec_EnforcePortCompliance:229: 0x3000005: peer not allowed
    promiscuous, revoking setting

    Network connectivity works fine if you enable the promiscuous mode of the virtual vswitch, and perform a tcpdump -i portgroup. But stopping tcpdump again results in loss of network connectivity. This issue is fixed in this release.
  • Network adapters lose bonding during scripted installation
    During a scripted installation, the following two commands do not result in a bonded pair of active network adapters on virtual switch VS_VM1. Instead, vmnic3 became the active adapter and vmnic4 became the standby adapter.
    esxcfg-vswitch -L vmnic3 VS_VM1
    esxcfg-vswitch -L vmnic4 VS_VM1

    The esxcfg-vswitch -L command now works as expected and with the same functionality as in 3.0.x.
  • ESX Server hosts become unresponsive during a network broadcast storm
    When a network broadcast storm occurs, ESX Server hosts might become unresponsive due to an issue with the tg3 network driver. During this time, service console or virtual machines that use the tg3 NIC might lose network connectivity. Rebooting the machine or unloading/loading the driver restores connectivity, but does not resolve the issue.
    ESX Server hosts with tg3 port cannot send or receive packets after being subjected to a broadcast storm. The following error messages might be logged in VMkernel:

    1. WARNING: Net: 1082: Rx storm on 1 queue 3501>3500, run 321>320
    2. VMNIX: WARNING: NetCos: 1086: virtual HW appears wedged (bug number 90831), resetting

    This issue is fixed in this release. This fix ensures that when the tg3 driver stops responding, the NIC is reset within 35 seconds.
  • NIC teaming fails to display a descriptive error message with beaconing enabled and when a NIC disconnects from a team of two NICs
    If you configure NIC teaming for beaconing and disconnect a NIC from a team of two NICs, a message similar to the following appears:
    Removing from config file only.
    The vmnic is also removed from the port group.

    Starting with this release, a suitable message similar to the following is displayed:
    Need uplink: for beaconing. (Minimum 2 required).
    The vmnic also stays in the port group.
  • High-Performance network driver for NetWare guests
    This release improves performance for NetWare guests by fixing compatibility issues between E1000.LAN driver and E1000 virtual NIC emulation.
  • e1000 Drivers fail with "P2MCache: GetPhysMemRange failed" error
    Intel Pro/1000 gigabit Ethernet device drivers (e1000) in some guests allocate MTU bytes for rx buffers, but tell the device the size of the rx buffer is 2048 bytes. If these buffers fall on the edge of the guest physical memory range, the virtual e1000 device could wedge during rx with the following messages in the VMkernel logs:
    WARNING: Alloc: ppn=0xc0000 out of range: 0x0-0xc0000 (count=3)
    WARNING: P2MCache: GetPhysMemRange failed: PPN 0xc0000 canBlock 0 status Bad parameter.
    This issue is resolved in this release.
  • Windows guest operating system stalls during reboot or shutdown
    In a corner case and under high network load, the Windows vmxnet driver misses send-completions on some packets. The Windows guest waits for these completions, which causes the guest to stall during a reboot or shutdown. This issue is resolved in this release.

Security

  • VMware privilege escalation on 32-bit and 64-bit guest operating systems
    A flaw in VMware's CPU hardware emulation might allow the virtual CPU to incorrectly handle the trap flag. Exploitation of this flaw could lead to a privilege escalation on guest operating systems. An attacker would need to have a user account on the guest operating system, and would need to have the ability to run applications.
    The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2008-4915 this issue.
  • VMware Web Access component JRE updated to version 1.5.0_16
    The currently installed version of JRE depends on your patch deployment history.
    For more information about security issues fixed in version 1.5.0_16 and in earlier versions, see the JRE release notes at http://java.sun.com/j2se/1.5.0/ReleaseNotes.html.
    For a list of the CVE identifiers related to the fixed security issues in JRE 1.5.0_16, see the advisory by Secunia at: http://secunia.com/advisories/31010.
  • chage -M option is not preserved after host reboot
    Previously, the root password expiration information was not preserved across hostd restarts. A new tag called rootPasswdExpiration is added to the /etc/vmware/hostd/config.xml file. If the rootPasswdExpiration tag is set to true, then the number of days to expiration will be preserved across hostd restarts.
    After setting the rootPasswdExpiration tag in the /etc/vmware/hostd/config.xml file as true, run the following command:
    chage –M <X> root
    Here, X is the number of days until expiration.
    Example: The command chage -M <60> root indicates the root password expires after 60 days.
    Note: Because the default value of rootPasswdExpiration tag is set as false, this fix does not impact customers who do not want the root password to expire.
  • Directory traversal vulnerability
    VirtualCenter allows administrators to have fine-grained privileges. A directory traversal vulnerability might allow administrators to increase these privileges. In order to leverage this flaw, the administrator needs to have the Datastore.FileManagement privilege.
    The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2008-4281 to this issue.

Server Configuration

  • New: Service console becomes read-only
    The service console becomes read-only when the IBM System Storage SAN Volume Controller (SVC) firmware is upgraded online or when the controller is reset. ESX Server should recognize the path as down and recover later when the controller is back online. This issue is resolved in this release.
  • New: The esxtop utility cannot support more than 32 network interface cards
    The esxtop utility that reports ESX Server resource utilization cannot report information on more than 32 network interface cards. This release resolves this issue. Systems with ESX Server Update 3 will dynamically read the number of NICs and show the statistics for all the devices.
  • Data Loss in Serial Ports
    This release resolves an issue where sending fax from a virtual machine using the serial port on the ESX Server host causes data loss such as missing lines and unclear information.
    This fix is activated by adding serial<n>.hardwareFlowControl = “TRUE” to the VMX file after patch installation.
  • tzdata RPM updates for daylight savings time
    This release supports the updated Service Console tzdata RPM with revised time zone rules. The new time zone rules reflect changes to Daylight Savings Time (DST) in the following regions:
    • Argentina
    • Brazil
    • Chile (mainland)
    • Cuba
    • Easter Island
    • Iraq
    • Morocco
    • Pakistan
    • Palmer Polar Station, Antarctica
    • Salas y Gómez Island
    • Syria
    • Venezuela
  • Boot option force36BitMTRRMask no longer required
    Because of BIOS MTRR issues on certain platforms, ESX Server hosts previously failed to boot unless the VMkernel force36BitMTRRMask boot option was set to false. This Update enables full support for memory up to 64GB with no need to specify a boot option.
    As a result of this change, the force36BitMTRRMask VMkernel boot option is no longer supported. If the option is set, the result is no operation (NOP) and boot succeeds.

Storage

  • Include SCSI Sense Codes in ESX 3.5 VMkernel Logs
    ESX Server 3.5 filters all SCSI sense codes out of /var/log/vmkernel by default. The absence of SCSI sense codes affects the troubleshooting and root cause analysis of storage issues. Without these codes, it is difficult to determine what has occurred at specific times on devices external to the ESX Server host.
    After applying this Update, SCSI sense codes are included in VMkernel logs, by default.
  • Support for advanced configuration options on iSCSI software to control multipath failover
    This fix enables iSCSI software to control multipath failover with LUN reset or target reset through the advance configuration options Disk.UseLunReset and Disk.UseDeviceReset.
  • In the VI Client, adding the software iSCSI target address in the dynamic discovery tab takes a long time
    The long delay occurs because a target discovery is triggered each time a discovery address is added. After adding the discovery address, you must rescan so that the VMkernel can find new targets from the added discovery address. This triggers a target discovery again. The target discovery performed after the addition of each discovery address is redundant and only results in unnecessary delays.
    This change removes the target discovery performed after each discovery address addition, thereby reducing the time taken for the operation.
  • "Failed to update disk partition information" error
    The disk partition information is not current, which causes various problems, such as Inventory not being updated and datastores not being created, extended, expanded, or removed. The following error message might be seen: Error during the configuration of the host:Failed to update disk partition information. This issue is resolved in this release.

Upgrade and Installation

  • Installation of ESX Server using kickstart file in interactive mode fails
    When ESX Server is installed using the kickstart file in the interactive mode, anaconda installer might stop responding. This issue is resolved in this release.
  • Upgrading to ESX Server 3.5 Update 3 with tarball causes "bundles cannot be found" error
    When using esxupdate to upgrade to Update 3 from an ESX release prior to Update 2, messages in the following format may be seen in the output:
    INFO: [ESX350-200802408-SG] requires ['ESX350-200802403-BG'] but these bundles cannot be found. Please make sure they are in the depot and specified in the bundle list.
    INFO: [ESX350-Update03] requires ESX350-200802408-SG, but it is not applicable.

    These messages are produced by the old version of esxupdate. During this upgrade operation, esxupdate will get updated to the latest version by the pre-install mechanism, the dependency resolution will be performed correctly and these messages will no longer be seen.

    To verify that the upgrade completed successfully check the output of `esxupdate query` and observe that the ESX350-Update03 bundle is listed as installed.
  • List of network devices now displayed correctly during ESX Server installation
    This release resolves an issue where during a fresh ISO install for ESX Server 3.5, the drop-down menu on the network configuration screen lists unsupported network devices and sometimes hides supported network devices. Network devices that do not have a corresponding driver module loaded in the installer environment are omitted from the list.
  • The esxupdate query Command Does Not Display Obsolete Bundles
    In prior releases of ESX, the esxupdate query command does not list the obsolete bundles. To resolve this issue, esxupdate adds two new options:
    • -a or --listall. This option displays all installed bundles, including obsolete bundles.
    • -o or --onlyobsolete. This option displays only obsolete installed bundles.
  • Installation of ESX350-200805501-BG or ESX350-200806401-BG cause esxtop to cease functioning (KB 1007391)

Virtual Machine Management

  • New: Data sent to keyboard port can cause virtual machine shutdown
    Data with unusual data sizes sent to the keyboard I/O port can cause the shutdown of a virtual machine. To cause this issue, privileged access to the keyboard port from the guest Operating System is required. This issue does not affect the ESX Server host or other virtual machines. This issue is resolved in this release.
  • vmware-cmd stop trysoft performs hard stop after soft power operation fails
    With ESX Server 3.5 Update 3, the vmware-cmd stop trysoft command now works as documented. The command first attempts to perform the power transition operation with vmPowerOpMode_Soft. If this fails, the same operation is performed with vmPowerOpMode_Hard. The command worked correctly in ESX Server 2.5; however, in previous versions of ESX Server 3.x, if the soft operation failed, the hard operation was not attempted.

Top of Page

Known Issues

This section contains known issues for this release in the following subject areas:

Backup

  • VMware Consolidated Backup is not updated in this release
    ESX Server 3.5 Update 3 does not include an updated version of VMware Consolidated Backup. This release is shipped with version 1.5.0 and contains no changes to VMware Consolidated Backup since the release of ESX Server 3.5 Update 2.
  • Consolidate Helper Snapshots Might Not Be Removed Automatically
    In the ESX Server 3.5 Update 2 release, Consolidate Helper snapshots are created iteratively to minimize the amount of time a virtual machine is inactive during snapshot creation. As a result, the Consolidate Helper snapshots are now called Consolidate Helper-xxx and not just Consolidate Helper. When you use VMware Consolidated Backup 1.1 with ESX Server 3.5 Update 2 or higher, if vcbMounter encounters a failure during a snapshot delete operation, this temporary snapshot might be left behind. The vbCleanup.bat command does not delete the Consolidate Helper-xxx snapshot. You must manually delete it using the VI Client. This issue does not exist in VMware Consolidated Backup 1.5.

CIM and API

  • Some CIM classes do not work properly on IBM Multinode systems
    The following anomalies are seen. For the following classes, the EnumerateInstance operation returns one instance fewer than the EnumerateInstanceNames operation:
    • CIM_AssociatedSensor
    • CIM_MemberOfCollection
    For the following classes, the GetInstance operation fails for some instances. However, the EnumerateInstances operation succeeds:
    • CIM_HostedService
    • CIM_Sensor
    • CIM_SystemDevice
    • CIM_Slot
    • CIM_ElementConformsToProfile
    For the following classes, the EnumerateInstances and EnumerateInstanceNames operations fail to return any results:
    • CIM_OwningCollectionElement
    • CIM_RedundancySet
  • Operation RequestStateChange(RestoreDefaultThresholds) results in error
    In the ESX Server 3.5 release, the operation RequestStateChange(RestoreDefaultThresholds) results in the following error message for some sensors:
    CIM_ERR_FAILED: index out of bounds

    In spite of the error message, the CIMOM does restore the thresholds.
  • VI Client displays incorrect name for power supply redundancy sensor on HP servers
    When you connect to an ESX Server installation on an HP server system using VI Client, the VI Client incorrectly displays the power supply redundancy sensor on the server as a physical power supply source. For example, for an HP server with redundancy sensor that has two physical power supplies, the VI Client displays the redundancy sensor as Power Supplies for Power Supply 3.
  • Executing a CallMethod query on a CIM_RecordLog instance might fail
    In ESX Server 3.5 Update 3, executing a CallMethod query (cm) on a CIM_RecordLog instance might not succeed at all times. You can, however, clear system event log through a remote management console or interface.
  • Changes to the sensor threshold are not reflected immediately
    If you change the sensor threshold through CIM, enumeration of the sensor might not return the new property values immediately. The changes take effect about a minute later.
  • On some Dell MLK hardware, the NumberOfBlocks property for OMC_Memory instance has a value of 0. This issue is under investigation.
  • On HP 380 G5 machines running ESX Server 3.5 Update 3 the IPMI board's IP address is not returned in response to CIM_IPProtocolEndpoint queries.
  • InvokeMethod(RequestStateChange) for either Sensor and SEL fails when you use the WS-Man protocol.
  • The ModifyInstance() call to change sensor threshold fails when you use the WS-Man protocol.
  • An ESX Server 3.5 host that has been upgraded to ESX Server 3.5 Update 3 does not report CIM_AssociatedSensor instances correctly. The EnumerateInstance() and Association() queries for CIM_AssociatedSensor do not return any instances.
    Workaround: Do a clean installation of ESX Server 3.5 Update 3.
  • Indications do not work on ESX Server 3.5 Update 3 when you use the WS-Man protocol.
  • On IBM IBM x3850 M2 and x3950 M2 servers, some OMC_DiscreteSensor instances are found to have incorrect device IDs (with -1 as the last segment of the device ID).
  • The InvokeMethod(RequestPowerStateChange) fails when you use the WS-Man protocol.
  • The chassis intrusion indication is not available for IBM x3850 M2 and x3950 M2 servers.

Guest Operating Systems

  • Solaris 10 Update 4, 64-bit graphical installation fails with the default virtual machine RAM size of 512MB
    After installing Update 3, Solaris 10 Update 4, 64-bit graphical installation fails with the default virtual machine RAM size of 512MB.
    Workaround: Use the Solaris 10 Update 4 text-mode installer or set the RAM size in the virtual machine to at least 580MB.
  • Linux guest operating systems lose network connectivity after automatic tools upgrade
    If the version of VMware tools in a Linux guest operating system becomes out of date and an automatic tools upgrade is performed, the guest operating system loses network connectivity. After an automatic tools upgrade, the guest operating system stops the network service and does not restart the service automatically after tools upgrade.
    Workaround: Restart the network service in the guest operating system manually or reboot the guest operating system after an automatic tools upgrade.
  • x64-based versions of Windows Vista and Windows Server 2008 guest operating systems require Microsoft hotfix
    x64-based versions of Windows Vista and Windows Server 2008 guest operating systems without Microsoft hotfix http://support.microsoft.com/kb/950772 might encounter a situation where the guest operating system stops responding and returns the following error:
    MONITOR PANIC: vcpu-3:ASSERT vmcore/vmm/cpu/segment.c:430
  • Windows Guest operating systems might fail to resume from standby or hibernation state
    Virtual machines running Windows Server 2008 and Windows Server 2003 based guest operating system in the standby or hibernation state might stop responding when resumed from standby or hibernation states.
    See KB 946331 on the Microsoft support Web site.
  • VMware Tools uninstaller in Ubuntu guest does not remove vmxnet module (KB 1004351)
  • Unable to Log in to Cloned Windows Vista Virtual Machine Using Administrator Account (KB 1004301)
  • VMware Tools Upgrade on Linux Guests Requires Manual Network Service Restart (KB 1004322)
  • VMware Tools Upgrade for Windows Guest Cannot Continue (KB 1004317)
  • Ubuntu 7.10, 64-Bit SMP Can Stall When Running, Installing, or Booting on an Intel Host (KB 1004384)

VMware High Availability (HA)

  • New: Virtual Machine may unexpectedly reboot when using VMware HA with Virtual Machine Monitoring on ESX 3.5 Update 3 (KB 1007899)
  • HA network compliance check
    During the configuration of HA in VirtualCenter 2.5 Update 2, the Task & Events tabs might display the following error message and recommendation:

    HA agent on <esxhostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Network:
    Consider using the Advanced Cluster Settings das.allowNetwork to control network usage.


    Starting with VirtualCenter 2.5 Update 2, HA has an enhanced network compliance check to increase cluster reliability. This enhanced network compliance check helps to ensure correct cluster-wide heartbeat network paths. See KB 1006606 for details.
  • Virtual Machine Migrations Are Not Recommended When the ESX Server Host Is Entering the Maintenance or Standby Mode
    VMware HA will not recommend or perform(when in fully automated mode) virtual machine migrations off of a host entering maintenance or standby mode, if the VMware HA failover level would be violated after the host enters the requested mode. This restriction applies whether strict HA admission control is enabled or not.
  • VMware HA Health Monitoring Does Not Show Rebooting in the Console After a Host Failover
    After a host failure, the VMware console displays an empty window when Health Monitoring is enabled for an HA cluster. The console does not display the virtual machines rebooting.

    Workaround
    You must open a new console to see the virtual machines restarting after the failover.

Internationalization

All fields in the VI Client and VI VMware Web Access support non-ASCII character input, except for the following limitations:

Non-ASCII Character Entry Limitations

  • Specifying a non-ASCII value as an input string is not supported by the remote command line interface (RCLI).
  • The name of the computer on which VMware Infrastructure 3 or any of its components are installed must not contain non-ASCII characters.
  • The name of the computer or virtual machine where VirtualCenter Server is installed must not have a non-ASCII computer name. Otherwise, the installation of VirtualCenter Server will fail.
  • Use the default installation path names specified in the installer for all components. Do not change the install pathto include installation path names containing non-ASCII characters and extended-ASCII characters.
  • Datastore names, virtual network names, and image file names (CD, DVD, and floppy drive) are restricted to ASCII characters only.
  • Message of the Day must use only ASCII characters.
  • Logging in to the VirtualCenter Server is supported for user names with ASCII characters only (login account name on Windows).
  • Image customization might fail if non-ASCII characters are used.
  • Custom attribute names and values must use only ASCII characters.
  • To conform to the general Internet practice and protocols, host names, workgroup names, domain names, URLs, email addresses, SMTP server names, and SNMP community strings cannot contain non-ASCII characters.
  • Guest operating system customizations that use ASCII encoding are supported but customizations using UTF-8 encoded native characters of Japanese, Chinese, or German have limited support. For customizations with non-ASCII owner, organization, username, or password, VirtualCenter and the sysprep tool must be hosted in the same locale as that of the guest OS. This includes the scenario to use UTF-8 encoded answer file.

Non-ASCII Character Display Limitations

  • When managing a VirtualCenter Server with the VI Client running on different languages of Windows, you might see some characters displayed incorrectly because of the difference in language-specific support on Windows.
  • If an error message includes log locations or user names containing non-ASCII characters, it does not display correctly in the localized environment.
  • When you use the Import wizard of VMware Converter, the date and time format is sometimes inconsistent with the current locale.
  • Unicode characters are displayed as '???' under the Status column and the Task Details of the Task View tab in the Japanese locale.
  • The Commands section on the Summary tab is not displayed properly.

Guided Consolidation Limitations

The Guided Consolidation tab is available only in the en_US locale.

Translation Issues

The following are known issues with translation in this release:

  • The Upgrade wizard is not translated.
  • Some messages originating from the ESX Server host are not translated.
  • Some localized interface layouts are not yet completed.

Other Internationalization Issues

The following additional issues have been identified:

  • Values used in the Run a Script action for an alarm might not display properly after restarting VirtualCenter Server if the VMware Infrastructure Client host OS language and VirtualCenter Server/Database host OS languages are different.
  • In the Simplified Chinese version of VI Web Access, the Cancel button does not have the correct text and the text on the button is displayed incorrectly.
  • The VI Client Might Override the Language Preference Setting
    The VI Client Might Override the Language Preference Setting and display some messages in a language other than its primary language. It might display messages that are dynamically generated by the server (VirtualCenter Server and ESX Server) in the primary language set on the server. This issue does not occur if all the software is running in the language that corresponds to the locale of the operating system.
  • Wrong Text Appears on the Reinstall Wizard of the German VI Client
    The reinstall wizard displays wrong text in the German VI Client.
    The reinstall wizard shows the following text
    Der Installations-Assistent ermöglicht Ihnen, VMware Infrastructure Client 2.5 zu reparieren oder zu entfernen., instead of The installation wizard will allow you to remove VMware Infrastructure Client 2.5.
  • Links Containing Machine-Generated Virtual Machine Names Do Not Work

    When you use VMware Web Access to browse the datastore by clicking a link containing machine-generated virtual machine name (typically starting with a plus sign and ending with slash, for example +5paw55qE5qih5p2,/), the Web browser displays a blank page or returns a page not found error. You can, however, access such virtual machines using the VI Client.

Migration with VMotion

Miscellaneous

Networking

  • New: Extended netperf testing for IPv6 fails
    Running high levels of stress using netperf on Internet Protocol Version 6 (IPv6) enabled virtual machines over 12 hours might result in the shutdown of sockets. The following sockets are known to be affected: TCP_STREAM, UDP_STREAM, TCP_RR, and UDP_RR. Error messages similar to the following might be displayed in the virtual machine console:

    send_tcp_rr: data recv error: Connection timed out
    netperf: cannot shutdown tcp stream socket: Transport endpoint is not connected

    This is a known issue.
  • Microsoft Windows virtual machine fails while receiving jumbo frames
    Microsoft Windows virtual machine fails and displays a blue screen while receiving jumbo frames if the ESX host has booted in the Debug mode.
  • Driver for NetXen NICs Supports Up to 31GB of Physical RAM on ESX Server Hosts (KB 1003046)
  • Duplicate Packets Are Created When Beacon Probing is Used With a VLAN of 4095
    During a virtual machine network operation where the VLAN ID is set to 4095 and the associated vSwitch is configured with beacon probing, duplicate packets are generated.
    Workaround: When using a VLAN ID of 4095, set Network Failover Detection to Link Status only instead of Beacon Probing. ( KB 1004373)

Server Configuration

Storage

Upgrade and Installation

VirtualCenter Upgrade and Installation

Virtual Machine Management

  • New: VMware Tools icon is missing from the Control Panel for 64-bit Windows Vista and Windows 2008 guest operating systems
    Only the 32-bit control panel is available for VMware tools on Windows Vista and Windows 2008 guest operating systems and so VMware Tools does not appear in the control panel of the 64-bit operating systems.

    Workaround: Use the 32-bit control panel applet that is available from the VMware Tray or from C:\Program Files (x86)\VMware\VMware Tools\VMControlPanel.cpl or <VMware tools install path>\VMControlPanel.cpl.
  • Installation of ESX350-200805501-BG or ESX350-200806401-BG cause esxtop to cease functioning (KB 1007391)
  • User with 'Create' Privileges Cannot Create Virtual Machines(KB 1004417)
  • Cloned Virtual Machines do not Contain DNS Suffix (KB 1004299)
  • Deploying Virtual Machine From a Template Fails With No Permission Error (KB 1004295)
  • Cloned Virtual Machines See the .vmdk File of the Source Virtual Machine (KB 1004176)
  • VMware Tools Custom Script Not Executed for Suspend or Shut Down Events (KB 1004390)
  • Virtual Machines Might Not Power on After a Failover When the Host Is Isolated
    Virtual machines might not start after a failover when a host is isolated and the isolation response is set to Guest Shutdown which is the default configuration for a cluster. This might occur on clusters with fewer than five nodes and can happen on virtual machines that take more time to complete the guest shutdown.
    Workaround
    Set the Isolation Response to either Leave powered on or Power off for clusters which have fewer than five nodes.
    To set the Isolation Response for a virtual machine, select the cluster, click the Edit Settings link, and select Virtual Machine Options under VMware HA. From the Isolation Response pop-up menu, select either Leave powered on or Power off options for the specific virtual machine.
  • I/O Might Stall on Virtual Machines During Firmware Upgrade
    When Virtual machines are running on a shared LUN that has heavy I/O workload, and if the firmware is upgraded using the storage management utility or if the storage controller is restarted, I/O might stall on any of the virtual machines.
    Messages similar to the following might appear in the vmkernel.log file:
    1:01:05:07.275 cpu2:1039)WARNING: FS3: 4785: Reservation error: Not supported
    SCSI: 4506: Cannot find a path to device vmhba1:0:125 in a good state. Trying path vmhba1:0:125.
    1:01:05:10.262 cpu3:1039)ALERT: SCSI: 4506: Cannot find a path to device vmhba1:0:125 in a good state. Trying path vmhba1:0:125.
    1:01:05:40.748 cpu1:1083)<6>mptbase: ioc0: LogInfo(0x30030108): Originator={IOP}, Code={Invalid Page}, SubCode(0x0108)
    1:01:05:40.930 cpu0:1024)Log: 472: Setting loglevel (via VSI) for module 'SCSI' to 5

VirtualCenter, VI Client, and Web Access Issues


Top of Page

Using Language Packs on the ESX Server Host

For German, Japanese, or Simplified Chinese language support when you use Virtual Infrastructure Web Access or the VI Client with your ESX Server host, the language pack must be on the host and the default locale set to your desired language. Starting with ESX Server 3.5 Update 3, the language pack files are installed on all hosts and do not need to be copied to the host before changing the locale.

To set the default locale on the host.

  1. Edit the /etc/vmware/hostd/config.xml file to enable the correct default locale. Find the following lines in config.xml:
       <locale>
          <DefaultLocale>en_US</DefaultLocale>
       </locale>

    For German, replace the lines with the following:

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

    For Japanese, replace the lines with the following:

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

  2. For Simplified Chinese, replace the lines with the following:

       <locale>
          <DefaultLocale>zh_CN</DefaultLocale>
       </locale>

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

    service mgmt-vmware restart
    service vmware-VMware Web Access restart

 

Top of Page