VMware

VMware vSphere 4.0 Release Notes—ESXi Edition

ESXi 4.0 Installable | 21 MAY 2009 | Build 164009

ESXi 4.0 Embedded | 21 MAY 2009 | Build 164009

vCenter Server 4.0 | 21 MAY 2009 | Build 162902

Last Document Update: 10 SEP 2010

What's in the Release Notes

The release notes cover the following topics:

What's New

This release of vSphere 4.0 includes ESXi 4.0 Installable, ESXi 4.0 Embedded, and vCenter Server 4.0. Read about the new and enhanced features in this release in What's New in VMware vSphere 4.0.

Before You Begin

ESXi, vCenter Server, and vSphere Client Version Compatibility

The vSphere Compatibility Matrixes provide details on the compatibility of current and previous versions of VMware vSphere components, including ESXi, vCenter Server, the vSphere Client, and optional VMware products. In addition, check the vSphere 4.0 Compatibility Matrixes for information on supported management and backup agents before installing ESXi or vCenter Server.

Installation Notes for This Release

Read the ESXi Installable and vCenter Server Setup Guide for step-by-step guidance on installing and configuring ESXi Installable and vCenter Server or the ESXi Embedded and vCenter Server Setup Guide for step-by-step guidance on setting up ESXi Embedded and vCenter Server.

After successful installation of ESXi Installable or successful boot of ESXi Embedded, several configuration steps are essential. In particular, some licensing, networking, and security configuration is necessary. Refer to the following guides in the vSphere documentation for guidance on these configuration tasks.

Future releases of VMware vSphere might not support VMFS version 2 (VMFS2). VMware recommends upgrading or migrating to VMFS version 3 or higher. See the vSphere Upgrade Guide.

Future releases of VMware vCenter Server might not support installation on 32-bit Windows operating systems. VMware recommends installing vCenter Server on a 64-bit Windows operating system. If you have VirtualCenter 2.x installed, see the vSphere Upgrade Guide for instructions on installing vCenter Server on a 64-bit operating system and preserving your VirtualCenter database.

The VMware Tools RPM installer, which was previously available on the VMware Tools ISO image for Linux guest operating systems, has been removed for this release of ESXi. VMware recommends using the tar.gz installer to install VMware Tools on virtual machines with Linux guest operating systems.

Management Information Base (MIB) files related to ESXi are not bundled with vCenter Server 4.0. Only MIB files related to vCenter Server are shipped with vCenter Server 4.0. All MIB files can be downloaded from the VMware Web site at http://www.vmware.com/download.

Internationalization

VMware vSphere 4.0 is available in the following languages:

  • English
  • German
  • Japanese
  • Simplified Chinese

vSphere Client Locale Forcing Mode

With vSphere 4.0, you can configure the vSphere Client to provide the interface text in English even when the machine on which it is running is non-English. This configuration can be done for the duration of a single session by supplying a command-line switch. This configuration applies to the interface text and will not affect other locale-related settings such as date/time or numeric formatting.

The following vSphere Client command will cause the individual session to appear in English:
vpxClient -locale en_US

About Upgrade Tools for This Release

vCenter Server Upgrades

You can upgrade VirtualCenter Server 2.x to vCenter Server 4.0. To upgrade, first confirm that your database is supported with vCenter Server 4.0, back up your supported database, SSL certificates, and VirtualCenter Server configuration. Then run the vCenter Server installer. The installer informs you that an earlier version of vCenter Server is on the computer and will be upgraded.

Note: Upgrading VirtualCenter Server 2.0.x to vCenter Server 4.0 or later is not supported on operating systems running the Japanese locale.

ESXi Upgrades

vSphere 4.0 offers two GUI-based applications that you can use to upgrade ESXi 3.5 to ESXi 4.0:

Test Releases of vSphere 4.0

Upgrades from the vSphere 4.0 Beta and the vSphere 4.0 Release Candidate releases to vSphere 4.0 are not supported. Uninstall ESXi 4.0 Beta or Release Candidate and vCenter Server 4.0 Beta or Release Candidate, and perform fresh installations of vCenter Server 4.0 and ESXi 4.0. If you were testing Beta or Release Candidate versions of vSphere 4.0, VMware recommends recreating data you want to preserve from those setups on vSphere 4.0.

Migration of virtual machines by using VMotion from a Beta or a Release Candidate host to a vSphere 4.0 host is not supported.

VMware vSphere Web Services SDK

This release of the vSphere Web Services SDK is designed to leverage new features available in vSphere 4.0 servers: ESX, ESXi, and vCenter Server 4.0 server systems. This SDK can also be used with all previous versions of ESX Server and VirtualCenter Server. For more information, and to download the vSphere Web Services SDK 4.0, see VMware vSphere Web Services SDK Documentation.

Open Source Components for vSphere

Open source components and their respective licenses for the most recent generally available release of vSphere is available at http://www.vmware.com/download/vsphere/open_source.html, under the Open Source tab. You can also download the source files for any GPL and/or LGPL, or other similar licenses that require the source code or modifications to source code to be made available, for the most recent generally available release of vSphere, by clicking on the link noted above.

Known Issues

The Known Issues section covers Functionality Caveats and provides a List of Known Issues.

Functionality Caveats

ESXi Rollback

Each time you patch, update, or upgrade an ESXi host, a copy of the ESXi build is saved on your host. If you think an ESXi patch might be causing issues for your host, you can roll back the update. ESXi permits only one level of rollback. Only one previous build can be saved at a time. In effect, each ESXi 4.0 host stores up to two builds, one boot build and one standby build. When you manually boot into the standby build instead of the current boot build, an irreversible rollback occurs. The standby build becomes the new boot build and remains the boot build until you perform another patch, update, or upgrade.

Character Input Limitations

All fields in the vSphere Client and the vSphere Web Access interface support non-ASCII character input, except for the limitations listed below.

Non-ASCII Character Entry Limitations:

  • The name of the computer on which vSphere 4.0 components are installed must not contain non-ASCII characters.
  • The name of the computer or virtual machine where vCenter Server is installed must not have a non-ASCII computer name or the installation of vCenter Server will fail.
  • Use the default installation path names specified in the installer for all the components. Do not change the install path, because the installer does not support 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.
  • Logging in to the vCenter Server is supported only for user names with ASCII characters (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.
  • In accordance with general Internet protocols, the following cannot contain non-ASCII characters: host names, workgroup names, domain names, URLs, email addresses, SMTP server names, and SNMP community string.
  • Guest operating system customizations using 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, user name, or password, vCenter Server, and the sysprep tool must be hosted in the same locale as that of the guest operating system. This limitation includes UTF-8 encoded answer files.

Non-ASCII Character Display Limitations:

  • When managing a vCenter Server with the vSphere Client running on different languages of Windows, some characters might be 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 is not displayed correctly in the localized environment.

New USB Pass-Through for Virtual Machines

Although you can add USB controllers to virtual machines, attaching USB devices is not supported.

List of Known Issues

The following issues are known to occur. The list of issues below pertains to this release of vSphere 4.0 only. The known issues are grouped as follows:

Installation Issues
  • Installation or upgrade of vCenter Server 4.0 might fail with disk space error

    During installation of vCenter Server 4.0, when you provide the amount of free space estimated by the installer, the installation might fail and issue a Not enough disk space error message. As a result, you might have to rerun the installation.

    Workaround: Provide at least 1GB of free space in addition to the amount recommended by the installer.

  • The vCenter Server installer cannot detect service ports if the services are not running

    When you install vCenter Server and accept the default ports, if those ports are being used by services that are not running, the installer cannot validate the ports. The installation fails, and an error message might appear, depending on which port is in use.

    This problem does not affect IIS services. IIS services are correctly validated, regardless of whether the services are running.

    Workaround: Verify which ports are being used for services that are not running before beginning the installation and avoid using those ports.

  • vCenter Server service might not start if vCenter Server is installed as a local system account on a local Microsoft SQL Server database with Integrated Windows NT Authentication

    If you install an instance of vCenter Server as a local system account on a local SQL Server database with Integrated Windows NT Authentication and then add an Integrated Windows NT Authentication user to the local database server with the same default database as vCenter Server, vCenter Server might not start.

    Workaround: Remove the Integrated Windows NT Authentication user from the local SQL database server. Alternatively, change the default database for the local system user account to the vCenter Server database for the SQL Server user account setup.

  • vCenter Server installer reports incorrect warning message during an installation or upgrade

    During installation or upgrade, the vCenter Server installer reports a warning message to enable TCP/IP and named pipes for remote connections. This message is reported if you use a local SQL Server database and enter the server name something other than (local) and "." when you create DSN.

    Workaround: Ignore the warning and click OK to continue the installation or upgrade.

  • The ESX/ESXi installer lists local SAS storage devices in the Remote Storage section

    When displaying storage locations for ESX or ESXi Installable to be installed on, the installer lists a local SAS storage device in the Remote Storage section. This happens because ESX/ESXi cannot determine whether the SAS storage device is local or remote and always treats it as remote.

    Workaround: None

  • vCenter Server installation on Windows Server 2008 with a remote SQL Server database fails in some circumstances

    If you install vCenter Server on Windows 2008, using a remote SQL Server database with Windows authentication for SQL Server, and a domain user for the DSN that is different from the vCenter Server system login, the installation does not proceed and the installer displays the following error message:

    25003.Setup failed to create the vCenter repository.

    Workaround: In these circumstances, use the same login credentials for vCenter Server and for the SQL Server DSN.

  • vCenter Server installation fails on Windows Server 2008 when using a nonsystem user account

    When you specify a non-system user during installation, vCenter Server installation fails with the following error message:

    Failure to create vCenter repository

    Workaround: On the system where vCenter Server is being installed, turn off the User Account Control option under Control Panel > User Accounts before you install vCenter Server. Specify the non-system user during vCenter Server installation.

  • Uninstalling the vSphere Client leaves behind empty directories

    When you uninstall the vSphere Client, empty directories remain.

    Workaround: Navigate to the installation directory and delete the Virtual Infrastructure Client directory.

  • vSphere Client 4.0 download times out with an error message when you connect VI Client 2.0.x on a Windows 2003 machine to vCenter Server or an ESX/ESXi host

    If you connect a VI Client 2.0.x instance to vCenter Server 4.0 or an ESX/ESXi 4.0 host, vSphere Client 4.0 is automatically downloaded onto the Windows machine where the VI Client resides. This operation relies on Internet Explorer to perform this download. By default, Internet Explorer on Windows 2003 systems blocks the download if the VI Client instance is VI Client 2.0.x.

    Workaround: In Internet Explorer, select Tools > Internet Options > Advanced and uncheck the option Do not save encrypted pages to disk. Alternatively, download and install vSphere Client 4.0 manually from vCenter Server 4.0, the ESX/ESXi 4.0 host, or the RC Communities Web page.

  • Cannot reinstall or uninstall product after terminating the uninstallation of vSphere Client 4.0

    If vSphere Client installation is interrupted, a subsequent installation or uninstallation of the vSphere Client 4.0 results in the following error message:

    Error applying transforms. Verify that the specified transform paths are valid.

    Workaround: Use the Windows Installer Cleanup to uninstall vSphere Client 4.0.

  • Cannot log in to VirtualCenter Server 2.5 after installing VI Client 2.0.x, 2.5, and vSphere Client 4.0 and then uninstalling VI Client 2.0.x on a Windows Vista system

    After you uninstall the VI Client 2.0.x on a Windows Vista machine where the VI Client 2.0.x, 2.5, and the vSphere Client 4.0 coexist, you cannot log in to vCenter Server 2.5. Log-in fails with the following message:

    Class not registered(Exception from HRESULT:0x80040154(REGDB_E_CLASSNOTREG))

    Workaround: Disable the User Account Control setting on the system where VI Client 2.0.x, 2.5, and vSphere Client 4.0 coexist or uninstall and reinstall VI Client 2.5.

  • If SQL Native Client is already installed, you cannot install vCenter with the bundled SQL Server 2005 Express database

    When you are installing vCenter with the bundled SQL Server 2005 Express database, if SQL Native Client is already installed, the installation fails with the following error message: An Installation package for the product Microsoft SQL Native Client cannot be found. Try the installation using a valid copy of the installation package sqlcli.msi.

    Workaround: Uninstall SQL Native Client if it is not used by another application. Then, install vCenter with the bundled SQL Server 2005 Express database.

  • vSphere Client installation might fail with Error 1603 if you do not have an active Internet connection
    You can install the vSphere Client in two ways: from the vCenter Server media or by clicking a link on the ESX, ESXi, or vCenter Server Welcome screen. The installer on the vCenter Server media (.iso file or .zip file) is self-contained, including a full .NET installer in addition to the vSphere Client installer. The installer called through the Welcome screen includes a vSphere Client installer that makes a call to the Web to get .NET installer components.

    If you do not have an Internet connection, the second vSphere Client installation method will fail with Error 1603 unless you already have .NET 3.0 SP1 installed on your system.

    Workaround: Establish an Internet connection before attempting the download, install the vSphere Client from the vCenter Server media, or install .NET 3.0 SP1 before clicking the link on the Welcome screen.

  • A minimum of 650MB of free space on the boot drive is required to install vCenter Server

    Although vCenter Server itself does not need to be installed on the boot drive, some required components must be installed on the boot drive. 650MB of free space is required at installation time to accommodate these required components as well as temporary files used during the installation.

    Workaround: Ensure that you have at least 650MB of free space on the boot drive before installing vCenter Server.

  • ESXi installation might fail on IBM x336 machines

    On some IBM x336 machines, the ESXi installation process might stop. This is caused by a bug in the machine's BIOS.

    Workaround: Update the machine's BIOS to version 1.15 prior to installing ESXi Installable.

  • During installation, VMware ESXi Installable does not automatically create a VMFS partition on certain local SAS hardware storage devices

    By default, VMware ESXi partitions occupy the remainder of the installation media disk to create a VMFS volume. Certain SAS hardware storage devices, although installed directly on the host, present themselves as remote storage devices. As a result, ESXi Installable does not create the VMFS volume on this type of device. After the installation process, the remainder of the SAS storage device remains empty.

    Workaround: Create a VMFS datastore manually using vSphere Client by completing the following steps:

    1. Open the vSphere Client and select the ESXi Installable host from the inventory.
    2. Click Storage on the Configuration tab.
    3. Click Add Storage and step through the Add Storage Wizard to create a VMFS partition on the SAS storage volume.

Upgrade Issues
  • Default alarms new with vCenter Server 4.0 are not added to the system during upgrade

    When upgrading to vCenter Server 4.0, the default alarms that are new with 4.0 are not added to the system. The following is a list of missing default alarms:

    HostConnectionStateAlarm
    VmFaultToleranceLatencyStatusAlarm
    HostEsxCosSwapAlarm
    VmDiskLatencyAlarm
    DatastoreDiskUsageAlarm
    LicenseNonComplianceAlarm
    VmTimedoutStartingSecondaryAlarm
    VmNoCompatibleHostForSecondaryAlarm
    HostErrorAlarm
    VmErrorAlarm
    HostConnectivityAlarm
    NetworkConnectivityAlarm
    StorageConnectivityAlarm
    MigrationErrorAlarm
    ExitStandbyErrorAlarm
    VmHighAvailabilityError
    HighAvailabilityError
    LicenseError
    HealthStatusChangedAlarm
    VmFaultToleranceStateChangedAlarm

    Workaround: See VMware Knowledge Base article 1010399 for information on a script that adds the new default alarms to the system.

  • Updated Servers shipped with ESX Server 3i Embedded 3.5 cannot be upgraded to ESXi 4.0 Embedded

    When you attempt to upgrade a server with ESX Server 3i Embedded 3.5 installed on an internal USB, the following error occurs during the upgrade:
    Unsupported boot disk. The boot device layout on the host will not support the upgrade.

    Workaround: If upgrading the server with ESX Server 3i Embedded 3.5 is not required immediately, delay the upgrade until a patch is available for ESXi 4.0 Embedded.

    If upgrading the server with ESX Server 3i Embedded 3.5 is required immediately, use the factory recovery CD to flash the server with ESXi 4.0.

    Warning: This will remove all system configuration settings.

  • The upgrade to ESXi 4.0 fails if ESXi Embedded and ESXi Installable are both on the machine

    If you have ESXi Installable installed on the local disk and you boot the machine with ESXi Embedded, and then you try to upgrade to ESXi 4.0, the upgrade fails.

    Workaround: ESXi Embedded and ESXi Installable cannot co-exist in the same machine. If you choose to remove ESXi Installable and only use ESXi Embedded, follow the steps below.

    1. Make sure you can boot the machine from the ESX Embedded USB flash device.
    2. Copy the virtual machines from the ESXi Installable VMFS datastore to the ESXi Embedded VMFS datastore.
    3. Remove the ESXi Installable VMFS datastores on the internal disks so that the internal disks are no longer set up to store virtual machines.
    4. Reboot the machine and configure the boot setting to boot from the USB flash device.

    If you choose to remove ESXi Embedded and only use ESXi Installable, follow the steps below.

    1. Install ESXi Installable on the machine's hard disk
    2. Copy virtual machines from the ESXi Embedded VMFS datastore to the ESXi Installable VMFS datastore.
    3. Reboot the machine and configure the boot setting to boot from the hard disk where you installed ESXi rather than the USB disk.
    4. If you can remove the ESXi Embedded USB device, remove it. If the USB device is internal, clear or overwrite the USB partitions.

  • The vCenter Server system's Database Upgrade wizard might overestimate the disk space requirement during an upgrade from VirtualCenter 2.0.x to vCenter Server 4.0

    During the upgrade of VirtualCenter 2.0.x to vCenter Server 4.0, the Database Upgrade wizard might show an incorrect value in the database disk space estimation. The estimation shown is typically higher than the actual space required.

    Workaround: None

  • Opening performance charts after an upgrade results in an error message

    After you perform an upgrade using the Microsoft SQL Express edition database, the vSphere Client displays the error message Perf Charts service experienced an internal error when you open performance charts. This happens because the installer does not restart the database service after making changes in the database settings.

    Workaround: Perform the following steps:

    1. Stop the VMware VirtualCenter Server service in Windows.
    2. Restart the database service.
    3. Start the VMware VirtualCenter Server service.
    4. Open a new vSphere Client instance and log into vCenter Server.

  • ESX Server 2.5 virtual machines with non-persistent disks upgraded to ESX 4.0 might enter a suspended state

    When you upgrade the virtual hardware of an ESX Server 2.5 virtual machine with non-persistent disks (identifiable by config version = 6, hardware version = 3) in ESX 4.0, the virtual machine will be incorrectly set to autorevert. If you take snapshots on this virtual machine (identifiable by config version = 8, hardware version = 7) in ESX 4.0, the virtual machine might enter a suspended state while reconfiguring its virtual hardware devices in the powered-off state.

    Workaround: Remove the entry snapshot.action = "autoRevert" from the configuration file manually after you upgrade the virtual machine.

  • vSphere Host Update Utility references wrong patch information when a proxy is configured in settings.xml

    This problem occurs on ESXi when a proxy is configured in the settings.xml file, and when VIB files are updated since the last scan with new information. Under these conditions, vSphere Host Update Utility uses the old information from the proxy cache and reports that scanned hosts are up-to-date.

    Workaround: To update the information used by the Host Update Utility, complete the following tasks:
    • Clear the proxy server cache.
    • Restart the vSphere Host Update Utility.
    • Rescan hosts.

  • The vmxnet driver is not installed automatically when you install or upgrade VMware Tools

    When you install or upgrade VMware Tools on a virtual machine running the Windows NT guest operating system, the vmxnet driver is not installed automatically.

    Workaround: Install the vmxnet driver manually. To do this, perform the following steps:

    1. Log in to the virtual machine and right-click Network Neighborhood.
    2. Click Properties and select the Adapters tab.
    3. Click Have Disk and enter the path to the driver:
      C:\Program Files\VMware\VMware Tools\Drivers\vmxnet\
    4. Reboot the virtual machine.
  • Incompatible legacy plug-ins appear as enabled in the vSphere Plug-in Manager after upgrading to vCenter Server 4.0

    If you have VirtualCenter 2.5 installed with VMware Update Manager 1.0 or VMware Converter Enterprise for VirtualCenter 2.5, and you upgrade to vCenter Server 4.0, the legacy plug-ins appear as installed and enabled in the vSphere Client Plug-in Manager. However, earlier versions of the plug-in modules are not compatible with vCenter Server 4.0. In such cases, the plug-ins might be available, but are not functional.

    Workaround: Upgrade VMware Update Manager to VMware vCenter Update Manager 4.0 and VMware Converter Enterprise to VMware vCenter Converter (for vCenter Server 4.0), and then install and enable the plug-ins.

  • The Next run time value for some scheduled tasks is not preserved after you upgrade from VirtualCenter 2.0.2.x to vCenter Server 4.0

    If you upgrade from VirtualCenter 2.0.2.x to vCenter Server 4.0, the Next run time value for some scheduled tasks might not be preserved and the tasks might run unexpectedly. For example, if a task is scheduled to run at 10:00 am every day, it might run at 11:30 am after the upgrade.

    This problem occurs because of differences in the way that VirtualCenter 2.0.2.x and vCenter Server 4.0 calculate the next run time. You see this behavior only when the following conditions exist:

    • You have scheduled tasks, for which you edited the run time after the tasks were initially scheduled so that they now have a different Next run time.
    • The newly scheduled Next run time has not yet occurred.

    Workaround: Perform the following steps:

    1. Wait for the tasks to run at their scheduled Next run time before upgrading.
    2. After you upgrade from vCenter 2.0.x to vCenter Server 4.0, edit and save the scheduled task. This process recalculates the Next run time of the task to its correct value.

  • When vSphere Client 4.0 and VI Client 2.5 are installed on the same system, depending on the order in which you uninstall the applications, the desktop shortcut is not updated

    If you install the vSphere Client 4.0 application on a system that includes an instance of the VI Client 2.5 application, only the vSphere Client 4.0 desktop shortcut appears on the desktop. You can launch both applications from the shortcut.

    However, if you uninstall the vSphere Client 4.0 application but do not uninstall the VI Client 2.5 application, the vSphere Client 4.0 desktop shortcut remains on the system. You can continue to use the shortcut to log in to VI Client 2.5, but if you attempt to log in to vSphere Client 4.0, you are prompted to download the application.

    Workaround: Perform one of the following steps:

    • If you uninstall only the vSphere Client 4.0 application, rename the desktop shortcut or reinstall the VI Client 2.5 application so that the link will correctly reflect the installed client.
    • If you uninstall both applications, remove any nonworking shortcuts.

  • Upgrading the hardware version of Windows virtual machines might require driver updates

    Upgrading the hardware version of a Windows virtual machine to hardware version 7 on an ESX 4.0 host will cause the Flexible network adapter to incorrectly use the AMD PCNet family PCI Ethernet adapter (pcnetpci5.sys) driver and have 10Mbps speed. The correct driver is the VMware Accelerated AMD PCNet Adapter (vmxnet.sys) driver.

    Workaround: Manually update the driver for the Flexible NIC to the VMware Accelerated AMD PCnet Adapter (vmxnet.sys) driver by pointing to C:\Program Files\VMware\VMware Tools\Drivers\vmware-nic.inf from the virtual machine Windows guest.

  • vCenter Server database upgrade fails for Oracle 10gR2 database with certain user privileges

    If you upgrade VirtualCenter Server 2.x to vCenter Server version 4.0 and you have connect, create view, create any sequence, create any table, and execute on dbms_lock privileges on the database (Oracle 10gR2), the database upgrade fails. The VCDatabaseUpgrade.log file shows following error:
    Error: Failed to execute SQL procedure. Got exception: ERROR [HY000] [Oracle][ODBC][Ora]ORA-01536: space quota exceeded for tablespace 'USERS'

    Workaround: As database administrator, enlarge the user table space or grant the "unlimited tablespace" privilege to the user who performs the upgrade.

  • If vSphere Host Update Utility loses its network connection to the ESX/ESXi host, the host upgrade might not work

    If you use vSphere Host Update Utility to perform an ESX/ESXi host upgrade and the utility loses its network connection to the host, the host might not be completely upgraded. When this happens, the utility might stop, or you might see the following error message: Failed to run compatibility check on the host.

    Workaround: Close the utility, fix the network connection, restart the utility, and rerun the upgrade.

  • Virtual machine hardware upgrades from version 4 to version 7 cause Solaris guests lose their network settings

    Virtual machine hardware upgrades from version 4 to version 7 changes the PCI bus location of virtual network adapters in guests. Solaris does not detect the adapters and changes the numbering of its network interfaces (for example, e1000g0 becomes e1000g1). This numbering change occurs because Solaris IP settings are associated with interface names, so it appears that the network settings have been lost and the guest is likely not to have proper connectivity.

    Workaround: Determine the new interface names after the virtual machine hardware upgrade by using the prtconf -D command, and then rename all the old configuration files to their new names. For example, e1000g0 might become e1000g1, so every /etc/*e1000g0 file should be renamed to its /etc/*e1000g1 equivalent.

  • vSphere Client fails with Microsoft Visual C++ Runtime Library error

    In environments that include vSphere 4.0 components, VI Client version 2.5, and VMware vCenter Converter, the vSphere Client might fail with a Microsoft Visual C++ Runtime Library runtime exception.

    Workaround: Delete libeay32.dll and ssleay32.dll located at the following path:
    C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher
    Alternatively, uninstall VI Client version 2.5.

Licensing Issues
  • A host with a single server license that fails to be added to vCenter Server is not given the option to correct licensing during a subsequent add host operation

    When an ESX or ESXi host configured with a single server license is added to a licensed vCenter server, vCenter Server displays an error message explaining that the host cannot be added.

    Workaround: Remove the disconnected host, and add it again with a non-single server license.

  • Virtual machines cannot power on if certain licenses are installed during a scripted or interactive installation

    If you do not have the correct license serial numbers for your hardware, when you install ESX/ESXi, you might encounter a licensing error. This problem is seen because the vendor and resource check validation of license keys is not performed during the installation. After a license is validated with lib/licensecheck, a subsequent test is needed to check that the system installed is within the limits imposed by the license. However, the installer does not perform this second check.

    Workaround: Switch to evaluation mode, and then get the appropriate license from the portal.

  • Virtual Machine with multi-way virtual SMP support might fail to start and might report a license failure immediately after upgrading a host's license

    Immediately after upgrading the license for a host, vCenter Server fails to power on virtual machine. For example, if you upgrade from an edition that supports 4 vCPU to an edition supporting 8 vCPU, vCenter Server reports a license failure such as: machine has 8 virtual cpus, but host only supports 4....

    Workaround: For the license upgrade to take effect, wait at least one minute before you power on virtual machines. To manually initiate the license change, go to Home > Licensing and click Refresh.

  • Purchased add-on licenses are not displayed in the License list on the vSphere Client Licensing page

    When you view your purchased licenses on the vSphere Client Licensing page, a separate product line item for add-on editions is not displayed. For example, if you purchased a vSphere 4.0 Standard with VMotion license, or a vSphere 4.0 Standard with VMotion and Data Recovery license, only the vSphere 4.0 Standard license appears.

    Workaround: To view the product features and add-on features for a license key, follow these steps:

    1. On the vSphere Home page, click Licensing.
    2. In the upper-right corner, click Manage vSphere Licenses to launch the License wizard.
    3. Click Next to go to the Assign Licenses page.
    4. Move your cursor over the host license key to see the available product and add-on features.

Networking Issues
  • New The console for the guest operating system fails and you cannot access the guest through the console if you set MTU to less than 1500 for a vNetwork Distributed Switch or a vSwitch that has the service console port group or the management network port group

    If you set the MTU for the vNetwork Distributed Switch or the vSwitch that includes the service console port group for ESX or the Management Network port group for ESXi Embedded to less than 1500, the console for the guest operating system fails and you cannot access the guest through the console. The service console port group for ESX and the management network port group for ESXi Embedded must be connected to a vSwitch or vNetwork Distributed Switch with an MTU set to 1500 or higher.

    Workaround: Avoid setting the MTU value less than 1500 for the vNetwork Distributed Switch or the vSwitch that includes the service console port group for ESX or the Management Network port group for ESXi Embedded.

  • For VMDirectPath Gen I, sharing a dual-function QLogic 2532 adapter between a virtual machine and either another virtual machine or the VMkernel might result in data corruption

    When you configure a dual-function QLogic 2532 adapter for VMDirectPath IO, and assign the first PCI function to a virtual machine and the second to either the VMkernel or another virtual machine, data corruption might occur. This happens because both ports use the same credentials to log in to the fabric and have the same storage visibility. VMware does not support this configuration for VMDirectPath IO.

    Workaround: If you cannot avoid sharing the dual-function adapter between a virtual machine and the VMkernel, assign the first PCI function to the virtual machine and the second to the VMkernel. The PCI functions cannot be split between two virtual machines.

  • Applying port groups with multiple statically assigned VMKNICs or VSWIFs results in repeated prompts for an IP address

    Applying a vDS portgroup with multiple statically assigned VMKNICs or VSWIFs causes a situation in which the user is repeatedly prompted to enter an IP address. DHCP assigned interfaces are not affected.

    Workaround: Use only one statically assigned VMKNIC or VSWIF per portgroup. If multiple statically assigned VMKNICs are desired on the same vDS portgroup, then assign each VMKNIC or VSWIF to a unique set of services (for example, VMotion, Fault Tolerance, and other services).

  • The VmwVmNetNum of VM-INFO MIB displays as Ethernet0 when running snmpwalk

    When snmpwalk is run for VM-INFO MIB on an ESX/ESXi host, the VmwVmNetNum of VM-INFO MIB is displayed as Ethernet0 instead of Network Adapter1 while the MOB URL in the VmwVmNetNum of VM-INFO description displays as Network Adapter1.

    Workaround: None

  • Applications that use VMCI Sockets might fail after virtual machine migration

    If you have applications that use Virtual Machine Communication Interface (VMCI) Sockets, the applications might fail after virtual machine migration if the VMCI context identifiers used by the application are already in use on the destination host. In this case, VMCI stream or Datagram sockets that were created on the originating host stop functioning properly. It also becomes impossible to create new stream sockets.

    Workaround: For Windows guest operating systems, reload the guest VMCI driver by rebooting the guest operating system or enabling the device through the device manager. For Linux guests, shut down applications that use VMCI Sockets, remove and reload the vsock kernel module and restart the applications.

  • VMware Distributed Power Management (DPM) fails to wake a host from standby when the host is configured using Wake-On-LAN and a NetXen NIC for its VMotion network

    The driver for NetXen NICs (nx_nic) that is included in this release advertises Wake-on-LAN support for all NetXen NICs, but the Wake-on-LAN feature does not work on most NICs when using this version of the driver. The only NetXen NIC for which Wake-on-LAN is known to work with this driver is the NetXen HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter, commonly found in the HP ProLiant ML370 G6. Because the driver advertises Wake-on-LAN support for other NetXen NICs as well, DPM is unaware that the support does not work for those NICs and will attempt to use it if configured to do so.

    Workaround: If the host has support for IPMI or iLO as a wake protocol, configure DPM to use one of those protocols instead of Wake-on-LAN. Otherwise, install a NIC with working Wake-on-LAN support, or disable DPM on this host.

  • DPM cannot put a host in standby mode when the VMkernel VMotion NIC is part of a vDS and the host is configured to use Wake-on-LAN for remote power-on

    If a host's VMkernel VMotion NIC is part of a vDS, the NIC is configured to not support Wake-on-LAN. Therefore, unless the host is configured to use IPMI or iLO for remote power-on, it is considered incapable of remote power-on and DPM cannot automatically move it into standby mode. DPM selects other hosts to put into standby mode, if possible. If you attempt to put the host into standby mode manually, the attempt fails and an Enter Standby Stopped dialog box appears.

    Workaround: Use IPMI or iLO to power on hosts that support one of these protocols instead of Wake-on-LAN by configuring the IPMI or iLO credentials on each host. Alternatively, if you need to use Wake-on-LAN to power on hosts, configure the VMkernel VMotion interface on a vNetwork Standard Switch (vSwitch), rather than on a vDS.

  • Removing an ESX/ESXi host configured with a vDS from a vCenter Server system results in inconsistent networking state on the host

    If you remove an ESX/ESXi host configured with a vDS from a vCenter Server system, the host cannot reconnect to the vDS. When you add the host back to the vCenter Server system, a warning similar to the following appears:

    The distributed Virtual Switch corresponding to the proxy switches d5 6e 22 50 dd f2 94 7b-a6 1f b2 c2 e6 aa 0f bf on the host does not exist in vCenter or does not contain the host.

    The virtual machines continue to function on their respective ports, but new virtual machines are not allowed to power on. You cannot modify the vDS settings for this host by using a vSphere Client connected to the vCenter Server system.

    Workaround: Perform the following steps:

    1. Use a vSphere Client to connect directly to the ESX/ESXi host. This workaround requires a direct connection.
    2. Migrate the virtual machines off of the invalid vDS ports one by one by editing the settings of each virtual machine. This will result in prolonged network interruption to the virtual machines.
    3. Choose Host > Configuration > Networking > Distributed Virtual Switch and click Remove.
    4. In a vSphere Client connected to the vCenter Server system, refresh the network settings of the host. The errors are cleared.
    5. Add the host back to the vDS, either manually or by using a host profile.
    6. Migrate the virtual machines back to their respective ports or portgroups on the vDS. To do so, right-click the vDS and choose Migrate Virtual Machine Networking. This process also results in network interruption to the virtual machines.

  • ESX 4.0/ESXi 4.0 does not support configuring port binding with DVS-enabled VMkernel NICs

    If you configure port binding with vNetwork Distributed Switch-enabled VMkernel NICs, the operation fails if you enter the esxcli swiscsi nic add -n vmkx -d vmhbaxx and vmkiscsi-tool -V -a vmkx vmhbaxx commands through the service console or the vSphere CLI.

    Workaround: Only use legacy vSwitch VMkernel NICs for port binding.

  • Removing a virtual machine from the inventory might fail if the virtual machine is associated with an invalid vNetwork Distributed Switch

    If a virtual machine is connected to an invalid vNetwork Distributed Switch, attempting to remove it from the inventory results in a NotFound exception. This problem occurs when you perform the following steps:

    1. Disconnect a host that is a member of a vNetwork Distributed Switch.
    2. Remove the host from the vNetwork Distributed Switch or the vSphere Client inventory.
    3. Reconnect the host or add the host back to vSphere Client inventory.
    4. Remove the virtual machine from the vSphere Client inventory.

    Workaround: Perform one of the following tasks before removing the virtual machine from the inventory:

    • If the vNetwork Switch still exists, reconnect the host to it to make the device backing valid.
    • Reconfigure the virtual machine's vNIC to connect to a valid network.
    • Remove the vNic from the virtual machine.

  • VLAN tagging does not work in SLES10 guest operating systems when Oplin NIC is used in passthrough mode (FPT)

    This issue occurs when an Oplin 10GB adapter is assigned to a virtual machine running the SUSE Enterprise Linux 10 (SLES10) 32-bit or 64-bit guest operating system as an FPT (fixed passthrough) device and the guest operating system is configured to perform VLAN tagging. In such a case, TCP traffic deteriorates and a call to netperf terminates prematurely with an error message. ICMP traffic still goes through and you can ping.

    Workaround: Run tcpdump while the TCP traffic is active. Running tcpdump puts the NIC in promiscuous mode, which ensures that the traffic flows properly but consumes a high number of CPU cycles on the guest operating system.

Storage Issues
  • ESX/ESXi might fail to discover second port on certain IBM servers with dual-port FC HBAs

    When you use IBM x3650 servers with dual-port FC HBAs, ESX/ESXi might fail to discover the second port. This problem can possibly happen on other IBM servers with the same version of BIOS.

    Workaround: Depending on the type of adapter your server has, do one of the following:

    • For QLogic HBAs, upgrade the IBM BIOS to the latest BIOS version (version 1.2).
    • For Emulex HBAs the following solutions exist:
      • If you use ESX booting from SAN, disable the local disk in IBM server's BIOS.
      • If you use ESX booting from the local disk or ESXi, disable BootBIOS for both ports on the Emulex HBA.

  • vCenter Server fails to open RDM after the RDM’s LUN number changes

    VMware does not support LUN number (position) changes within the target. When the LUN number changes vCenter Server fails to open the RDM that is built on that LUN. A raw device mapping file (RDM) resides on the VMFS datastore and points to a LUN. The LUN number shows the position of the LUN within the target. When this number (or position) changes, the vml identifier (vml_ID) for the RDM file also changes. For example, you can’t disconnect VMFS datastores and reconnect them in a different order. This changes the identification of the LUN so that it is no longer accessible and vCenter Server prevents the virtual machine from powering on. vSphere Client uses the vml_ID for backward compatibility.

    Workaround: Remove the RDM and re-create it. This generates a new vml_ID that the LUN can recognize.

  • The size of virtual RDMs with snapshots cannot be expanded

    When you increase the size of an underlying LUN for a virtual machine with a virtual RDM attached, the size is not updated. You cannot expand the size of virtual RDMs that are independent and nonpersistent, and/or virtual RDMs with snapshot(s). This type of disk is read-only inside the VMkernel and metadata updates are not performed on them. Therefore, the virtual machine will not see the new size of the LUN.

    Workaround: None

  • vmfs-undelete utility is not available for ESX/ESXi 4.0

    ESX/ESXi 3.5 Update 3 included a utility called vmfs-undelete, which could be used to recover deleted .vmdk files. This utility is not available with ESX/ESXi 4.0.

    Workaround: None. Deleted .vmdk files cannot be recovered.

  • Path for a device cannot be unclaimed after you disable autoclaiming

    You cannot unclaim a path for a device after you set the autoclaiming option to Off/Disabled.

    Workaround: The autoclaiming option is not supported in ESX/ESXi 4.0.

  • Storage VMotion failure mode can result in power off of virtual machine

    When Storage VMotion is used on an ESX/ESXi 4.0 host, if moving the data fails due to a transient error (for example: out of memory), StorageVMotion might not complete successfully, migration performance may degrade, or the source virtual machine may power off.

    Workaround: Power on the virtual machine.

  • If ESX/ESXi hosts fail or reboot during Storage VMotion, the operation can fail and virtual machines might become orphaned

    If hosts fail or reboot during Storage VMotion, the VMotion operation can fail. The destination virtual machine's virtual disks might show up as orphaned in the vSphere inventory after the host reboots. Typically, the virtual machine's state is preserved before the host shuts down.

    If the virtual machine does not show up in an orphaned state, check to see if the destination VMDK files exist.

    Workaround: You can manually delete the orphaned destination virtual machine from the vSphere inventory. Locate and delete any remaining orphaned destination disks if they exist on the datastore.

  • Using Storage VMotion to relocate a virtual machine back to its source volume might result in an insufficient disk space error

    When you use Storage VMotion to move a virtual machine to another datastore and then back to its source volume, the vSphere Client does not immediately refresh the size of the source datastore, resulting in an error.

    Workaround: Refresh the datastore in the vSphere Client. If the reported size of the datastore does not change after one attempt, wait for 30 minutes and refresh again.

  • Setting VMkernel:Boot.storageHeapMaxSize to a value of 2147483647 or higher can cause a non-responsive server

    If you use the Advanced Settings dialog box on the vSphere Client Configuration tab to set the VMkernel:Boot.storageHeapMaxSize option to a value of 2147483647 or higher, the ESX/ESXi host will fail with a purple screen after you reboot it.

    Workaround: Set the VMkernel:Boot.storageHeapMaxSize option to a value less than 2147483647.

  • Storage VMotion of NFS volume may be overriden by NFS server disk format

    When you use Storage VMotion to migrate a virtual disk to an NFS volume or perform other virtual machine provisioning that involves NFS volumes, the disk format is determined by the NFS server where the destination NFS volume resides. This overrides any selection you made in the Disk Format menu.

    Workaround: None

  • Storage VMotion does not support source RDM conversion to target NFS volumes

    Disk-only Storage VMotion fails for virtual mode RDMs when you convert the disks to flat/sparse format on NFS volumes.

    Workaround: Perform the following steps to migrate virtual mode RDMs to NFS volumes:

    1. Use Storage VMotion to convert an RDM virtual machine disk to disk type flat/sparse using intermediate an SAN, local, or iSCSI volume.
    2. Use Storage VMotion to relocate the converted disks from the SAN, local, or iSCSI volume to an NFS volume.

  • VMFS2 datastores are not visible on an ESXi host after booting

    When you use IPv4 with DHCP, if the DHCP connection is slow, the ESXi host might not be able to display VMFS2 volumes after it boots.

    Workaround: Update the list of datastores on your host from the vSphere Client by performing the rescan operation and selecting the Scan for New VMFS Volumes option. Alternatively, you can assign a static IP address to the host instead of using the DHCP.

  • Storage VMotion of thick to thin virtual disk fails

    Migrating virtual machines configured with the VMFS maximum filesystem limit report the following error: File[vol] <vmpath> is larger than the maximum size supported by datastore <destination datastore>.

    Workaround: None. Do not configure a virtual machine disk to its maximum volume limit if you plan to migrate the virtual machine.

  • When installing ESXi Installable hosts on a LUN on network storage, only one ESXi host boots from that image and booting from the LUN fails for additional ESXi hosts

    Host configuration files are stored in the same LUN where the host image resides and have a one to one mapping relationship. Therefore, each host requires a unique LUN for booting ESXi from network storage. Multiple hosts may not be booted from the same LUN.

    Note: Network booting is an experimental feature for ESXi.

    Workaround: Create a unique LUN per host with a boot image for each host.

  • vSphere Client displays drive fault alerts when the drive is not present on ESX and ESXi hosts with multi-node IBM systems

    On some multi-node IBM systems, the BMC firmware reports a drive fault for drive slots when no drive is present. The vSphere Client reports the Drive Fault sensor as being in an Alert state. The same faults are shown in the IBM iLOM interface.

    Workaround: None. A defect report is filed with IBM to address this issue.

  • ESX/ESXi 4.0 does not support HP Enterprise Virtual Arrays with Egenera BladeFrame BF400S2

    When you try to install ESX/ESXi 4.0 on a Egenera BF400S2 BladeFrame that boots from HP EVA series arrays, the installation fails and an error message appears stating that no disks are found. This happens because the installer does not recognize the disks that are presented through the Egenera BF400S2 BladeFrame. HP EVA with Egenera BF400S2 is not supported.

    Workaround: None

  • NAS datastores report incorrect available space

    When you view the available space for an ESX/ESXi host by using the df (ESXi) or vdf (ESX) command in the host service console, the space reported for ESX/ESXi NAS datastores is free space, not available space. The space reported for NFS volumes in the Free column when you select Storage > Datastores on the vSphere Client Configuration tab, also reports free space, and not the available space. In both cases, free space can be different from available space.

    ESX file systems do not distinguish between free blocks and available blocks, but always report free blocks for both block types (specifically, f_bfree and f_bavail fields of struct statfs). For NFS volumes, free blocks and available might can be different.

    Workaround: You can check NFS servers to get correct information regarding available space. No workarounds are available for ESX/ESXi.

  • Adding a QLogic iSCSI adapter to an ESX/ESXi system fails if an existing target with the same name but a different IP address exists

    Adding a static target for QLogic hardware iSCSI adapter fails if there is existing target with same iSCSI name, even if the IP address is different.

    You can add a QLogic iSCSI adapter to an ESX/ESXi system only with a unique iSCSI name for a target, not the combination of IP and iSCSI name. In addition, the driver and firmware do not support multiple sessions to the same storage end point.

    Workaround: None. Do not use the same iSCSI name when you add targets.

  • On rare occasions, after repeated SAN path failovers, operations that involve VMFS changes might fail for all ESX/ESXi hosts accessing a particular LUN

    On rare occasions, after repeated path failovers to a particular SAN LUN, attempts to perform such operations as VMFS datastore creation, VMotion, and so on might fail on all ESX/ESXi hosts accessing this LUN. The following warnings appear in the log files of all hosts:

    • I/O failed due to too many reservation conflicts.
    • Reservation error: SCSI reservation conflict

    If you see the reservation conflict messages on all hosts accessing the LUN, this indicates that the problem is caused by the SCSI reservations for the LUN that are not completely cleaned up.

    Workaround: None

  • Cannot perform port binding in conjunction with IPv6 ports

    Port binding is a mechanism of identifying certain VMkernel ports for use by the iSCSI storage stack. Port binding is necessary to enable storage multipathing policies, such as the VMware round-robin load-balancing, MRU, or fixed-path, to apply to iSCSI NIC ports and paths. Port binding does not work in combination with IPv6. When users configure port binding, they expect to see additional paths for each bound VMkernel NIC. However, when they configure the array under a IPv6 global scope address the additional paths are not established. Users only see paths established on the IPv6 routable VMkernel NIC. For instance, if users have two target portals and two VMkernel NICs, they see four paths when using IPv4 but see only two paths when using IPv6. Because there are no paths for failover, path policy setup does not make sense.

    Workaround: Use IPv4 and port binding, or configure the storage array and the ESX/ESXi host with LOCAL SCOPE IPv6 addresses on the same subnet (switch segment). You cannot currently use global scope IPv6 with port binding.

  • Changing the Maximum Outstanding R2T iSCSI parameter on your ESX/ESXi host to a value greater than one, might result in the EMC CX3 Series storage system not working properly

    If you change the default value of the Maximum Outstanding R2T iSCSI parameter on your ESX/ESXi host to a value grater than one, the EMC CX3 Series storage system might not work properly.

    Workaround: Do not change the default value of one for the Maximum Outstanding R2T parameter.

  • The path status for the CLARiiON iSCSI storage system changes from dead to active and from active to dead when the system is accessed through the ESX/ESXi software iSCSI initiator

    When you use the software iSCSI initiator to access a CLARiiON iSCSI storage system, the path status frequently changes from dead to active and from active to dead. This occurs because CLARiiON does not support the advanced Delayed Ack parameter enabled on your ESX/ESXi host by default.

    Workaround: Disable the Delayed Ack parameter on your ESX/ESXi host by performing the following steps:

    1. Log in to the vSphere Client, and select a host from the inventory panel.
    2. Click Configuration tab, and click Storage Adapters.
    3. Select the software iSCSI initiator to configure and click Properties.
    4. On the General tab, click Advanced.
    5. Deselect the Delayed Ack parameter.

  • Connecting to a tape library through an Adaptec card with aic79xx driver might cause ESXi to fail

    If your ESX/ESXi system is connected to a tape library with an Adaptec HBA (for example: AHA-39320A) that uses the aic79xx driver, you might encounter a server crash when the driver tries to access a freed memory area. Such a condition is accompanied by an error message similar to Loop 1 frame=0x4100c059f950 ip=0x418030a936d9 cr2=0x0 cr3=0x400b9000.

    Workaround: None

  • Updated When you use the PSP_RR path selection policy with Failover Clustering, shared disks experience problems and the cluster may not operate

    Failover Clustering conducts SCSI-3 reservations on shared disks. SCSI-3 registration sent down one path allows the cluster to do SCSI-3 reservations only on that path. When PSP_RR later switches to another path, Failover Clustering may be unable to do a reservation or use other SCSI-3 commands that depend on the reservation.

    Workaround: Do not switch devices used for shared disks to PSP_RR. Instead, use the PSP_MRU or PSP_FIXED policies depending on the normal default for the array.

  • Entering additional static discovery targets for hardware iSCSI might fail

    When you configure your hardware iSCSI adapter, an attempt to enter additional static discovery targets might fail. This occurs when a new target has the same iSCSI name as the existing one, even though their IP addresses are different.

    Workaround: When configuring hardware iSCSI, use static discovery targets with different iSCSI names.

  • The ESX/ESXi host does not register a path added from Storage Manager Application

    When you add a new port on a storage system using Storage Manager Application, your ESX/ESXi host does not display a new path to the storage system.

    Workaround: Perform the following steps:

    1. Make sure the port is accessible by the ESX/ESXi host.
    2. Remove the physical connection for the newly added port.
    3. Wait for the Device Delay Missing timer to expire.
    4. Reconnect the physical connection.

  • Booting from an iSCSI LUN might be too slow or fail

    If any iSCSI configuration data is present before you start configuring an iSCSI boot device through the QLogic BIOS, you can create duplicate iSCSI sessions for the same target. When this occurs, I/O operations might be very slow and might fail.

    Workaround: Perform the following steps:

    1. In the BIOS, select the Clear Persistent Targets option to remove any existing iSCSI configuration data.
    2. Add iSCSI boot configuration data.
Backup Issues
  • VMware Consolidated Backup (VCB) is not supported with Fault Tolerance

    A VCB backup performed on an FT-enabled virtual machine powers off both the primary and the secondary virtual machines and might render the virtual machines unusable.

    Workaround: None

  • Reverting to snapshot might not work if you cold migrate a virtual machine with a snapshot from an ESX/ESXi 3.5 host to an ESX/ESXi 4.0 host

    You can cold migrate a virtual machine with snapshots from an ESX/ESXi 3.5 host to ESX/ESXi 4.0 host. However, reverting to a snapshot after migration might not work.

    Workaround: No Workaround.

Server Configuration Issues
  • Host profiles do not capture or duplicate physical NIC duplex information

    When you create a new host profile, the physical NIC duplex information is not captured. This is the intended behavior. Therefore, when the reference host’s profile is used to configure other hosts, the operation negotiates the duplex configuration on a per physical NIC basis. This provides you with the capability to generically handle hosts with a variety of physical NIC capabilities.

    Workaround: To set the physical NIC duplex value uniformly across NICs and hosts that are to be configured using the reference host profile, modify the host profile after it is created and reapply the parameters.

    To edit the profile, follow the steps below.

    1. On the vSphere Client Home page, click Host Profiles.
    2. Select the host profile in the inventory list, then click the Summary tab and click Edit Profile.
    3. Select Network configuration > Physical NIC configuration > Edit.
    4. Select Fixed physical NIC configuration in the drop-down menu and enter the speed and duplex information.

  • SNMP PowerOn traps generated during vmware_hostd restart

    When you restart vmware_hostd, only the Warm Start trap message should be generated by default. However, for all virtual machines running on your host, the PowerOn trap messages are also generated.

    Workaround: You can ignore the PowerOn trap messages.

  • The health status of the ESX/ESXi host server components does not appear on the Hardware Status tab

    If you change the HTTPS port number in the SFCB configuration file (sfcb.cfg) to a port other than the default and restart the SFCB (CIM) server, the health status of the ESX/ESXi host server components does not appear on the Hardware Status tab. This behavior is also seen if you log directly in to an ESX/ESXi host and click the Configuration tab to view the health status. Status information for the server components does not appear. This problem occurs because vCenter Server and the SFCB server are communicating on different ports.

    Workaround: Make sure that the SFCB server communicates only through the default port.

vCenter and vSphere Client Issues
  • Snapshot deletion and virtual machine hot clone operations might take a long time when the virtual machine runs a heavy workload

    Deleting a snapshot or cloning a powered-on virtual machine might take a long time to complete when the virtual machine is running a heavy input/output workload. For example, when the virtual machine writes to its local disks, the input/output load is very heavy.

    Workaround: Avoid these operations when the virtual machine is writing to its local disks or issuing any other heavy input/output workloads. This can help to reduce the completion time.

  • Using the vSphere Client Delete All option to remove virtual machine snapshots might leave the snapshot disk files in the virtual machine folder

    This behavior occurs only when you previously used the snapshot to create linked clones and then deleted them from the vCenter Server. If you now attempt to remove the snapshot using the Snapshot Manager’s Delete All option, the snapshot is deleted. However, the snapshot disk is not consolidated with the parent disk and is left undeleted in the virtual machine folder.

    Workaround: Instead of using the "Delete All" option, use the "Delete" option to remove the snapshot./p>

  • For large vCenter Server inventories, when you open the vSphere Client in Linked Mode with the inventories of all vCenter Server systems fully expanded, the vSphere Client might be nonresponsive for several minutes

    Fully expanded vSphere Client inventories are those with clusters and datacenters expanded. If you close the vSphere Client after fully expanding the inventories, the next time you open it, the expanded inventory view is loaded. As a result, the vSphere Client might become nonresponsive for several minutes, depending on the number of vCenter Server systems and the number of objects in each vCenter Server system's inventory. The vSphere Client will start responding after it loads all inventory objects.

    Workaround: As a best practice, do not to expand the nodes of every vCenter Server system in the inventory of a Linked Mode group. Collapse the nodes before you close the vSphere Client to avoid loading the expanded nodes at start-up.

  • When you run the Linked Mode Configuration Wizard after linking a vCenter Server system to a group in a pure IPv6 environment, there is no option to isolate the vCenter Server system from Linked Mode

    If vCenter Server is linked in a pure IPv6 environment (Windows 2008 x32 or Windows 2008 x64) and you invoke the Linked Mode Configuration Wizard, the Join vCenter Server instance to existing Linked Mode group or another instance option is enabled. There is no option to isolate the vCenter Server system from Linked Mode.

    Workaround: Configure the vCenter Server system with mixed mode (IPv4 and IPv6) and invoke the Linked Mode Configuration Wizard: Start > VMware > Linked Mode Configuration Wizard. The Join option is disabled and the Isolate this vCenter server instance from linked mode group option is enabled.

    Note: If you configure a vCenter Server system with mixed mode, the domain controller must also be in mixed mode. If you do not want to use mixed mode in your IPv6 environment, you must uninstall vCenter Server to isolate the system from Linked Mode.

  • Multiple SSL warning messages appear when vCenter Server systems are joined in a Linked Mode group

    If multiple vCenter Server systems are joined in a Linked Mode group and do not use SSL certificates for authentication, multiple SSL warnings might be displayed in the vSphere Client when you log in.

    Workaround: Address each warning individually. Select the Always ignore this certificate option on each host. You must configure vCenter Servers to use SSL certificates.

  • vCenter Server might fail if permissions for vpxuser account are changed

    When you use a vSphere Client to connect to an ESX/ESXi host directly, if you select the Permission tab, it is possible to change the permissions for the vpxuser account. You might consider changing the permissions, for example, so vpxuser does not have administrator privileges on all host inventory objects. However, vCenter Server might fail after such a change.

    Workaround: Set the vpxuser account on the host to have administrator privileges from the root folder down. You can do so by connecting to the host with a vSphere Client, then selecting the Permissions tab.

  • vSphere Client displays inaccurate information in the General section of the Summary tab for hosts

    Under heavy load, the right-hand panel in the vSphere Client might fail to refresh and displays an inaccurate information in the General section.

    Workaround: You may need to refresh the vSphere Client manually by selecting a different host, and then select the first host again.

  • Virtual machine templates stored on shared storage become unavailable after Distributed Power Management (DPM) puts a host in standby mode or when a host is put in maintenance mode

    The vSphere Client associates virtual machine templates with a specific host. If the host storing the virtual machine templates is put into standby mode by DPM or into maintenance mode, the templates appear disabled in the vSphere Client. This behavior occurs even if the templates are stored on shared storage.

    Workaround: Disable DPM on the host that stores the virtual machine templates. When the host is in maintenance mode, use use the Datastore browser on another host that is not in maintenance or standby mode and also has access to the datastore on which the templates are stored to find the virtual machine templates. Then you can provision virtual machines using those templates.

  • vCenter Server 4.0 becomes unresponsive in large environments if managing ESX Server 3.5 hosts prior to ESX 3.5 patch 10

    vCenter Server 4.0 can become unresponsive in large environments after 30 days if it manages any ESX Server 3.5 hosts prior to ESX Server 3.5 patch 10.

    Workaround: Upgrade to ESX Server 3.5 Update 4 if you are running ESX Server 3.5 with vCenter Server 4.0.

  • Joining two vCenter Server instances fails with an error message in status.txt about failure to remove VMwareVCMSDS

    Joining an existing standalone vCenter Server instance to a Linked Mode group causes the vCenter Server installer to fail. When this happens, vCenter Server does not start on the machine where you are performing the installation. Also, messages indicating problems with LDAP connectivity or the LDAP service being unreachable are written to the <TEMP>/status.txt file, where <TEMP> is the temporary directory defined on your Windows system. To diagnose this problem, open the status.txt file and look for the following message:

    [2009-03-06 21:44:55 SEVERE] Operation "Join instance VMwareVCMSDS" failed: : Action: Join Instance
    Action: Removal of standalone instance
    Action: Remove Instance
    Problem: Removal of instance VMwareVCMSDS failed: The removal wizard was not able to remove all of the components. To complete removal, run "Adamuninstall.exe /i:<instance>" after resolving the following error:

    Folder '<vCenter Server installation directory>\VMwareVCMSDS' could not be deleted.
    The directory is not empty.

    Workaround: Perform the following steps:

    1. From a command prompt with administrator-level privileges, change directories to the vCenter Server installation directory.
    2. Delete the VMwareVCMSDS directory.
    3. Recover the local LDAP instance by typing jointool.bat recover.

  • Search in the vSphere Client does not support the colon characters

    Queries in the advanced search form that contain the colon result in a Bad Request error.

    Workaround: Modify the query to remove unsupported characters. For example, replace the colon character in the search text with a space or an asterisk.

  • The vCenter Server Resource Manager does not update the host tree after a migration in a cluster that has neither DRS nor HA enabled

    If you use VMotion to power on or migrate a virtual machine on clusters that have neither HA nor DRS enabled, the operations might fail with one of the following messages:

    • The host does not have sufficient memory resources to satisfy the reservation.
    • The host does not have sufficient CPU resources to satisfy the reservation

    This problem occurs even when the host appears to have sufficient capacity available and occurs only if both hosts are in the same cluster.

    When VMotion is used to migrate a virtual machine to a host or power it on under the new host, vCenter Server assesses whether the host has sufficient unreserved resources to meet the requirements of the virtual machine. However, the internal data structures used for this assessment are not updated when you use VMotion to migrate a virtual machine from a source host to a destination host in a cluster after having powered on the virtual machine on the source host. Any future admission control calculations for the source host consider the reservation of this virtual machine, even though it is no longer running on the host. This behavior might cause power-on and VMotion operations that target the source host to fail.

    Note: These failures are reported as the following faults in the log file:

    • vim.fault.InsufficientHostCpuCapacityFault
    • vim.fault.InsufficientHostMemoryCpuCapacityFault

    Workaround: Reconfigure the virtual machine's reservation, or power the machine on or off. These actions force vCenter Server to update its internal data structures.

  • Guided Consolidation cannot import systems that are running vCenter Converter

    Guided Consolidation import operations encounter a problem when the source system (the imported system) is running vCenter Converter. Guided Consolidation imports the system and attempts to uninstall vCenter Converter from the source system. The import operation succeeds but the following error is displayed when Guided Consolidation attempts to uninstall vCenter Converter:

    VMware Converter Agent Install failed.

    Workaround: Uninstall vCenter Converter from source systems before attempting to import them using Guided Consolidation.

  • The vSphere Client Roles menu does not display role assignments for all vCenter Server systems in a Linked Mode group

    When you create a role on a remote vCenter Server system in a Linked Mode group, the changes you make are propagated to all other vCenter Server systems in the group. However, the role appears as assigned only on the systems that have permissions associated with the role. If you remove a role, the operation only checks the status of the role on the currently selected vCenter Server system. However, it removes the role from all vCenter Server systems in the Linked Mode group without issuing a warning that the role might be in use on the other servers.

    Workaround: Before you delete a role from vCenter Server system, ensure that the role is not being used across other vCenter Server systems. To see if a role is in use, go to the Roles view and use the navigation bar to select each vCenter Server system in the group. The role's usage is displayed for the selected vCenter Server system.

    See vSphere Basic System Administration to learn about best practices for users and groups as well as information on setting roles for Linked Mode vCenter Server groups.

  • Removing a virtual machine's virtual switch that is being used might result in an error message

    If you try to remove a virtual switch that a powered-on virtual machine is using, an error message appears. The warning message should alert you that the virtual switch is in use and cannot be removed. Removing virtual switches in such cases might cause the virtual machine to become unusable.

    Workaround: Do not remove a virtual switch that is in use.

  • Some alarms remain in a triggered state after the virtual machine is migrated using VMotion

    Metric-based alarms (for example, CPU usage or memory Usage) that apply to virtual machines may remain in a triggered state after they are migrated using VMotion to another host.

    Workaround: Any of the following actions will solve the problem:

    • Reconfigure the triggered alarm.
    • Delete the triggered alarm.
    • Change the virtual machine's power state.
    • Induce a workload on the virtual machine such that the alarm triggers, and then remove the workload. The alarm is cleared.

  • Data displayed on the vSphere Client Performance tab does not relate to the selected object

    When you select a certain sequence of objects from the inventory list, the vSphere Client might display charts pertaining to the wrong object on the Overview page of the Performance tab. This problem occurs regardless of whether you select the objects in order from top to bottom or randomly.

    Workaround: Select a different inventory object. If this doesn't fix the problem, restart the vSphere Client.

  • Networking problems and errors might occur when analyzing machines with VMware Guided Consolidation

    When a large number of machines are under analysis for Guided Consolidation, the vCenter Collector Provider Services component of Guided Consolidation might be mistaken for a virus or worm by the operating system on which the Guided Consolidation functionality is installed. This occurs when the analysis operation encounters a large number of machines that have invalid IP addresses or name resolution issues. As a result, a bottleneck occurs in the network and error messages appear.

    Workaround: Do not add machines for analysis if they are unreachable. If you add machines by name, make sure the NetBIOS name is resolvable and reachable. If you add machines by IP address, make sure the IP address is static.

  • The Hardware Status tab does not display the ESX/ESXi host's hardware status information

    The Hardware Status tab in the vSphere Client does not populate the hardware status of the selected ESX/ESXi host when the vCenter Server machine or ESX/ESXi host are running in pure IPv6 mode.

    Workaround: Add and configure the IPv4 interface for both the vCenter Server machine and the ESX/ESXi host.

  • Disabled alarms for inventory objects are enabled if vCenter Server is restarted

    If an alarm for an inventory object, such as a hosts, virtual machine, datstore, and so on, is disabled in vCenter Server and vCenter Server is restarted, the alarms are enabled after the vCenter Server restart is complete.

    Workaround: Disable the alarms on the appropriate inventory objects when vCenter Server restarts.

  • You cannot re-display the toolbar in the Reports view of the Storage Views tab after you hide it

    The Reports view of the Storage Views tab has a toolbar that contains an object filter menu and a search field. These controls enable you to filter the reports tables based on object type, storage attributes, and keywords. If you hide the toolbar by selecting Hide from the toolbar's right-click menu, there is no mechanism to re-display it.

    Workaround: Close and reopen the vSphere Client.

  • Joining a Linked mode group after installation is unsuccessful if UAC is enabled on Windows Server 2008

    When User Account Control (UAC) is enabled on Windows Server 2008 32- or 64-bit operating systems and you try to join a machine to a Linked Mode group on a system that is already running vCenter Server, the link completes without any errors, but it is unsuccessful. Only one vCenter Server appears in the inventory list.

    Workaround: Complete the following procedures.

    After installation, perform the following steps to turn off UAC before joining a Linked Mode group:

    1. Select Start > Setting > Control Panel > User Accounts to open the User Accounts dialog box.
    2. Click Turn User Account control on or off.
    3. Deselect User Account Control (UAC) to help protect your computer and click OK.
    4. Reboot the machine when prompted.

    Start the Linked Mode configuration process as follows:

    1. Select Start > All Programs > VMware > vCenter Server Linked Mode Configuration.
    2. Click Next.
    3. Select Modify Linked-Mode configuration and click Next.
    4. Click Join this vCenter Server instance to an existing Linked-Mode group or another instance and click Next.
    5. Enter the server name and LDAP port information and click Next.
    6. Click Continue to complete the installation.
    7. Click Finish to end the linking process.

    Log in to one of the vCenter Servers and verify that the servers are linked. After the vCenter Servers are linked, turn on UAC as follows:

    1. Select Start > Setting > Control Panel > User Accounts to open the User Accounts dialog box.
    2. Click Turn User Account control on or off.
    3. Select User Account Control (UAC) to help protect your computer and click OK.
    4. Reboot the machine when prompted.

  • Starting or stopping the vctomcat Web service at the Windows command prompt might result in an error message

    On Windows operating systems, if you use the net start and net stop commands to start and stop the vctomcat Web service, the following error message might appear:

    The service is not responding to the control function.
    More help is available by typing NET HELPMSG 2186.

    Workaround: You can ignore this error message. If you want to stop the error message from occurring, modify the registry to increase the default timeout value for the service control manager (SCM). For more information, see the following Microsoft KB article: http://support.microsoft.com/kb/922918.

  • vCenter Server allows addition of the same ESX/ESXi system twice with two different IPv6 addresses

    If you add an ESX/ESXi system to the vCenter inventory, and if that system is already managed by vCenter under a different IP address, the vCenter Server does not detect the problem. The ESX/ESXi system appears in the inventory with a new IP address, with status disconnected. Connections to the ESX/ESXi system that use the old IP address remain active.

    Workaround: Do not add the same ESX/ESXi system twice.

  • Overview performance charts do not display after upgrade from VirtualCenter Server 2.5.x with SQL Express bundled database

    If you upgrade from a VirtualCenter Server 2.5 to vCenter Server 4.0 with an SQL Express bundled database, Overview performance charts do not display. When you open the Overview view of the Performance tab, the following error appears:

    STATs Report service internal error

    This error occurs because the vCenter Server upgrade tool cannot reconfigure the existing database. You must manually perform the configuration.

    Workaround: Perform the following steps.

    1. Choose Start > Program Files > SQL Server Configuration Manager.
    2. In the SQL Server Configuration Manager, do the following:
      1. Select Protocols for SQLEXP_VIM.
      2. Select TCP/IP.
      3. In Enabled, select True, and in Listen All, select Yes.
      4. Click OK.
    3. In a command window, type Services.msc to open the Service Manager.
    4. In the Services list, start the following services:
      • SQL Server 2005 Services: SQL Server (SQLEXP_VIM)
      • SQL Server 2005 Services: SQL Browser (if SQL Browser service is disabled, mark it for automatic or manual start)
      • VMware vCenter service
      • VMware Web service

  • If a system has virtual network adapter, Guided Consolidation might compute a larger number of NICs for that system than the number of physical NICs

    The number of NICs for a system computed by Guided Consolidation can be larger than the number of physical NICs for the system if the system has virtual network adapters. In this case, you might get the following warning during the Plan Consolidation phase: "Host does not have the desired number of VM networks. A consolidation will result in the mapping of multiple networks of the physical computer to a single VM network." This happens for any machine with virtual NICs (for example, for any virtual machine and any (physical or virtual) machine running VMware Workstation or other hosted virtualization platform).

    Workaround: No workaround needed. You can ignore the warning.

  • Error message appears if you add a second virtual disk to a virtual machine

    Suppose you create a virtual machine with default options by using Web Access connected to ESX/ESXi 4.0. If you then connect from vSphere Web Access to the vCenter Server that manages the ESX/ESXi host and add a second virtual disk to the same virtual machine with the option Create a New Virtual Disk, the error The specified file already exists on the server appears.

    Workaround: Use the vSphere Client to connect to vCenter Server and add a second virtual disk to the virtual machine.

  • The vc-support command uses a 64-bit DSN application and cannot gather data from the vCenter Server database

    When you use the VMware cscript vc-support.wsf command to retrieve data from the vCenter Server database, the default Microsoft cscript.exe application is used. This application is configured to use a 64-bit DSN rather than a 32-bit DSN, which is required by the vCenter Server database. As a result, errors occur and you cannot retrieve the data.

    Workaround: At a system prompt, run the vc-support.wsf command with the 32-bit DSN cscript.exe application:

    %windir%\SysWOW64\cscript.exe vc-support.wsf

  • Alarms with health status trigger conditions are not migrated to vSphere 4.0

    The vSphere 4.0 alarm triggers functionality has been enhanced to contain additional alarm triggers for host health status. In the process, the generic Host Health State trigger was removed. As a result, alarms that contained this trigger are no longer available in vSphere 4.0.

    Workaround: Use the vSphere Client to recreate the alarms. You can use any of the following preconfigured VMware alarms to monitor host health state:

    • Host battery status
    • Host hardware fan status
    • Host hardware power status
    • Host hardware temperature status
    • Host hardware system board status
    • Host hardware voltage
    • Host memory status
    • Host processor status
    • Host storage status

    If the preconfigured alarms do not handle the health state you want to monitor, you can create a custom host alarm that uses the Hardware Health changed event trigger. You must manually define the conditions that trigger for this event alarm. In addition, you must manually set which action occurs when the alarm triggers.

    Note: The preconfigured alarms already have default trigger conditions defined for them. You only need to set which action occurs when the alarm triggers.

  • The Overview performance charts do not display when vCenter Server uses an Oracle database

    You view the performance charts through the Overview view of the Performance tab. If your vCenter Server uses an Oracle database, the charts do not appear when you open this view. Instead, the following error message appears:

    STATs Report service internal error
    Message: STATs Report application initialization is not completed successfully.

    This error occurs because VMware installs a placeholder file instead of the Oracle ojdbc5.jar file with the overview performance charts due to licensing constraints.

    Workaround: Perform the following task to overwrite the placeholder Oracle ojdbc5.jar file with the actual file.

    1. Download the ojdbc5.jar file from the Oracle Technology Network Web site.
    2. Overwrite the VMware placeholder file with the ojdbc5.jar file you downloaded. By default, this file is installed in the C:\Program Files\VMware\Infrastructure\tomcat\lib directory.
    3. Restart vCenter Server Web Service.

  • Refresh delay for powered-on Virtual Machines field on the vSphere Client resource pool summary page

    The resource pool summary page in the vSphere Client displays the number of powered-on virtual machines for the selected resource pool and all of its nested resource pools. This information in Powered on Virtual Machines might be out of date at any given moment because the field is refreshed periodically (usually in less than two minutes) and not when a change occurs.

    Workaround: Count the number of powered on virtual machines by viewing the virtual machine list or by expanding the inventory tree.

  • On IBM x3655 Systems, the vSphere Client Configuration tab might list a power distribution sensor With an unknown status

    If the vSphere Client is installed on an IBM x3655 system that is equipped with certain types of power supplies, the Power Distribution sensor might indicate the health status of that power supply as Unknown. The Unknown status results from a discrepancy between the IPMI firmware and the power supply sensors. The IPMI firmware reports the presence of a Power Distribution entity in the system. However, the available power supply sensors cannot determine the status of the Power Distribution entity. As a result, the vSphere Client cannot indicate the current status of the Power Distribution entity.

    Workaround: None

  • Adapter Type drop-down menu missing vmxnet3 option on virtual machine running SUSE Enterprise Linux

    A virtual machine running SLES 10 or SLES 11 for which SLES is selected as the guest operating system type does not include vmxnet3 in the Adapter Type drop-down menu. The problem is most likely to occur in virtual machines that are migrated from ESX Server 3.x to ESX 4.x, but it might also occur in other circumstances.

    Workaround: The vmxnet3 option becomes available if you change the guest operating system type from SLES to SLES10 or SLES11.

    1. Power off the virtual machine.
    2. Right-click the virtual machine and select Edit Settings.
    3. In the Options tab, click General Options.
    4. In the version field, select either SLES10 or SLES11.

  • Virtual machines disappear from the the virtual switch diagram in the Networking View for host configuration

    In the vSphere Client Networking tab for a host, virtual machines are represented in the virtual switch diagram. If you select another host and then return to the Networking tab of the first host, the virtual machines might disappear from the virtual switch diagram.

    Workaround: Select a different view in the Configuration tab, such as Network Adapters, Storage, or Storage Adapters, and return to the Networking tab.

  • In the vSphere Client, clicking Close Tab on the Getting Started tab for certain objects (cluster, host, virtual machine) does not result in any action

    In the vSphere Client, clicking Close Tab [x] on the Getting Started tab for certain objects (cluster, host, virtual machine) does not result in any action. This issue occurs only if the vSphere Client is running on a machine whose operating systems is configured to disable javascript.

    Workaround: None

  • The vSphere Client does not update sensors that are associated with physical events

    The vSphere Client does not always update sensor status. Some events may trigger an update, such as a bad power supply or the removal of a redundant disk. Other events, such as chassis intrusion and fan removal, may not trigger an update to the sensor status.

    Workaround: None

  • The vSphere Client might take longer than expected to display newly installed extensions in the list of installed extensions

    After the installation of extensions is finished, 30-60 seconds pass before newly installed extensions appear in the list of installed extensions.

    Workaround: Restart the vSphere Client.

Virtual Machine Management Issues
  • Virtual machines running a Windows NT guest operating system require a reinstall of the network adapter driver after upgrading virtual hardware from version 4 to version 7

    After upgrading the virtual hardware on a Windows NT guest operating system, the virtual machine is unable to get an IP address because Windows NT does not fully support plug-and-play specification.

    Workaround: After upgrading virtual hardware from version 4 to version 7 on a Windows NT virtual machine, reinstall the network adapter driver by following the steps below.

    1. Right-click Network Neighborhood and select Properties.
    2. Select the Adapters tab.
    3. Remove the existing adapter.
    4. Add a new adapter.
    5. For an AMD PCNet dirver, select AMD PCNET Family Ethernet adapter and specify the path as C:\winnt\system32.
      For a vmxnet driver, click Have disk and specify path as C:\Program Files\VMware\VMware Tools\Drivers\vmxnet\.
    6. Reboot the virtual machine.

  • Automatic VMware Tools upgrade on guest power on reboots the guest automatically without issuing a reboot notification

    If you select to automatically update VMware Tools on a Windows Vista or Windows 2008 guest operating system, when the operating system powers on, VMware Tools is updated and the guest operating system automatically reboots without issuing a reboot notification message.

    Workaround: None

  • The SCSI driver floppy image required for Windows virtual machines that use the BusLogic virtual SCSI adapter is not displayed in the vSphere Client floppy drive configuration screen

    Certain Windows virtual machines that use the BusLogic virtual SCSI adapter require a SCSI driver to operate properly. By default, the driver floppy image is available on the ESXi host. However, when you attempt to connect the floppy image to your virtual machine using the Virtual Machine Properties dialog box, the file is not displayed for your selection in the datastore browser.

    Workaround: To connect the floppy image file to your virtual machine, enter the following in the Use existing floppy image in datastore text box:
    /usr/lib/vmware/floppies/vmscsi-1.2.1.0-signed.flp

  • Prompts to install a PCI standard PCI-PCI bridge occur after upgrading Windows 2000 virtual machines from hardware version 4 to hardware version 7

    When you upgrade a Windows 2000 virtual machine from hardware version 4 to hardware version 7, you might see numerous pop-up messages prompting you to install a PCI standard PCI-PCI bridge. These messages are harmless.

    Workaround: Accept all prompts to complete the hardware version upgrade.

  • Legacy vmware-toolbox script tab settings revert to default after VMware Tools upgrade on Linux guest operating systems

    When you upgrade VMware Tools on an ESX Server 3.0.x virtual machine running a Linux guest operating system, existing settings on the vmware-toolbox script tab revert to default settings.

    Workaround: Reconfigure custom script settings after upgrading VMware Tools.

  • The Installation Boot options for a virtual machine are not exported to OVF

    When you create an OVF package from a virtual machine that has the Installation Boot option enabled, this option is ignored during export. As a result, the OVF descriptor is missing the InstallSection element, which provides information about the installation process. When you deploy an OVF package, the InstallSection element is parsed correctly.

    Workaround: After exporting the virtual machine to OVF, manually create the InstallSection parameters in the OVF descriptor. If a manifest (.mf) file is present, you must regenerate it after you modify the OVF descriptor.

    Example: <InstallSection ovf:initialBootStopDelay="300"> <Info>Specifies that an install boot is needed.</Info> </InstallSection>

    The inclusion of the InstallSection parameters in the descriptor informs the deployment process that an install boot is required to complete deployment. The ovf:initialBootStopDelay attribute specifies the boot delay.

    See the OVF specification for details.

  • Cloning virtual machines with customization might result in a dialog box for Sysprep file information

    When you clone a virtual machine with customization, the cloning process might not finish and a Sysprep dialog box might prompt you for additional files.

    Workaround: Perform the following steps:

    1. Note the list of missing files that Windows mini-setup cannot find.
    2. Copy the required files (for example, c_20127.nls) from the source machine to the Sysprep install files folder, c:\sysprep\i386. The files that Sysprep prompts for are usually in the following location on the virtual source machine: C:\Windows\system32.
    3. Perform the cloning with customization.

    Note: The Sysprep directory is removed after the virtual machine is started and customization is completed.

  • A virtual machine cloned from a snapshot of a virtual machine with an LSI SAS controller might be erroneously configured with a BusLogic controller

    If you take a snapshot of a virtual machine with an LSI SAS controller and then clone a virtual machine from the snapshot, the virtual machine that was cloned from the snapshot might have BusLogic controller configured in the virtual machine properties instead of LSI SAS controller.

    Workaround: After cloning a virtual machine from a snapshot of a virtual machine with an LSI SAS controller, check the controller type for the cloned virtual machine in the Snapshot.config property. Reconfigure the controller type for the cloned virtual machine if necessary.

  • The vCenter Server fails when the delta disk depth of a linked virtual machine clone is greater than the supported depth of 32

    If the delta disk depth of a linked virtual machine clone is greater than the supported depth of 32, the vCenter Server fails and the following error message appears:

    Win32 exception: Stack overflow

    In such instances, you cannot restart the vCenter Server unless you remove the virtual machine from the host or clean the vCenter Server database. Consider removing the virtual machine from the host rather than cleaning the vCenter Server database, because it is much safer.

    Workaround: Perform the following steps:

    1. Log in to the vSphere Client on the host.
    2. Display the virtual machine clone in the inventory.
    3. Right-click the virtual machine and choose Delete from Disk.
    4. Restart the vCenter Server.

    Note: After you restart the vCenter Server, if the virtual machine is listed in the vSphere Client inventory and the Remove from Inventory option is disabled in the virtual machine context menu, you must manually remove the virtual machine entry from the vCenter database.

  • Custom scripts assigned in vmware-toolbox for suspend power event do not run when you suspend the virtual machine from the vSphere Client

    If you have assigned a custom script to the suspend power event in the Script tab of vmware-toolbox and you have configured the virtual machine to run VMware Tools scripts when you perform the suspend scripts, then the custom scripts are not run when you suspend the virtual machine from the vSphere Client.

    Workaround: None

  • An IDE hard disk added to a hardware version 7 virtual machine is defined as Hard Disk 1 even if a SCSI hard disk is already present

    If you have a hardware version 7 virtual machine with a SCSI disk already attached as Hard Disk 1 and you add an IDE disk, the virtual machine alters the disk numbering. The IDE disk is defined as Hard Disk 1 and the SCSI disk is changed to Hard Disk 2.

    Workaround: None. However, if you decide to delete one of the disks, do not rely exclusively on the disk number. Instead, verify the disk type to ensure that you are deleting the correct disk.

VMotion and Storage VMotion Issues
  • Virtual machines stored on a local datastore are not migrated off of the host when the host is placed in maintenance mode

    Virtual machines stored on a local datastore are not migrated off of the host when the host is placed in maintenance mode.

    Workaround: Manually move virtual machine on local datastores to another host if they need to remain available while their current host is in maintenance mode.

  • Storage VMotion conflicts with remote CD/DVD and floppy disk device connections

    CD/DVD and floppy remote backup devices are not supported with Storage VMotion. However, when you perform Storage VMotion on a powered-on virtual machine hosted by ESX/ESXi 4.0, the toolbar icon for connecting and disconnecting CD/DVD and floppy devices remains enabled, allowing you to add these devices while Storage VMotion is in progress even though this might cause failures.

    Workaround: Before initiating Storage VMotion, disconnect all remote CD/DVD and floppy devices attached to the virtual machine by clicking the CD/DVD and floppy device connect/disconnect icon.

  • Storage VMotion on ESX/ESXi 3.5 hosts does not display correct disk type if disk type is changed during Storage VMotion

    The Storage VMotion wizard presents an option to convert disk type (from thick to thin or from thin to thick) for virtual machines on any ESX/ESXi host version. After a disk is converted and Storage VMotion is complete, the disk type is not reflected properly for ESX/ESXi 3.5 hosts. The vSphere Client still reflects the old disk type.

    Workaround: Power off the virtual machine, un-register it, and then re-register it.

  • Reverting to a snapshot might fail after reconfiguring and relocating the virtual machine

    If you reconfigure the properties of a virtual machine and move it to a different host after you have taken a snapshot of it, reverting to the snapshot of that virtual machine might fail.

    Workaround: Avoid moving virtual machines with snapshots to hosts that are very different (for example, different version, different CPU type, etc.)

  • Using Storage VMotion to migrate a virtual machine with many disks might time out

    A virtual machine with many virtual disks might be unable to complete a migration with Storage VMotion. The Storage VMotion process requires time to open, close, and process disks during the final copy phase. Storage VMotion migrations of virtual machines with many disks might time out because of this per-disk overhead.

    Workaround: Increase the Storage VMotion fsr.maxSwitchoverSeconds setting in the virtual machine configuration file to a larger value. The default value is 100 seconds. Alternatively, at the time of the Storage VMotion migration, avoid running a large number of provisioning operations, migrations, power on, or power off operations on the same datastores the Storage VMotion migration is using.

VMware HA and Fault Tolerance Issues
  • When enabling FT, the Secondary VM starts for a few seconds and then fails, which causes the Primary VM to go into the Need Secondary VM state

    When Primary and Secondary VMs for FT run on hosts with mixed steppings of Intel Xeon 5400 or 5200 Series Processors (CPUID Family 6, Model 23, steppings 6 and 10), the Secondary VM starts for a few seconds and then fails, which causes the Primary VM to go into the Need Secondary VM state.

    Workaround: Ensure that the processors within the host match. You can check for configuration issues with VMware SiteSurvey. Download VMware SiteSurvey from http://www.vmware.com/download/shared_utilities.html. This utility reports configuration issues that impact FT. In addition, you can determine the processor stepping on VMware ESX with the command cat /proc/cpuinfo or by looking for CPU information in the host BIOS.

  • VMware HA might report misleading timeout errors when powering on or failing over a host with many VMs

    VMware HA timeout errors might appear a few minutes after powering on or migrating (using VMware HA) a host with many VMs (more than 70). This timeout error disappears when most of the VMs are powered on.

    Workaround: They can be ignored.

  • Disabling the virtual machine restart priority setting for a fault tolerant virtual machine disables some VMware Fault Tolerance operations

    Disabling the virtual machine restart priority setting for a fault tolerant virtual machine causes the Turn Off Fault Tolerance operation to fail. In addition, fault tolerant virtual machines with the virtual machine restart priority setting disabled cannot be deleted.

    Workaround: Avoid disabling the virtual machine restart priority setting for a fault tolerant virtual machine. If the virtual machine restart priority setting is disabled for a fault tolerant virtual machine, re-enable this setting to restore the Turn Off Fault Tolerance operation or to delete the virtual machine. To enable the virtual machine restart priority setting, perform the following steps.

    1. In the inventory of the vSphere Client, right-click the cluster in which the fault tolerant virtual machine resides.
    2. Click Edit Settings.
    3. Under VMware HA, click Virtual Machine Options.

      NOTE: VMware HA must be turned on in order to see this option.
    4. Under Cluster Default Settings, select a virtual machine restart priority from the drop-down menu other than Disabled.

  • Nonresponsive Secondary VMs or copies of virtual machines with possibly different names might remain in the host inventory if there is an interruption when turning on Fault Tolerance

    If you have a virtual machine on which VMware HA is enabled and you turn on Fault Tolerance, a nonresponsive Secondary VM might be added to the cluster's inventory, or you might end up with multiple copies of the virtual machine with different names. This situation occurs if the destination ESX/ESXi host of the Secondary VM loses connectivity to its managing vCenter Server through a reboot, power loss, or disconnection from the network while the secondary copy is being created and might result in incomplete configuration settings on the Secondary VM.

    Workaround: Delete the nonresponsive Secondary VM from the vCenter Server inventory.

  • Suspended virtual machines with independent nonpersistent disks do not failover on VMware HA hosts

    If you have suspended or powered off virtual machines on a host that has VMware HA enabled and if the virtual machine disks are configured to be independent and nonpersistent, failover does not happen. Those disks are not migrated to another host if the host fails, is powered off, or is placed in Maintenance Mode. Migrating these virtual machines is currently not supported on HA because the machines are not compatible with any other host in the cluster.

    Workaround: Unregister the virtual machine and register it on a compatible host.

  • When a virtual machine running on a NAS datastore is configured to shut down in response to host isolation, the virtual machine might attempt to run simultaneously on two hosts in a network isolation event

    If a virtual machine is configured with the default setting to shut down on host isolation, the virtual machine might fail to respond indefinitely while trying to shut down in the event of a multiple network failure that causes host isolation and the loss of network access to the datastore. HA tries to power off the virtual machine and restart it on another host. Two instances of the virtual machine might appear in the vSphere Client. There is no data corruption, because HA and VMFS correctly control access to the virtual machine's data, but the original virtual machine becomes nonresponsive. You can clear the condition by connecting directly the host that was isolated and dismissing the question.

    Workaround: In NFS environments, select Power Off as the host isolation response for the cluster default on affected virtual machines.

  • Secondary VM remains in inventory after Fault Tolerance has been turned off for Primary VM

    In some rare cases, selecting Turn Off Fault Tolerance in the vSphere Client for a Primary VM succeeds but the associated Secondary VM object is left in the inventory. This occasionally happens when a failover operation has just occurred and the new Secondary VM has not yet been started. This does not cause any serious consequences because the Secondary VM's files should have already been deleted..

    Workaround: Manually delete the Secondary VM.

  • Upgrading from an ESX/ESXi 3.x host to an ESX/ESXi 4.0 host results in a successful upgrade, but VMware HA reconfiguration might fail

    When you use vCenter Update Manager 4.0 to upgrade an ESX/ESXi 3.x host to ESX/ESXi 4.0, if the host is part of an HA or DRS cluster, the upgrade succeeds and the host is reconnected to vCenter Server, but HA reconfiguration might fail. The following error message displays on the host Summary tab: HA agent has an error : cmd addnode failed for primary node: Internal AAM Error - agent could not start. : Unknown HA error .

    Workaround: Manually reconfigure HA by right-clicking the host and selecting Reconfigure for VMware HA.

  • Virtual Machine Monitoring feature in VMware HA is not supported for ESX or ESXi releases prior to ESX 3.5 U3

    With VMware HA enabled for a cluster managed by vCenter Server 4.0, the VM Monitoring feature does not function correctly on ESX or ESXi hosts earlier than ESX Server 3.5 Update 3 and might cause false virtual machine failovers.

    Workaround: Disable the VM Monitoring feature for such virtual machines or upgrade the ESX/ESXi host to ESX Server 3.5 Update 3 or later.

  • Failover to VMware FT secondary virtual machine produces error message on host client

    When VMware Fault Tolerance is failing over to a secondary virtual machine, if the host chosen for the secondary virtual machine has recently booted, the host client sees this attempt as failing and displays the following error message:

    Login failed due to a bad username or password.

    This error message is seen because the host has recently booted and it is possible that it has not yet received an SSL thumbprint from the vCenter Server. After the thumbprint is pushed out to the host, the failover succeeds. This condition is likely to occur only if all hosts in an FT-enabled cluster have failed, causing the host with the secondary virtual machine to be freshly booted.

    Workaround: None. The failover succeeds after a few attempts.

  • Turning on Fault Tolerance for a powered-on virtual machine with lazyzeroed virtual disks fails

    If you try to turn on FT for a powered-on virtual machine with lazyzeroed virtual disks, the operation fails and the secondary virtual machine is not created. If you try to enable FT for a powered-on virtual machine with lazyzeroed virtual disks, the operation fails and the secondary virtual machine is not started.

    Workaround: Power off the virtual machine, turn on FT, and power the virtual machine back on. The virtual disks are correctly converted to eagerzeroed disks and the operation to turn on FT succeeds.

  • Trying to change the disk format of an FT-enabled virtual machine while migrating it across datastores results in a fault

    If you attempt to change the disk format of a powered-off, FT-enabled virtual machine while migrating it across datastores, the vSphere Client displays an InvalidArgument error message indicating that the operation has failed. The correct behavior is for the vSphere Client to disable the option to change the disk format.

    Workaround: When you relocate an FT-enabled virtual machine to another datastore, select the Same format as source as the default option.

  • Changing the system time on an ESX/ESXi host produces a VMware HA agent error

    If you change the system time on an ESX/ESXi host, after a short time interval, the following HA agent error appears:

    HA agent on <server> in <cluster> in <data center> has an error.

    This error is displayed in both the event log and the host's Summary tab in the vSphere Client.

    Workaround: Correct the host's system time and then restart vpxa by running the service vmware-vpxa restart command.

  • Configuring VMware High Availability (HA) on a heavily loaded system might result in an error message

    If you are enabling HA on a host that is experiencing a heavy load from its guest virtual machines, HA configuration might be interrupted for the host and an error message is displayed:
    HA Agent on the host failed

    Workaround: Reconfigure HA for the host, preferably after reducing the load either by powering off virtual machines or by migrating them to another host in the cluster using VMotion.

Guest Operating System Issues
  • VMware Tools installation failsfor unsupported Linux operating systems

    The default installer for VMware Tools only provides support for select Linux guest operating systems. When you try to install VMware Tools on an ESXi-hosted virtual machine with an unsupported Linux guest operating system, the installation fails.

    Workaround: From the VMware Web site, download an alternative Linux Tools ISO image that contains VMware Tools for supported as well as a variety of older and unsupported Linux guest operating systems. Alternatively, you can compile kernel modules for the unsupported Linux release by using the install-vmware.pl script distributed as part of VMware Tools.

  • Virtual machines with WindowsNT guests require a response to a warning message generated when the virtual machine attempts to automatically upgrade VMware Tools

    If you set the option to automatically check and upgrade VMware Tools before each power-on operation for WindowsNT guests, the following warning message appears:

    Set up failed to install the vmxnet driver Automatically, This driver will have to be installed manually

    Workaround: The upgrade stops until the warning is acknowledged. To complete the upgrade, log into the WindowsNT guest and acknowledge the warning message.

  • Multiple DNS suffixes are not applied correctly after image customization of Linux distributions

    DNS suffixes are automatically appended when a Linux distribution tries to resolve a DNS domain name. When more than one DNS suffix is customized, only the last DNS suffix is applied. Depending on the Linux distribution, not all customized DNS suffixes appear in the Linux distribution user interface.

    Workaround: None

  • VMware Guided Consolidation subcomponent fails when installed on a Windows Server 2008 64-bit virtual machine running on ESX/ESXi or Workstation hosts

    If you install VMware Guided Consolidation on a Windows 64-bit operating system running in a virtual machine hosted by ESX 3.5/ESXi 3.5 with Update 3, Patch 9 or earlier, the Guided Consolidation VMwareCollectorSubProcess.exe subcomponent might malfunction. Multiple processes running VMwareCollectorSubProcess.exe run for many hours. All analysis appears to be stalled and remains stalled (the Process IDs do not change). The symptoms reappear even after rebooting the system. Multiple error logs appear in the Event Viewer attributed to VMwareCollectorSubProcess.exe. This problem also occurs on Workstation 5.5, but is fixed in Workstation 6.5.

    Workaround: You must be running ESX 3.5/ESXi 3.5 Patch 10 or later, or upgrade to ESX 4.0/ESX 4.0 or Workstation 6.5.

  • Removing the disk from a virtual machine with a RHEL3 guest operating system without informing the guest causes the virtual machine to fail

    For 32-bit a virtual machine with a RHEL3 guest operating system and a Bus Logic Driver, hot removing the disk without informing the guest OS about the disk removal causes the virtual machine operation to fail.

    Workaround: Remove the disk from the guest explicitly. To remove the disk, first get the disk details from /proc/scsi/scsi for the disk that you want to remove:

    1. Get the HOST CHAN ID and LUN numbers for the device from /proc/scsi/scsi
    2. Run the following command in the RHEL console:

      echo "scsi remove-single-device HOST CHAN DEV LUN" > /proc/scsi/scsi

  • Devices attached to hot-added BusLogic adapter are not visible to Linux guest

    Devices attached to hot-added BusLogic adapter are not visible to a Linux guest if the guest previously had another BusLogic adapter. In addition, hot removal of the BusLogic adapter might fail. This issue occurs because the BusLogic driver available in Linux distributions does not support hot plug APIs. This problem does not affect performing hot add of disks to the adapter, only performing hot add of the adapter itself.

    Workaround: Use a different adapter, such as a parallel or SAS LSI Logic adapter, for hot add capabilities. If a BusLogic adapter is required, attempt a hot remove of the adapter after unloading the BusLogic driver in the guest. You can also attempt to get control of the hot-added adapter by loading another instance of the BusLogic driver. You can load another instance of the BusLogic adapter by running the command modprobe -o BusLogic1 BusLogic (where you replace BusLogic1 with BusLogic2, BusLogic3 for BusLogic2, and so on, for every hot add operation).

  • SMP virtual machines with large amount of memory might boot slowly

    SMP virtual machines with large amounts of memory might boot slower than on native hardware. Degraded performance occurs only during the boot phase as the guest operating system zeroes memory. The issue is observed on, but might not be limited to, Windows Server 2003 64-bit guest operating systems.

    Workaround: None

  • Solaris 10 U4 virtual machine becomes nonresponsive during VMware Tools upgrade

    Upgrading or restarting VMware Tools in a Solaris 10 U4 virtual machine with an advanced vmxnet adapter might cause the guest operating system to become nonresponsive and the installation to be unable to proceed.

    Solaris 10 U5 and later versions are not affected by this issue.

    Workaround: Before installing or upgrading VMware Tools, temporarily reconfigure the advanced vmxnet adapter by removing its autoconfiguration files in /etc/ or removing the virtual hardware.

Supported Hardware Issues
  • VMware ESXi Embedded fails to boot on HP DL385 G2 servers when BIOS uses USB 1.1 controller

    VMware ESXi Embedded systems do not recognize the USB 1.1 controller on HP DL385 G2 servers. As a result, the ESXi system fails to boot. This problem always occurs on HP DL385 G2 servers when the BIOS is set to use the USB 1.1 Controller.

    Workaround: During the boot phase of an ESXi Embedded system, enable the USB 2.0 controller in the BIOS settings. In some installations, this controller appears as V1.1+V2.0.

  • VMware ESXi Installable might fail to boot on Dell 2900 servers

    If your Dell 2900 server has a version of BIOS earlier than 2.1.1, ESXi Installable VMkernel might stop responding while booting. This is due to a bug in the Dell BIOS, which is fixed in BIOS version 2.1.1.

    Workaround: Upgrade BIOS to the version 2.1.1 or later.

  • Core Dump fails with a timeout message

    Configuring a device connected to a Perc 4/DC controller as a core dump device on which to store crash dumps in the event of a system crash can lead to timeouts and unsaved core dumps. This timeout behavior has been observed with different firmware versions on this controller (for example, 352B and 352D) and only for system crashes. No issues have been observed with I/O to the same device when the system is running.

    Workaround: Do not configure a device connected to the Perc 4/DC controller as a core dump device for ESX/ESXi 4.0 systems.

  • Slow performance during virtual machine power-On or disk I/O on ESX/ESXi on the HP G6 Platform with P410i or P410 Smart Array Controller

    Some of these hosts might show slow performance during virtual machine power on or while generating disk I/O. The major symptom is degraded I/O performance, causing large numbers of error messages similar to the following to be logged to /var/log/messages.

    Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
    Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL!
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
    Mar 25 17:39:26 0 0x0 0x0.
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)WARNING: NMP: nmp_DeviceRetryCommand: Device
    "naa.600508b1001030304643453441300100": awaiting fast path state update for failoverwith I/O blocked. No prior reservation
    exists on the device.
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060700) to NMP device
    "naa.600508b1001030304643453441300100" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 0x
    Mar 25 17:39:26 0 0x0 0x0.

    Workaround: Install the HP 256MB P-series Cache Upgrade module: http://h30094.www3.hp.com/product.asp?mfg_partno=462968-B21&pagemode=ca&jumpid=in_r3924/kc.

  • No CIM indication alerts are received when the power supply cable and power supply unit are reinserted into HP servers

    No new SEL(IML) entries are created for power supply cable and power supply unit reinsertion into HP servers when recovering a failed power supply. As a result, no CIM indication alerts are generated for these events.

    Workaround: None

  • Problems with TEAC DV-28E-V DVD drive

    If an ESX/ESXi host is physically connected to a TEAC DV-28E-V DVD drive with old firmware (for example, C.AB), the virtual machine, host daemon, or ESX/ESXi host might become nonresponsive. The problem does not occur each time, and it is more likely to occur with Windows virtual machines.

    Workaround: Upgrade the DVD drive firmware to the latest version or replace the DVD drive with a different model.

Internationalization Issues
  • Parallel/serial port output file name does not accept non-ASCII characters and displays an error message

    When configuring a virtual machine, filenames that include non-ASCII characters might be rejected with an error message. The validation for filenames is not localization-safe and might result in rejection of a valid name. This problem affects output files for serial and parallel ports, and it might affect ISO and FLP names or disk (VMDK) filenames.

    Workaround: Restrict all datastore contents (directories and filenames) to ASCII.

Miscellaneous Issues
  • New Help menu items appear inactive or clicking other links for Help results in an error

    In vSphere Client installations on machines running non-English, non-Japanese, non-German, and non-Simplified Chinese Windows operating systems, Help menu items appear inactive. In addition, if you click other links or buttons for Help within the vSphere Client the following error message appears:

    Missing help file

    Workaround: Copy the contents of the vSphere Client online help folder from
    C:\Program\VMware\Infrastructure\Virtual Infrastructure Client\Help\en\VIC40
    to
    C:\Program\VMware\Infrastructure\Virtual Infrastructure Client\Help\en.

    Ensure that only the contents of the vSphere Client online help subdirectory (VIC40) is copied to this level.

    To view the online help for other product components under C:\Program\VMware\Infrastructure\Virtual Infrastructure Client\Help\en, double-click the index.html file in the subdirectory for that help system. For example, to view the DRS Troubleshooting help system, double-click the index.html file in the DSR40 subdirectory. The subdirectories for online help systems for other vSphere modules at this location vary depending on the vSphere products you have installed.

  • An ESX/ESXi host or a virtual machine's guest operating system might fail to operate if running multi-threaded applications using VMCI Sockets SDK
    A known issue with the VMCI Sockets library can cause a host or guest operating systems to fail to operate if they are running multi-threaded applications that use the VMCI Sockets SDK.

    Workaround: Avoid running multi-threaded applications that use VMCI Sockets that exhibit this behavior.

  • Stopping or restarting the vCenter Server service through the Windows Services Control MMC plug-in might lead to an error message

    Under certain circumstances, the vCenter Server service might take longer than usual to start. Stopping and restarting the vCenter Server service through the Windows Services Control MMC plug-in might lead to the following error message:

    Service failed to respond in a timely manner.

    This message indicates that the time required to shut down or start up vCenter Server was more than the configured system-wide default timeout for starting or stopping the service.

    Workaround: Refresh the Services Control screen after a few minutes, which should show that the service has been correctly stopped and restarted.

  • Patches continue to be listed as installed after you restore factory settings or remove custom extensions

    Even after you select Restore Factory Settings or Remove Custom Extensions in the direct console user interface, an esxupdate or vihostupdate query displays all patches as Installed.

    Workaround: None

  • ESX/ESXi host's core dump partition setting is not persistent under certain conditions

    If you change the core dump partition from /root to a second location and experience an ESX/ESXi host failure within an hour after this change is made but before the host is rebooted, the core dump partition reverts to its original setting of /root.

    Workaround: After changing the core dump partition, immediately run esxcfg-boot.

  • Diagnostic data from vCenter may be contained in file that cannot be decompressed

    While extracting a .tgz file that contains diagnostic data from vCenter, a dialog appears listing files that cannot be extracted, as well as an error message: Symbolic link points to missing files.

    Workaround: None

  • ESXi runs in degraded mode and some operations might fail if insufficient memory is available

    ESXi Embedded and ESXi Installable require at least 3GB of physical memory. If the available memory is less than 3GB, ESXi performance is degraded and some operations might fail. Features that are most likely to fail include VMware High Availability and any operation that you perform when the vSphere Client is connected directly to an ESXi host.

    Workaround: Increase the amount of available memory.