Updated on: 10 DEC 2013
VMware ESXi™ 5.1 10 SEPT 2012 Build 799733
VMware vCenter Server™ 5.1 10 SEPT 2012 Build 799731
vCenter Server Appliance 5.1 10 SEPT 2012 Build 799730
Check for additions and updates to these release notes.
What's in the Release Notes The release notes cover the following topics:
This release of VMware vSphere 5.1 includes ESXi 5.1 and vCenter Server 5.1. Read about the new and enhanced features in this release in What's New in VMware vSphere 5.1.
VMware vSphere 5.1 is available in the following languages:
- Simplified Chinese
Compatibility and Installation
ESXi, vCenter Server, and vSphere Web Client Version Compatibility
The VMware Product Interoperability Matrix provides details about the compatibility of current and previous versions of VMware vSphere components, including ESXi, VMware vCenter Server, the vSphere Web Client, and optional VMware products. In addition, check this site for information about supported management and backup agents before installing ESXi or vCenter Server.
The vSphere Client and the vSphere Web Client are packaged with the vCenter Server and modules ZIP file. You can install one or both clients from the VMware vCenter™ Installer wizard.
Hardware Compatibility for ESXi
To determine which processors, storage devices, SAN arrays, and I/O devices are compatible with vSphere 5.1, use the ESXi 5.1 information in theVMware Compatibility Guide.
The list of supported processors is expanded for this release. To determine which processors are compatible with this release, use theVMware Compatibility Guide.
Guest Operating System Compatibility for ESXi
To determine which guest operating systems are compatible with vSphere 5.1, use the ESXi 5.1 information in theVMware Compatibility Guide.
Beginning with vSphere 5.1, support level changes for older guest operating systems have been introduced. For descriptions of each support level, seeKnowledge Base article 2015161. TheVMware Compatibility Guide provides detailed support information for all operating system releases and VMware product releases.
The following guest operating system releases that are no longer supported by their respective operating system vendors are deprecated. Future vSphere releases will not support these guest operating systems, although vSphere 5.1 does support them.
- Windows NT
- All 16-bit Windows and DOS releases (Windows 98, Windows 95, Windows 3.1)
- Debian 4.0 and 5.0
- Red Hat Enterprise Linux 2.1
- SUSE Linux Enterprise 8
- SUSE Linux Enterprise 9 prior to SP4
- SUSE Linux Enterprise 10 prior to SP3
- SUSE Linux Enterprise 11 Prior to SP1
- Ubuntu releases 8.04, 8.10, 9.04, 9.10 and 10.10
- All releases of Novell Netware
- All releases of IBM OS/2
Virtual Machine Compatibility for ESXi
Virtual machines that are compatible with ESX 3.x and later (hardware version 4) are supported with ESXi 5.1. Virtual machines that are compatible with ESX 2.x and later (hardware version 3) are no longer supported. To use such virtual machines on ESXi 5.1, upgrade the virtual machine compatibility. See thevSphere Upgrade documentation.
vSphere Client Connections to Linked Mode Environments with vCenter Server 5.x
vCenter Server 5.1 can exist in Linked Mode only with other instances of vCenter Server 5.1.
Installation Notes for This Release
Read thevSphere Installation and Setup documentation for step-by-step guidance on installing and configuring ESXi and vCenter Server.
Although the installations are straightforward, several subsequent configuration steps are essential. In particular, read the following:
- 'Licensing' in thevCenter Server and Host Management documentation
- 'Networking' in thevSphere Networking documentation
- 'Security' in thevSphere Security documentation for information on firewall ports
Migrating Third-Party Solutions
You cannot directly migrate third-party solutions installed on an ESX or ESXi host as part of a host upgrade. Architectural changes between ESXi 5.0 and ESXi 5.1 result in the loss of third-party components and possible system instability. To accomplish such migrations, you can create a custom ISO file with Image Builder. For information about upgrading with third-party customizations, see thevSphere Upgrade documentation. For information about using Image Builder to make a custom ISO, see thevSphere Installation and Setup documentation.
Upgrades and Installations Disallowed for Unsupported CPUs
vSphere 5.1 supports only CPUs with LAHF and SAHF CPU instruction sets. During an installation or upgrade, the installer checks the compatibility of the host CPU with vSphere 5.1. If your host hardware is not compatible, a purple screen appears with an incompatibility information message, and you cannot install or upgrade to vSphere 5.1.
Upgrades for This Release
For instructions about upgrading vCenter Server and ESX/ESXi hosts, see thevSphere Upgrade documentation.
Test Releases of vSphere 5.1
Upgrades from the vSphere 5.1 Beta and the vSphere 5.0 Release Candidate releases to vSphere 5.1 are not supported. Uninstall ESXi 5.1 Beta or Release Candidate and vCenter Server 5.1 Beta or Release Candidate, and perform fresh installations of vCenter Server 5.1 and ESXi 5.1. If you were testing Beta or Release Candidate versions of vSphere 5.1, VMware recommends that you recreate data that you want to preserve from those setups on vSphere 5.1.
vCenter Server Upgrades
vSphere 5.1 supports the following upgrade scenarios.
You can perform in-place upgrades on 64-bit systems from vCenter Server 4.x and vCenter Server 5.0 to vCenter Server 5.1.
You cannot upgrade an instance of vCenter Server 4.x that is running on Windows XP Professional x64 Edition.
Customers with VirtualCenter 2.5 update 6 and later with 32-bit operating system will be required to perform a migration upgrade to vCenter Server 5.0 as the first step in the upgrade process due to the 32bit/64bit differences. After this migration upgrade, customers can perform an in-place upgrade from version 5.0 to version 5.1. See the version 5.0vSphere Upgrade documentation.
vCenter Server 5.1 can manage ESXi 5.x hosts in the same cluster with ESX/ESXi 4.x hosts. vCenter Server 5.1 cannot manage ESX 2.x or 3.x hosts.
vSphere 5.1 offers the following tools for upgrading ESX/ESXi hosts:
vSphere Update Manager. You can use vSphere Update Manager to upgrade, update, and patch clustered hosts, and virtual machines. If your site uses vCenter Server, VMware recommends that you use vSphere Update Manager. To perform an orchestrated host upgrade or an orchestrated virtual machine upgrade, see the instructions in thevSphere Upgrade documentation. For complete documentation about vSphere Update Manager, seeInstalling and Administering VMware vSphere Update Manager.
Upgrade interactively using an ESXi installer ISO image on CD-ROM, DVD, or USB flash drive. You can run the ESXi 5.1 installer from a CD-ROM, DVD, or USB flash drive to do an interactive upgrade. This method is appropriate for a small number of hosts.
Perform a scripted upgrade. You can upgrade or migrate from version 4.x ESX/ESXi hosts and ESXi 5.0.x hosts to ESXi 5.1 by invoking an update script, which provides an efficient, unattended upgrade. Scripted upgrades also provide an efficient way to deploy multiple hosts. You can use a script to upgrade ESXi from a CD-ROM or DVD drive, or by PXE-booting the installer.
vSphere Auto Deploy. If your ESXi 5.0.x host was deployed using vSphere Auto Deploy, you can use Auto Deploy to reprovision the host by rebooting it with a new image profile that contains the ESXi upgrade.
esxcli. You can upgrade and apply patches to ESXi 5.0.x hosts by using the esxcli command-line utility for ESXi to upgrade to ESXi 5.1 from a download depot on vmware.com or from a downloaded ZIP file of a depot that is prepared by a VMware partner. You cannot use esxcli to upgrade ESX or ESXI hosts to version 5.x from ESX/ESXI versions earlier than version 5.0.
Open Source Components for VMware vSphere 5.1
The copyright statements and licenses applicable to the open source software components distributed in vSphere 5.1 are available at http://www.vmware.com/download/vsphere/open_source.html, on the Open Source tab. You can also download the source files for any GPL, 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.
Product Support Notices
vSphere Client. In vSphere 5.1, all new vSphere features are available only through the vSphere Web Client. The traditional vSphere Client will continue to operate, supporting the same feature set as vSphere 5.0, but not exposing any of the new features in vSphere 5.1.
vSphere 5.1 and its subsequent update and patch releases are the last releases to include the traditional vSphere Client. Future major releases of VMware vSphere will include only the vSphere Web Client.
For vSphere 5.1, bug fixes for the traditional vSphere Client are limited to security or critical issues. Critical bugs are deviations from specified product functionality that cause data corruption, data loss, system crash, or significant customer application down time where no workaround is available that can be implemented.
VMware Toolbox. vSphere 5.1 is the last release to include support for the VMware Tools graphical user interface, VMware Toolbox. VMware will continue to update and support the Toolbox command-line interface (CLI) to perform all VMware Tools functions.
VMI Paravirtualization. vSphere 4.1 was the last release to support the VMI guest operating system paravirtualization interface. For information about migrating virtual machines that are enabled for VMI so that they can run on later vSphere releases, see Knowledge Base article 1013842.
Windows Guest Operating System Customization. vSphere 5.1 is the last release to support customization for Windows 2000 guest operating systems. VMware will continue to support customization for newer versions of Windows guests.
- VMCI Sockets. Guest-to-guest communications (virtual machine to virtual machine) are deprecated in the vSphere 5.1 release. This functionality will be removed in the next major release. VMware will continue support for host to guest communications.
The known issues are grouped as follows. Installation Issues
New If Auto Deploy encounters a rule that applies a host profile, it applies that rule even if the host profile no longer exists
Assume that one of the rules in an Auto Deploy ruleset applies a host profile, and you delete the host profile from the vSphere Client or the vSphere Web Client. If you do not remove the rule from the ruleset, the host profile is still applied to hosts that are booted with Auto Deploy.
Workaround: You can determine whether any rules use deleted host profiles by using the
Get-DeployRuleSet PowerCLI comdlet. The cmdlet shows the string
deleted in the rule's item list. You can then run the
Remove-DeployRule cmdlet to remove the rule.
For Auto Deploy Stateful installation, cannot use firstdisk argument of esx on systems that have ESX/ESXi already installed on USB
You configure the host profile for a host that you want to set up for Stateful Install with Auto Deploy. As part of configuration, you select USB as the disk, and you specify esx as the first argument. The host currently has ESX/ESXi installed on USB. Instead of installing ESXi on USB, Auto Deploy installs ESXi on the local disk.
Auto Deploy PowerCLI cmdlets Copy-DeployRule and Set-DeployRule require object as input
When you run the Copy-DeployRule or Set-DeployRule cmdlet and pass in an image profile or host profile name, an error results.
Workaround: Pass in the image profile or host profile object.
Applying host profile that is set up to use Auto Deploy with stateless caching fails if ESX is installed on the selected disk
You use host profiles to set up Auto Deploy with stateless caching enabled. In the host profile, you select a disk on which a version of ESX (not ESXi) is installed. When you apply the host profile, an error that includes the following text appears.
Expecting 2 bootbanks, found 0
Workaround: Remove the ESX software from the disk, or select a different disk to use for stateless caching.
vSphere Auto Deploy no longer works after a change to the IP address of the machine that hosts the Auto Deploy server
You install Auto Deploy on a different machine than the vCenter Server, and change the IP address of the machine that hosts the Auto Deploy server. Auto Deploy commands no longer work after the change.
Workaround: Restart the Auto Deploy server service.
net start vmware-autodeploy-waiter
If restarting the service does not resolve the issue, you might have to reregister the Auto Deploy server. Run the following command, specifying all options.
autodeploy-register.exe -R -a vCenter-IP -p vCenter-Port -u user_name -w password -s setup-file-path
VDS configuration fails for ESXi systems booted with Auto Deploy
In a cluster, only two hosts are capable of running a virtual machine that is enabled for Fault Tolerance (FT). One of the hosts is rebooted with Auto Deploy. VDS configuration fails, and the host remains in maintenance mode after it is reconnected to the vCenter Server system.
This happens when only the ESXi system that is being rebooted can host the secondary virtual machine. The Fault Tolerance process adds the secondary virtual machine to the booting ESXi host's inventory and vDS migration fails with a Resource In Use error.
The problem has been observed in the following situations:
- During upgrade of ESXi hosts that are in a cluster.
- If many hosts in a cluster reboot simultaneously, so that only one or two hosts are fully booted.
- In a small cluster (two or three hosts).
Workaround: If you see the problem during an upgrade, disable Fault Tolerance on the virtual machines temporarily. The virtual machines can migrate to the already upgraded host. Reenable Fault Tolerance after the upgrade process is complete.
If you see the problem when multiple hosts are rebooting or in a small cluster, wait until several hosts in the cluster have completed the boot process, and reboot the affected host. You can also disable Fault Tolerance for the virtual machine whose secondary virtual machine is assigned to the affected host.
On HP DL980 G7, ESXi hosts do not boot through Auto Deploy when onboard NICs are used
You cannot boot an HP DL980 G7 system using Auto Deploy if the system is using the onboard (LOM Netxen) NICs for PXE booting.
Workaround: Install an add-on NIC approved by HP on the host, for example HP NC3 60T and use that NIC for PXE booting.
Installation of vCenter Server and related components fails if the user name of the logged-in user contains non-ASCII characters
If the user name of the user who is currently logged in contains non-ASCII characters, installation of vCenter Server, vCenter Inventory Server, vCenter Single Sign On, or vSphere Web Client fails with the error message: The user name contains non-ASCII characters. Please log in with a user name that contains only ASCII characters.
Workaround: Log in with a user name that does not contain non-ASCII characters and retry the installation.
Auto Deploy installation fails if the installation path includes non-ASCII characters
If you select a folder that includes non-ASCII characters when you run the Auto Deploy installer, the following error results
: Error 29106.Unknown error.
Workaround: Select a folder that includes only ASCII characters in the path name.
A live update with esxcli fails with a VibDownloadError
A user performs two updates in sequence, as follows.
- A live install update using the esxcli software profile update or esxcli vib update command.
- A reboot required update.
The second transaction fails. One common failure is signature verification, which can be checked only after the VIB is downloaded.
Workaround: Resolving the issue is a two-step process.
- Reboot the ESXi host to clean up its state.
- Repeat the live install.
ESXi scripted installation fails to find the kickstart (ks) file on a CD-ROM drive when the machine does not have any NICs connected
When the kickstart file is on a CD-ROM drive in a system that does not have any NICs connected, the installer displays the error message: Can't find the kickstart file on cd-rom with path <path_to_ks_file>.
Workaround: Reconnect the NICs to establish network connection, and retry the installation.
VMware VirtualCenter Management Webservice service fails to start after vCenter Server is installed in a location containing any combination of the special characters !, @, or #
If the vCenter Server installation path contains any combination of the special characters !, @, or #, the vCenter Server installation is successful but the VMware VirtualCenter Management Webservice service does not start, and logging in to vCenter Server fails with the error do not have permissions. For example, the following installation path would produce the error: C:[email protected]@On!#$Installer.
Workaround: Install vCenter Server in the default location or in a custom location without the special characters.
Scripted installation fails on the SWFCoE LUN
When the ESXi installer invokes installation using the kickstart (ks) file, all the FCoE LUNs have not yet been scanned and populated by the time installation starts. This causes the scripted installation on any of the LUNs to fail. The failure occurs when the https, http, or ftp protocol is used to access the kickstart file.
Workaround: In the %pre section of the kickstart file, include a sleep of two minutes:
vCenter Single Sign On server installation fails on systems running IBM DB2 9.7 Fix Pack 1 or earlier
Components of Single Sign On (SSO) require DB2 9.7 Fix Pack 2 or later. When you attempt to install SSO on a system running earlier versions of DB2 9.7, installation fails.
Workaround: Update the DB2 9.7 instance to Fix Pack 2 or later.
Potential problems if you upgrade vCenter Server but do not upgrade Auto Deploy server
When you upgrade vCenter Server, vCenter Server replaces the 5.0 vSphere HA agent (vmware-fdm) with a new agent on each ESXi host. The replacement happens each time an ESXi host reboots. If vCenter Server is not available, the ESXi hosts cannot join a cluster.
Workaround: If possible, upgrade the Auto Deploy server.
If you cannot upgrade the Auto Deploy server, you can use Image Builder PowerCLI cmdlets included with vSphere PowerCLI to create an ESXi 5.0 image profile that includes the new vmware-fdm VIB. You can supply your hosts with that image profile.
- Add the ESXi 5.0 software depot and add the software depot that contains the new vmware-fdm VIB.
Add-EsxSoftwareDepot C:PathVMware-Esxi-5.0.0-buildnumber-depot.zip Add-EsxSoftwareDepot http://vcenter server/vSphere-HA-depot
- Clone the existing image profile and add the vmware-fdm VIB.
New-EsxImageProfile -CloneProfile 'ESXi-5.0.0-buildnumber-standard' -name 'Imagename' Add-EsxSoftwarePackage -ImageProfile 'ImageName' -SoftwarePackage vmware-fdm
- Create a new rule that assigns the new image profile to your hosts and add the rule to the ruleset.
New-DeployRule -Name 'Rule Name' -Item 'Image Name' -Pattern 'my host pattern' Add-DeployRule -DeployRule 'Rule Name'
- Perform a test and repair compliance operation for the hosts.
If Stateless Caching is turned on, and the Auto Deploy server becomes unavailable, the host might not automatically boot using the stored image
In some cases, a host that is set up for stateless caching with Auto Deploy does not automatically boot from the disk that has the stored image if the Auto Deploy server becomes unavailable. This can happen even if the boot device that you want is next in logical boot order. What precisely happens depends on the server vendor BIOS settings.
Workaround: Manually select the disk that has the cached image as the boot device.
Installation fails when you install vCenter Single Sign On with a local database on a Turkish version of Windows 2008 R2 64 bit
You might receive an error (Error 20003 or 20010) when you install vCenter Single Sign On in a Turkish Windows environment and the database is on the local system. This error occurs when Microsoft SQL Server capitalizes certain letters, which makes the database incompatible with vCenter Single Sign On.
- Install the database on a separate system running an English version of Windows 2008 Server.
- Run the vCenter Single Sign On installer on the system running the Turkish version of Windows 2008 Server.
- Connect to the database remotely.
Installation of vCenter Single Sign On high availability or recovery node fails if Master Password and Administrator password are different
The following behavior occurs when you install vCenter Single Sign On in high availability mode:
- When you provide the correct vCenter Single Sign On Administrator password, validation appears to be successful, but installation fails with an error that the vCenter Single Sign On Master Password is incorrect.
- When you provide the correct vCenter Single Sign On Master Password, validation fails because the installer is expecting the vCenter Single Sign On Administrator password.
The following behavior occurs when you install vCenter Single Sign On in recovery mode:
- When you provide the correct vCenter Single Sign On Administrator password, installation fails with an error that the vCenter Single Sign On Master Password is incorrect.
- When you install vCenter Single Sign On on a domain machine and you provide the correct vCenter Single Sign On Master Password, installation fails with an error that the SSPI Service account cannot be configured because the installer is expecting the vCenter Single Sign On Administrator password.
- When you install Single Sign On on a workgroup machine, installation fails with an error that the Lookup Service configuration failed. The log file contains an error that the vCenter Single Sign On Administrator password is incorrect.
Workaround: Ensure that the same password is used for the vCenter Single Sign On Master Password and the vCenter Single Sign On Administrator password. You can verify the passwords using the following commands. The default <ssoserver folder> is typically C:Program FilesVMwareInfrastructureSSOServer.
- vCenter Single Sign On Master Password:
<ssoserver folder>utils>rsautil.cmd manage-secrets -a list
- vCenter Single Sign On Administrator password:
<ssoserver folder>utils>rsautil.cmd manage-identity-sources -a list -u admin
You can set the passwords using the following commands:
- vCenter Single Sign On Master Password:
<ssoserver folder>utilsrsautil.cmd manage-secrets -a change -m <master password> -N <new Master Password>
- vCenter Single Sign On Administrator password:
<ssoserver folder>utilsrsautil.cmd reset-admin-password -m <master password> -u <admin> -p <pass>
The vCenter Single Sign On Administrator password expires by default in 365 days. When you reset this password, reset the vCenter Single Sign On Master Password as well to ensure that they remain the same.
Installation fails when you attempt to install vCenter Single Sign On in an IPv6 environment
When you use the command netsh interface ipv4 uninstall with reboot in a purely IPv6 environment on Windows 2003, 2008, or 2008 R2, vCenter Single Sign On installation fails. The following error occurs: Error 29114. Cannot connect to database. In addition, this error might appear in the install.log file: Error: Failed to access configuration database: Network error IOException: Address family not supported by protocol family: create.
Workaround: Use the FQDN or host name of the vCenter Server system. The best practice is to use the FQDN, which works in all cases, instead of the IP address, which can change if assigned by DHCP. In addition, you must reinstall the IPv4 interface using the following command: netsh interface ipv4 install.
Alternatively, on Windows 2003, 2008, or 2008 R2, navigate to the Change Adapter Settings dialog box and deselect the check box: Internet Protocol Version 4 (TCP/IPv4).
vCenter Single Sign On database installation fails when you use a double quotation mark in your password
When you use a double quote character (') in your Single Sign On password, installation of the Single Sign On database fails. An error message appears when you install Single Sign On SQL Express.
Workaround: Do not use a Single Sign On password that contains a double quotation mark.
vCenter Single Sign On installation fails when the system's host name contains unsupported characters
An error message appears and Single Sign On installation fails when the Single Sign On system's host name contains non-ASCII or high-ASCII characters.
Workaround: Use only ASCII characters for the host names of systems where Single Sign On is installed.
vCenter Single Sign On installation fails when the Single Sign On folder name contains unsupported characters
An error message appears, and Single Sign On installation fails when the Single Sign On build folder name contains non-ASCII or high-ASCII characters.
Workaround: Use only ASCII characters for source folders that contain Single Sign On installer files.
Connection to the MSSQL database fails during vCenter Single Sign On installation
The error message Database connection has failed appears when you install vCenter Single Sign On and you are using manually created MSSQL database users. For MSSQL databases, you must use SQL Server Authentication database users. Windows Authentication users are not supported.
Workaround: Ensure that the manually-created database users are using SQL Server authentication.
Insufficient privileges error occurs when you use manually created DB2 database users
When you install vCenter Single Sign On and the installer requests Single Sign On database information for existing databases, you can select the Use manually created DB users check box. If you are using a DB2 database and have manually created users with the rsaIMSLiteDB2SetupUsers.sql script, you might receive an error that the database users do not have sufficient privileges.
Workaround: The rsaIMSLiteDB2SetupUsers.sql script, which is located in the <installation directory>Single Sign OnDBScriptsSSOServerschemadb2 directory, does not include two of the required privileges. If you use the script to manually create users, edit the script to include the following privileges:
GRANT DBADM ON DATABASE TO USER RSA_DBA;
GRANT CREATETAB ON DATABASE TO USER RSA_USER;
Known issues that affect both installation and upgrade are listed under Installation Issues.
New During upgrade of ESXi 5.0 hosts to ESXi 5.1 with ESXCLI, VMotion and Fault Tolerance (FT) logging settings are lost
On an ESXi 5.0 host, you enable vMotion and FT for a port group. You upgrade the host by running the command
esxcli software profile update. As part of a successful upgrade, the vMotion settings and the logging setings for Fault Tolerance are returned to the default settings, that is, disabled.
Workaround: Use vSphere Upgrade Manager to upgrade the hosts, or return vMotion and Fault Tolerance to their pre-upgrade settings manually.
During upgrade of vSphere Authentication Proxy from version 5.0 to version 5.1 'bad user name or password' warning appears
When you upgrade vSphere Authentication Proxy from version 5.0 to version 5.1, on systems with vCenter Server Heartbeat installed, the installer might display the warning Error 29453 login failed due to bad user name or password. You can ignore the warning and proceed with the installation.
ESXi 5.1 cannot be added to vCenter Server using the named administrator account
When you attempt to add an ESXi 5.1 host to vCenter Server using a named administrator account, a license download error might occur: License file download from <IP address> to vCenter Server failed due to exception: vim.fault.HostConnectFault.
Workaround: Use the root account to add an ESXi 5.1 host to vCenter Server.
System stops responding during TFTP/HTTP transfer when provisioning ESXi 5.1 or 5.0 U1 with Auto Deploy
When provisioning ESXi 5.1 or 5.0 U1 with Auto Deploy on Emulex 10GbE NC553i FlexFabric 2 Ports using the latest open-source gPXE, the system stops responding during TFTP/HTTP transfer.
Emulex 10GbE PCI-E controllers are memory-mapped controllers. The PXE/UNDI stack running on this controller must switch to big real mode from real mode during the PXE TFTP/HTTP transfer to program the device-specific registers located above 1MB in order to send and receive packets through the network. During this process, CPU interrupts are inadvertently enabled, which causes the system to stop responding when other device interrupts are generated during the CPU mode switching.
Workaround: Upgrade the NIC firmware to build 4.1.450.7 or later.
Changes to the number of ports on a standard virtual switch do not take effect until host is rebooted
When you change the number of ports on a standard virtual switch, the changes do not take effect until you reboot the host. This differs from the behavior with a distributed virtual switch, where changes to the number of ports take effect immediately.
When changing the number of ports on a standard virtual switch, ensure that the total number of ports on the host, from both standard and distributed switches, does not exceed 4096.
Prefix- and range-based MAC address allocation is supported only in vCenter Server 5.1 and ESXi 5.1
Prefix- and range-based MAC address allocation is supported only in vCenter Server 5.1 and ESXi 5.1. If you add pre-5.1 hosts to vCenter Server 5.1, and use anything other than VMware OUI prefix- or range-based MAC address allocation, virtual machines assigned MAC addresses that are not VMware OUI prefixed fail to power on their pre-5.1 hosts.
The prefix- and range-based MAC address allocation schemes are not supported on pre-5.1 hosts because pre-5.1 hosts explicitly validate if an assigned MAC address uses the VMware OUI 00:50:56 prefix. If the MAC address is not prefixed with 00:50:56, the virtual machine pre-5.1 host fails to power on.
Do not add pre-5.1 hosts to 5.1 vCenter Server.
If the virtual machine is newly created and is placed on pre-5.1 hosts, edit the virtual machine settings. If the MAC address of the new virtual machine is not prefixed with 00:50:56, change its MAC address to a manual address type and provide another valid MAC address prefixed with 00:50:56. After applying the change, the MAC addresses using non-VMware OUI and VMware OUI prefixes can co-exist in vCenter Server.
Administrative state of a physical NIC not reported properly as down
Administratively setting a physical NIC state to down does not conform to IEEE standards. When a physical NIC is set to down through the virtual switch command, it causes two known problems:
VMware recommends using the using ESXCLI network down
ESXi experiences a traffic increase it cannot handle that wastes network resources at the physical switch fronting ESXi and in resources in ESXi itself.
The NIC behaves in an unexpected way. Operators expect to see the NIC powered down, but the NIC displays as still active.
-n vmnicN command with the following caveats:
This command turns off the driver only. It does not power off the NIC. When the ESXi physical network adapter is viewed from the management interface of the physical switch fronting the ESXi system, the standard switch uplink still appears to be active.
The administrative state of a NIC is not visible in the ESXCLI or UI. You must remember when debugging to check the state by examining /etc/vmware/esx.conf.
The SNMP agent will report administrative state, however it will report incorrectly if the NIC was set to down when the operational state was down to begin with. It reports the admin state correctly if the NIC was set to down when the operational state was active.
Workaround: Change the administrative state on the physical switch fronting the ESXi system to down instead of using the virtual switch command.
vMotion and Storage vMotion for virtual machines on monoflat disks with a snapshot do not function
Monoflat is a disk format that is no longer supported by VMware. Monoflat disks can be powered on when attached to virtual machines, but VMware does not recommend migration of the attached virtual machines. The migration fails when there is a snapshot present.
Workaround: Change to another disk format before attempting migrations. VMware supports Virtual Machine File System (VMFS) disk formats eagerzeroedthick, zeroedthick, thin disk, and 2gbsparse.
Linux driver support changes
Device drivers for vmxnet2 or vmxnet (flexible) virtual NICs are not available for virtual machines running Linux kernel version 3.3 and later.
Workaround: Use a vmxnet3 or e1000 virtual NIC for virtual machines running Linux kernel version 3.3 and later.
vSphere 5.0 network I/O control bandwidth allocation is not distributed fairly across multiple uplinks
In vSphere 5.0, if a networking bandwidth limit is set on a resource pool while using network I/O control, this limit is enforced across a team of uplinks at the host level. This bandwidth cap is implemented by a token distribution algorithm that is not designed to fairly distribute bandwidth between multiple uplinks.
Workaround: vSphere 5.1 network I/O control limits have been narrowed to a per uplink basis.
maxProxySwitchPorts setting not persistent after stateless host reboot
The maximum number of ports on a host is reset to 512 after the host is rebooted and a host profile applied. When you set
maxProxySwitchPorts on a specific stateless host on a distributed switch, the setting might not persist when the host is rebooted. This applies only to stateless hosts that are part of a distributed switch and have had the
maxProxySwitchPorts setting changed.
Workaround: Manually change the
maxProxySwitchPorts settings for the hosts after reboot.
Mirrored Packet Length setting could cause a remote mirroring source session not to function
When you configure a remote mirroring source session with the Mirrored Packet Length option set, the destination does not receive some mirrored packets. However, if you disable the option, packets are again received.
If the Mirrored Packet Length option is set, packets longer than the specified length are truncated and packets are dropped. Lower layer code will not do fragmentation and recalculate checksum for the dropped packets. Two things might cause packets to drop:
The Mirrored Packet Length is greater than the maximum transmission unit (MTU)
If TSO is enabled in your environment, the original packets could be very large. After being truncated by the Mirrored Packet Length, they are still larger than the MTU, so they are dropped by the physical NIC.
Intermediate switches perform L3 check
Some truncated packets can have the wrong packet length and checksum. Some advanced physical switches check L3 information and drop invalid packets. The destination does not receive the packets.
If TCP Segmentation Offload (TSO) is enabled, disable the Mirrored Packet Length option.
You can enable or disable L3 check on some switches, such as Cisco's 4500 series switch. If these switches are in use, disable the L3 check. For switches that cannot be configured, disable the Mirrored Packet Length option.
Enabling more than 16 VMkernel network adapters causes vMotion to fail
vSphere 5.x has a limit of 16 VMkernel network adapters enabled for vMotion per host. If you enable more than 16 VMkernel network adapters for vMotion on a given host, vMotion migrations to or from that host might fail. An error message in the VMkernel logs on ESXi says
Refusing request to initialize 17 stream ip entries, where the number indicates how many VMkernel network adapters you have enabled for vMotion.
Workaround: Disable vMotion VMkernel network adapters until only a total of 16 are enabled for vMotion.
vSphere network core dump does not work when using a nx_nic driver in a VLAN environment
When network core dump is configured on a host that is part of a VLAN, network core dump fails when the NIC uses a QLogic Intelligent Ethernet Adapters driver (nx_nic). Received network core dump packets are not tagged with the correct VLAN tag if the uplink adapter uses nx_nic.
Workaround: Use another uplink adapter with a different driver when configuring network coredump in a VLAN.
Encapsulated remote mirror sessions require the destination IP to be a valid unicast IP
In an encapsulated remote mirror session, a vSphere distributed switch redirects the original traffic to the specified destination IP. If you selected a multicast or broadcast IP address as the destination for the session, the original traffic is mirrored to multiple destinations. This can consume a lot of physical network bandwidth. If you specified an invalid IP address, such as a reserved IP address, the original traffic is not mirrored.
Workaround: Configure valid unicast IP addresses as the destination of encapsulated remote mirror session.
Searching for distributed virtual port groups by private VLAN might return the wrong results in a multiple vCenter Server environment
When you manage multiple vCenter Servers with one instance of the vSphere Web Client, a search for distributed virtual port groups that have specific private VLAN settings might return not only the specific port groups, but also port groups that should not be part of the results.
Workaround: Perform another search.
Naming a network protocol profile with surrogate pair characters results in error
Creating a network protocol profile using surrogate pair characters results in failure and an error message related to UTF-8 handling in the vSphere Web Client.
Workaround: Avoid using surrogate pair characters for network protocol profiles.
If the kickstart file for a scripted installation calls a NIC already in use, the installation fails
If you use a kickstart file to set up a management network post installation, and you call a NIC that is already in use from the kickstart file, you see the following error message:
Sysinfo error on operation returned status: Busy. Please see the VMkernel log for detailed error information.
The error is encountered when you initiate a scripted installation on one system with two NICs: a NIC configured for SWFCoE/SWiSCSI, and a NIC configured for networking. If you use the network NIC to initiate the scripted installation by providing either
BOOTIF=<MAC of the NIC> at boot-options, the kickstart file uses the other NIC,
netdevice=<nic configured for SWFCoE / SWiSCSI>, in the network line to configure the management network.
Installation (partitioning the disks) is successful, but when the installer tries to configure the management-network for the host with the network parameters provided in the kickstart file, it fails because the NIC was in use by
Workaround: Use an available NIC in the kickstart file for setting up a management network after installation.
Unable to join vCenter Server to Linked Mode group
You are unable to join vCenter Server to a Linked Mode group if you changed the vCenter Server HTTPS port during a vCenter Server upgrade.
- Open the vSphere Client.
- Navigate to Administration > vCenter Server Settings > Advanced Settings.
- Select the key named
- In the value field, change the port number in the URL to the one you were given during vCenter Server Upgrade.
- Restart the service
VMware VirtualCenter Server.
- Start the Modify Linked Mode configuration by clicking Start Menu > VMware > vCenter Server Linked Mode Configuration. This option links a vCenter Server to a linked mode group.
Virtual machines running ESX that also use vmxnet3 as the pNIC might crash
Virtual machines running ESX as a guest that also use vmxnet3 as the pNIC might crash because support for vmxnet3 is experimental. The default NIC for an ESX virtual machine is e1000, so this issue is encountered only when you override the default and choose vmxnet3 instead.
Workaround: Use e1000 or e1000e as the pNIC for the ESX virtual machine.
Error message is displayed when a large number of dvPorts is in use
When you power on a virtual machine with dvPort on a host that already has a large number of dvPorts in use, an Out of memory or Out of resources error is displayed. This can also occur when you list the switches on a host using an esxcli command.
Workaround: Increase the dvsLargeHeap size.
- Change the host's advanced configuration option:
- esxcli command: esxcfg-advcfg -s /Net/DVSLargeHeapMaxSize 100
- Virtual Center: Browse to Host configuration -> Software Panel -> Advanced Settings -> Under 'Net', change the DVSLargeHeapMaxSize value from 80 to 100.
- vSphere 5.1 Web Client: Browse to Manage host -> Settings -> Advanced System Settings -> Filter. Change the DVSLargeHeapMaxSize value from 80 to 100.
- Capture a host profile from the host. Associate the profile with the host and update the answer file.
- Reboot the host to confirm the value is applied.
Note: The max value for /Net/DVSLargeHeapMaxSize is 128.
Please contact VMware Support if you face issues during a large deployment after changing /Net/DVSLargeHeapMaxSize to 128 and logs display either of the the following error messages:
Unable to Add Port; Status(bad0006)= Limit exceeded
Failed to get DVS state from vmkernel Status (bad0014)= Out of memory
Standard Switch topology in the vSphere Web Client shows the failover policy for both the switch level and the port group level
The port state icon and the Stand By or Unused label apply to the failover policy at the switch level. When a port group is selected, the orange line applies to the failover policy at the port group level.
Workaround: None. The orange-highlighted physical network adapters are used for port group traffic even if they are labeled Stand By or Unused in the topology.
ESXi fails with Emulex BladeEngine-3 10G NICs (be2net driver)
ESXi might fail on systems that have Emulex BladeEngine-3 10G NICs when a vCDNI-backed network pool is configured using VMware vCloud Director. You must obtain an updated device driver from Emulex when configuring a network pool with this device.
Server Configuration Issues
New Unable to create or expand a VMFS datastore using the vSphere Client in Japanese
When running the vSphere Client on a Windows system with the locale set to Japanese, attempting to create a VMFS datastore or access datastore properties produces an error message stating that the format of the entered string is invalid.
Workaround: Do one of the following:
- Create or edit the VMFS datastore using the vSphere Web Client.
- Change the Windows locale from Japanese to another locale on the vSphere Client system.
- Force the vSphere Client to use English as described in KB 1020512: Changing the language used by the vSphere Client.
New Storage device names using non-ASCII or high-ASCII characters appear as unreadable in the vSphere Web Client UI
During OVF deployment, the names of storage devices named with non-ASCII or high-ASCII characters appear garbled or unreadable in the vSphere Web Client UI.
Workaround: Name storage devices using ASCII characters only.
Virtual machine observed datastore latency
You might see incorrect virtual machine observed datastore latency values when running SDRS or SIOC on a datastore connected to a combination of ESXi 5.0 and ESXi 5.1 hosts. ESXi 5.1 collects a new statistic called 'virtual machine observed datastore latency' which is not collected in ESXi 5.0. Because of this difference, it is not possible to correctly average statistics values between a mixture of ESXi 5.0 and ESXi 5.1 hosts. This can also result in less aggressive SDRS I/O load balancing behavior when a datastore cluster has datastores mounted with a combination of ESXi 5.0 and ESXi 5.1 hosts compared to a datastore cluster with only ESXi 5.1 hosts.
Workaround: Upgrade all hosts to ESXi 5.1.
Enabling historic performance charts for datastores and datastore clusters in a Storage DRS environment
In a vSphere 5.1 environment, if you have the Collection Level for the statistics set to the default of 1, only real-time performance charts are displayed for Storage DRS data counters related to datastore and datastore cluster metrics. If you select a different time interval, the chart displays No data available. This is the result of many datastore and datastore cluster metrics having been moved to Stats Collection Level 3, by default, in order to improve performance.
Workaround: To enable historic performance charts for datastore and datastore cluster metrics, move the Storage DRS counters to Stats Collection Level 1. For more information, see the Knowledge Base article 2009532. Be aware that changes in the counter levels may cause a significant increase in data collection and storage, along with a corresponding decrease in performance. For more information, see Modifying Performance Counter Collection Levels in the vSphere Web Services Programming Guide and the vSphere API Reference.
VMFS5 datastore creation might fail when you use an EMC Symmetrix VMAX/VMAXe storage array
If your ESXi host is connected to a VMAX/VMAXe array, you might not be able to create a VMFS5 datastore on a LUN presented from the array. If this is the case, the following error will appear: An error occurred during host configuration. The error is a result of the ATS (VAAI) portion of the Symmetrix Enginuity Microcode (VMAX 5875.x) preventing a new datastore on a previously unwritten LUN.
- Disable Hardware Accelerated Locking on the ESXi host.
- Create a VMFS5 datastore.
- Reenable Hardware Accelerated Locking on the host.
Use the following tasks to disable and reenable the Hardware Accelerated Locking parameter.
In the vSphere Web Client
- Browse to the host in the vSphere Web Client navigator.
- Click the Manage tab, and click Settings.
- Under System, click Advanced System Settings.
- Select VMFS3.HardwareAcceleratedLocking and click the Edit icon.
- Change the value of the VMFS3.HardwareAcceleratedLocking parameter:
In the vSphere Client
- In the vSphere Client inventory panel, select the host.
- Click the Configuration tab, and click Advanced Settings under Software.
- Change the value of the VMFS3.HardwareAcceleratedLocking parameter:
Attempts to create a GPT partition on a blank disk might fail when using Storagesystem::updateDiskPartitions()
You can use the Storagesystem::computeDiskPartitionInfo API to retrieve disk specification, and then use the disk specification to label the disk and create a partition with Storagesystem::updateDiskPartitions(). However, if the disk is initially blank and the target disk format is GPT, your attempts to create the partition might fail.
Workaround: Use DatastoreSystem::createVmfsDatastore instead to label and partition a blank disk, and to create a VMFS5 datastore.
Updated Storage vMotion might fail with an error message
When storage configuration is overloaded and stressed, a file on a VMFS datastore might take much longer to open. This delay can cause Storage vMotion of a virtual machine to fail with the error message A parent disk path is required for snapshot of disk /path/to/disk/XXX.vmdk.
Workaround: Use one of the following methods to reload the virtual machine disk information and then perform Storage vMotion again.
- Create a dummy snapshot and then immediately remove it.
- Migrate the virtual machine to another host. Do not change the datastore.
- After powering off the virtual machine, detach the virtual disk and then reattach it again.
- After powering off the virtual machine, unregister the virtual machine and then register it again.
- Restart the management agent via DCUI, or by executing /etc/init.d/hostd restart.
To avoid the Storage vMotion failure when the storage array is stressed and slow, edit the following option in the /etc/vmware/config file to increase the number of open disk retries: diskLibMiscOptions.openRetries = large number, such as 99.
Attempts to create a diagnostic partition on a GPT disk might fail
If a GPT disk has no partitions, or the tailing portion of the disk is empty, you might not be able to create a diagnostic partition on the disk.
Workaround: Avoid using GPT-formatted disks for diagnostic partitions. If you must use an existing blank GPT disk for the diagnostic partition, convert the disk to the MBR format.
- Create a VMFS3 datastore on the disk.
- Remove the datastore.
The disk format changes from GPT to MBR.
ESXi cannot boot from a FCoE LUN that is larger than 2TB and accessed through an Intel FCoE NIC
When you install ESXi on a FCoE boot LUN that is larger than 2TB and is accessed through an Intel FCoE NIC, the installation might succeed. However, when you try to boot your ESXi host, the boot fails. You see the error messages: ERROR: No suitable geometry for this disk capacity! and ERROR: Failed to connect to any configured disk! at BIOS time.
Workaround: Do not install ESXi on a FCoE LUN larger than 2TB if it is connected to the Intel FCoE NIC configured for FCoE boot. Install ESXi on a FCoE LUN that is smaller than 2TB.
vCenter Server and vSphere Client Issues
New High package loss might occur when two ESXi systems have the same MAC address
When you install ESXi on a Dell r720 server, incorrect or duplicated MAC addresses are assigned on the embedded Intel I350 network interface.
Workaround: Apply the following patch to the server: https://my.vmware.com/group/vmware/details?downloadGroup=DT-ESXI50-INTEL-igb-3210&productId=231.
New Validating host customizations fails while editing host profiles
You might receive the following error while validating host customizations from the Host Profile editor:
Cannot validate host customizations for host.
This error might occur when old host customization values are saved in vCenter Server, such as, when a host was previously assigned to an old host profile with a different configuration.
Workaround: Perform the following to reset the host customizations:
- Right-click the host listed in the error.
- Select All vCenter Actions >Host Profiles >Reset Host Customizations.
Applying host profiles might fail when accessing VMFS folders through console
If a user is accessing the VMFS datastore folder through the console at the same time a host profile is being applied to the host, the remediation or apply task might fail. This failure occurs when stateless caching is enabled on the host profile or if an auto deploy installation occurred.
Workaround: Do not access the VMFS datastore through the console while remediating the host profile.
Leading white space in login banner causes host profile compliance failure
When you edit a host profile and change the text for the Login Banner (Message of the Day) option, but add a leading white space in the banner text, a compliance error occurs when the profile is applied. The compliance error Login banner has been modified appears.
Workaround: Edit the host profile and remove the leading white space from the Login Banner policy option.
Host Profile extracted from ESXi 5.0 host fails to apply to ESX 5.1 host with Active Directory enabled
When applying a Host Profile with Active Directory enabled that was originally extracted from an ESXi 5.0 host to an ESX 5.1 host, the apply task fails. Setting the maximum memory size for the likewise system resource pool might cause an error to occur. When Active Directory is enabled, the services in the likewise system resource pool consume more than the default maximum memory limit for ESXi 5.0 captured in an ESXi 5.0 host profile. As a result, applying an ESXi 5.0 host profile fails during attempts to set the maximum memory limit to the ESXi 5.0 levels.
Workaround: Perform one of the following:
- Manually edit the host profile to increase the maximum memory limit for the likewise group.
- From the host profile editor, navigate to the Resource Pool folder, and view host/vim/vmvisor/plugins/likewise.
- Modify the Maximum Memory (MB) setting from 20 (the ESXi 5.0 default) to 25 (the ESXi 5.1 default).
- Disable the subprofile for the likewise group. Do one of the following:
- In the vSphere Web Client, edit the host profile and deselect the checkbox for the Resource Pool folder. This action disables all resource pool management. You can disable this specifically for the host/vim/vmvisor/plugins/likewise item under the Resource Pool folder.
- In the vSphere Client, right-click the host profile and select Enable/Disable Profile Configuration... from the menu.
Host gateway deleted and compliance failures occur when ESXi 5.0.x host profile re-applied to stateful ESXi 5.1 host
When an ESXi 5.0.x host profile is applied to a freshly installed ESXi 5.1 host, the profile compliance status is noncompliant. After applying the same profile again, it deletes the host's gateway IP and the compliance status continues to show as noncompliant with the IP route configuration doesn't match the specification status message.
Workaround: Perform one of the following workarounds:
- Login to the host through DCUI and add the default gateway manually with the following esxcli command:
esxcli network ip route ipv4 add --gateway xx.xx.xx.xx --network yy.yy.yy.yy
- Extract a new host profile from the ESX 5.1 host after applying the ESX 5.0 host profile once. Migrate the ESX 5.1 host to the new ESX 5.1-based host profile.
Compliance errors might occur after stateless caching enabled on USB disk
When stateless caching to USB disks is enabled on a host profile, compliance errors might occur after remediation. After rebooting the host so that the remediated changes are applied, the stateless caching is successful, but compliance failures continue.
Workaround: No workaround is available.
Hosts with large number of datastores time out while applying host profile with stateless caching enabled
A host that has a large number of datastores times out when applying a host profile with stateless caching enabled.
Workaround: Use the vSphere Client to increase the timeout:
- Select Administrator >vCenter Server Settings.
- Select Timeout Settings.
- Change the values for
Network policy compliance failures continue for host profiles created from ESXi 4.1 or ESXi 4.0 hosts applied to ESXi 5.1 hosts
After applying a host profile created from an ESXi 4.1 or ESXi 4.0 host to an ESXi 5.1 host, the following host profile compliance failures might continue:
For port group [PORT GROUP NAME] network policy property spec.policy.nicTeaming.failureCriteria doesn't match
For port group [PORT GROUP NAME] network policy property spec.policy.nicTeaming.reversePolicy doesn't match
The above network settings are not supported on ESXi 5.1 hosts and are no longer configured when applying a host profile containing those settings.
Workaround: Two possible remedies are available:
- After applying the host profile originally created from an ESXi 4.1 host to an ESXi 5.1 host, create a new host profile from the ESXi 5.1 host and attach that to that ESXi 5.1 host and other affected ESXi 5.1 hosts.
- Modify the NIC Teaming policy in the host profile to the User must explicitly choose the policy option option instead of the Apply specified NIC teaming policy.
Cannot extract host profile from host when IPv4 is disabled on vmknics
If you remove all IPv4 addresses from all vmknics, you cannot extract a host profile from that host. This action affects hosts provisioned with auto-deploy the most, as Host Profiles is the only way to save the host configuration in this environment.
Workaround: Assign as least one vmknic to one IPv4 address.
Applying host profile fails when applying a host profile extracted from an ESXi 4.1 host on an ESXi 5.1 host
If you set up a host with ESXi 4.1, extract a host profile from this host (with vCenter Server), and attempt to attach a profile to an ESXi 5.1 host, the operation fails when you attempt to apply the profile. You might receive the following error: NTP service turned off.
The NTPD service could be running (on state) even without providing an NTP server in /etc/ntp.conf for ESXi 4.1. ESXi 5.1 needs an explicit NTP server for the service to run.
Workaround: Turn on the NTP service by adding a valid NTP server in /etc/ntp.conf and restart the NTP daemon on the 5.1 host. Confirm that the service persists after the reboot. This action ensures the NTP service is synched for the host and the profile being applied to it.
Host profile shows noncompliant after profile successfully applied
This problem occurs when extracting a host profile from an ESXi 5.0 host and applying it to an ESXi 5.1 host that contains a local SAS device. Even when the host profile remediation is successful, the host profile compliance shows as noncompliant.
You might receive errors similar to the following:
- Specification state absent from host: device naa.500000e014ab4f70 Path Selection Policy needs to be set to VMW_PSP_FIXED
- Specification state absent from host: device naa.500000e014ab4f70 parameters needs to be set to State = on' Queue Full Sample Size = '0' Queue Full Threshold = '0'
The ESXi 5.1 host profile storage plugin filters out local SAS device for PSA and NMP device configuration, while ESXi 5.0 contains such device configurations. This results in a missing device when applying the older host profile to a newer host.
Workaround: Manually edit the host profile, and remove the PSA and NMP device configuration entries for all local SAS devices. You can determine if a device is a local SAS by entering the following esxcli command:
esxcli storage core device list
If the following line is returned, the device is a local SAS:
Is Local SAS Device
Host profile compliance errors occur when removing ESXi hosts from vCenter Server inventory
While checking host profile compliance, vCenter Server sometimes needs to query an ESXi host for data related to Host Profiles. The target host for the compliance check operation is not necessarily the ESXi host that vCenter Server uses for these Host Profile data queries. A race condition exists when a customer removes an ESXi host from the vCenter Server inventory and performs a compliance check operation at the same time. During this time, a query for Host Profile data results in an error with the message Host Unavailable For Checking Compliance.
Workaround: After removing the host from the vCenter Server inventory, check the host profile compliance again. vCenter Server attempts to use a different host to query for Host Profile data.
Default system services always start on ESXi hosts provisioned with Auto Deploy
For ESXi hosts provisioned with Auto Deploy, the Service Startup Policy in the Service Configuration section of the associated host profile is not fully honored. In particular, if one of the services that is turned on by default on ESXi has a Startup Policy value of off, that service still starts at the boot time on the ESXi host provisioned with Auto Deploy.
Workaround: Manually stop the service after booting the ESXi host.
Host Profile compliance failures for Firewall Rulesets might occur after remediating ESXi 5.1 host with ESXi 5.0 host profile
When checking compliance using a host profile created from an ESXi 5.0 host, you might see compliance failures related to the CIMHttpsService and CIMHttpService.
In some cases, a mismatch in a host profile might exist between the enabled state of the Firewall Rulesets for the CIM/WBEM services (CIMHttpService and CIMHttpsService) and the Service Startup Policy for the CIM/WBEM service (sfcb-watchdog). When the service starts, the firewall ports automatically open. This results in the compliance failure for the CIM service firewall rulesets.
Workaround: Perform one of the following workarounds.
- Make the host profile consistent by editing the Firewall Ruleset subprofiles for CIMHttpService and CIMHttpsService in the host profile so that the enabled parameter is True.
- Go to the Security Profile configuration of the ESXi host from which the host profile was created (or the new reference host, if it has changed since creation), and manually refresh the Firewall info. Then, perform a Update host profile from reference host operation.
Alternatively, if you are using the vSphere Web Client, perform the 'Copy Settings From Host' operation to update the host profile.
Information retrieval from VMWARE-VMINFO-MIB does not happen correctly after an snmpd restart
Some information from VMWARE-VMINFO-MIB might be missing during SNMPWalk after you restart the snmpd daemon using /etc/init.d/snmpd restart from the ESXi Shell.
Workaround: Do not use /etc/init.d/snmpd restart. You must use the esxcli system snmp set --enable command to start or stop the SNMP daemon. If you used /etc/init.d/snmpd restart to restart snmpd from the ESXi Shell, restart Hostd, either from DCUI or by using /etc/init.d/hostd restart from the ESXi Shell.
Virtual Machine Management Issues
New Data for multi-selected virtual machines loads slowly in the vSphere Web Client
In the vSphere Web Client, if you select a large number of virtual machines in a list by pressing Ctrl+A, Shift+End, or Shift+Home, the virtual machine data might take longer than expected to load.
Workaround: Press Esc to cancel the multi-select operation.
New Unable to power on a virtual machine in the vSphere Web Client
If you power off a virtual machine from within the guest operating system, the virtual machine's state might not be updated in the vSphere Web Client. If you then attempt to power on the virtual machine, the operation fails with the error message: This action is not available for any of the selected objects at this time.
Click the refresh button in the vSphere Web Client and repeat the power on operation.
Updated Active Directory users with customized UPN user names cannot use Windows session credentials to log into the vSphere Web Client
Active Directory users might have a custom suffix in their UPN instead of using the domain name as the suffix. For example, the user name [email protected] can be customized to be [email protected] Active Directory users with these custom suffixes cannot log into the vSphere Web Client using Windows session credentials when vCenter Single Sign On is installed on a Windows system.
Users who log in with a smartcard whose UPN includes a custom suffix might not be provided their Windows system user name and password. For example, because CAC smartcard users always log in with the smartcard, they are not provided with their Windows credentials. These users cannot log in to a vSphere environment if Single Sign On is enabled with the Use Windows Credentials feature.
Workaround: When vCenter Single Sign On is installed on a Windows system, Active Directory users with custom suffixes must log into the vSphere Web Client by entering their user name and password, where the user name has the non-customized domain name as a suffix. This workaround is only valid for users who know their Windows system credentials.
Enabling or Disabling View Storage Accelerator might cause ESXi hosts to lose connectivity to vCenter Server
If VMware View is deployed with vSphere 5.1, and a View administrator enables or disables View Storage Accelerator in a desktop pool, ESXi 5.1 hosts might lose connectivity to vCenter Server 5.1.
The View Storage Accelerator feature is also called Content Based Read Caching. In the View 5.1 View Administrator console, the feature is called Host caching.
Workaround: Do not enable or disable View Storage Accelerator in View environments deployed with vSphere 5.1.
The vCenter Server Appliance Web interface does not work in Firefox 14
In Firefox 14 or later, the Administration, Services, and Storage tabs do not appear in the vCenter Server Appliance Web interface. The Admin page appears but is blank. This prevents configuration of the Active Directory membership and other settings.
Workaround: Use another supported browser, or use the Firefox Extended Support Release, which is based on Firefox 10 and can be downloaded from http://www.mozilla.org/en-US/firefox/organizations/all.html.
Uninstalled plug-ins appear in the vSphere Web Client Plug-in Management interface
If you uninstall a currently-loaded vSphere Web Client plug-in, the Plug-in Management Interface continues to show the plug-in until the Web server is restarted. The plug-in functionality itself is no longer available in the vSphere Web Client.
Workaround: Restart the Web server.
Virtual machine console in the vSphere Web Client is not responsive to mouse input
For virtual machines running some Linux distributions, the console might not initially respond to mouse input when you launch the console from the vSphere Web Client.
Workaround: Click Full Screen to switch the console to full screen mode.
A Web browser context menu appears when right-clicking an object in the vSphere Web Client inventory.
When using Windows 8 with Internet Explorer 10, when you navigate to an object in the vSphere Web Client inventory and right-click, the browser context menu is displayed over the object's context menu. .
Workaround: Right-click somewhere else in the application to allow the object's context menu to be displayed.
Unable to delete folder
If you have the Folder.Delete folder permission defined at the folder level only, attempting to remove that folder produces an error message stating that you do not have the correct permissions.
Failed to read request errors in vpxd.log
Error messages similar to the following might appear in vpxd.log:
2012-05-15T08:41:03.120Z [7F7DCB7C6700 error 'QsAdapter.HTTPService'] Failed to read request; stream: UNIX(/var/run/vmware/vpxd-qsadapter-pipe), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
2012-05-15T08:41:03.120Z [7F7DCB889700 error 'SoapAdapter.HTTPService'] Failed to read request; stream: TCP(), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
2012-05-15T08:41:33.124Z [7F7DCB5BE700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
2012-05-15T08:41:48.125Z [7F7DCB57D700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
2012-05-15T08:41:48.125Z [7F7DCAD75700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
2012-05-15T08:41:58.127Z [7F7DCBC58700 error 'SoapAdapter.HTTPService'] Failed to read request; stream: TCP(), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
These log entries are not real errors and are indicative only of an attempt to connect to an external service that is not running.
Tag names cannot contain surrogate pair characters
If you attempt to create a tag with a name containing surrogate pair characters, the tag creation fails.
Workaround: Do not use surrogate pair characters in tag names.
Changes to the host name of the vCenter Server system are not reflected in the vSphere Web Client or vSphere Web Client inventory
If you change the host name of a vCenter Server system or vCenter Server Appliance, the local machine shows the new host name, but the old name appears in the vSphere Web Client and vSphere Client inventory.
Workaround: Use the vSphere Web Client or vSphere Client to change the display name of the vCenter Server system.
In the vSphere Web Client, do the following:
- Navigate to the vCenter Server instance and select the Manage tab.
- Under Settings, click General.
- In the Edit vCenter Server Settings dialog box, select Runtime Settings.
- In vCenter Server name, type the name for the vCenter Server system.
- Click OK.
In the vSphere Client, do the following:
- Select Administration > vCenter Server Settings.
- If the vCenter Server system is part of a Linked Mode group, select the server to configure from the Current vCenter Server drop-down list.
Note: Linked Mode is not supported on the vCenter Server Appliance.
- In the navigation panel, select Runtime Settings.
- In vCenter Server Name, type the name for the vCenter Server system.
- Click OK.
The vSphere Web Client becomes unresponsive when running multiple operations
When you perform operations affecting multiple virtual machines, such as powering on or powering off multiple virtual machines, the vSphere Web Client might become unresponsive until tasks complete. This is due to a limitation in Flash on how many tasks can run in parallel. The vSphere Web Client will become responsive when all tasks are sent to the server.
Backup of the Inventory Service database fails
A backup of the Inventory Service database while the Inventory Service is running fails due to a bad_certificate error.
Workaround: Shut down the inventory service before taking a backup.
On a Windows system, do the following:
- Stop the Inventory Service:
- Open the Windows Administrative Tools control panel and select Services.
- Right-click VMware vCenter Inventory Service and select Stop.
- Open the command prompt and change to the directory vCenter_Server_installation_directoryInfrastructureInventory Servicescripts.
vCenter_Server_installation_directory is the directory where you installed vCenter Server. By default, this is C:VMware.
- Run the following command at the prompt to back up the Inventory Service database: backup.bat -file backup_file_name.
On a vCenter Server Appliance, do the following:
- Open a console and run the service vmware-inventory service stop command to stop the Inventory Service.
- Change the directory to /usr/lib/vmware-vpx/inventoryservice/scripts/.
- Run the following command to back up the Inventory Service database: ./backup.sh -file backup_file_name.
Cannot add an ESXi host to the vCenter Server Appliance using the local-link IPv6 address
If you try to add an ESXi host to the vCenter Server Appliance using a local-link IPv6 address of the form fe80::*, you see the error message, Cannot contact the specified host.
Workaround: Use a valid IPv6 address for the host that is not a local-link address.
Enabling DRS for a cluster produces an erroneous warning about DPM being enabled
If you resume an Edit Cluster Services task from the Work in Progress pane and enable DRS, you might see a message incorrectly stating that DPM will be enabled. This occurs after you log out of and log back into the vSphere Web Client while the Edit Cluster Services task is saved to the Work in Progress pane.
Workaround: No workaround is required. DPM will not be enabled.
Search fails and Hardware Health and Health Status plug-ins are disabled in the vSphere Client
The vSphere Client does not connect to the inventory service when installed on Windows 2003 or Windows XP. This has the following effects:
- When you try to search the vSphere Client inventory, you see the error message, Login to the query service failed. A communication error occurred while sending data to the server. (The underlying connection was closed: An unexpected error occurred on a send.)
- Hardware Health and Health Status plug-ins are disabled and cannot be viewed in the vSphere Client.
Workaround: No workaround is available for 32-bit Windows XP. For Windows 2003 or 64-bit Windows XP, apply the appropriate hotfix as listed below.
vCenter Server and vCenter Single Sign On services fail to start
When you change the host name or port assignment of the Single Sign On database server, Single Sign On fails. As a result, vCenter Server fails to start. This issue can also occur when you use SQL Server Express Edition, which is installed with Single Sign On and vCenter Server. If SQL Server Express Edition is configured to use dynamic ports, the port assignment might change when you reboot the system. This occurs when the port is already occupied by another service.
Workaround: When you change the host name or port of the Single Sign On database server, you must reconfigure Single Sign On with the new host name or port.
- Stop the vCenter Single Sign On server.
- Enter the following command:
<ssoserver folder>utils> ssocli configure-riat -a configure-db --database-host <new database server> --database-port <new database port> -m <master password>
- Edit the following text file to replace the port number with the new value in the line that begins with db.url=:
- Start the vCenter Single Sign On server.
Attaching an Oracle database to vCenter Server Appliance produces an error about incompatible schema
If you attempt to configure the vCenter Server Appliance with an external Oracle database that was used previously with a vCenter Server 5.0 Appliance, you see the error message, Error: Incompatible DB schema version.
Workaround: You can use the vCenter Server Appliance setup wizard to reset the database. Doing so will destroy all records currently in the database. To keep the records in the database, follow the upgrade process as described in the vSphere Upgrade documentation to upgrade the vCenter Server Appliance and database from vCenter Server 5.0 to vCenter Server 5.1.
To reset the database:
- Log in to the vCenter Server Appliance Web interface and start the setup wizard.
- Enter the database information.
The wizard displays the message, The database has been initialized with an incompatible schema version.
- Select reset the DB contents.
Errors related to python scripts appear when an invalid configuration file is uploaded to the vCenter Server Appliance configuration wizard
In the vCenter Server Appliance initial configuration wizard, if you select Upload configuration file and select an invalid file, the Web interface displays errors related to python scripts.
Login or navigation errors after upgrading a vCenter Server Appliance with a static IP address
After upgrading a vCenter Server Appliance with a static IP address, you might experience the following errors:
- When you attempt to log in to the vCenter Server Appliance Web interface, you might see the error, Unable to connect to server. Please try again.
- When you attempt to navigate to a new page in the vCenter Server Appliance Web interface, you might see the error, Not Found.
Workaround: Clear the browser cache and log in to the vCenter Server Appliance Web interface again.
Active Directory is not discovered as an identity source if the vCenter Server Appliance is joined to an Active Directory domain before vCenter Single Sign On is started
This might occur when the vCenter Server Appliance is joined to an Active Directory domain as part of its initial configuration through the Web interface configuration wizard. After the configuration, the related vCenter Server and vCenter Single Sign On services might work, but Active Directory is not discovered as an identity source.
Workaround: Do one of the following.
- Restart the vCenter Server Appliance.
- Restart vCenter Single Sign On, followed by the vSphere Web Client service.
Unable to reconfigure vCenter Server Appliance settings that failed on initial configuration
The first time you log in to the vCenter Server Appliance, the initial configuration wizard prompts you to accept the EULA and configure database options, vCenter Single Sign On, and Active Directory. If any of these steps fail, the configuration wizard completes the remaining steps and starts the vCenter Server service.
If you attempt to reconfigure any of the settings that the wizard failed to configure, you see the message, Error: VPXD must be stopped to perform this operation.
Workaround: Do the following:
- Log in to the vCenter Server Appliance console, and execute the following command: /etc/init.d/vmware-vpxd stop
- Log in to the vCenter Server Appliance Web interface and reconfigure the settings as needed.
- Restart the vCenter Server service using the Web interface.
The related item listed in the Advanced Search results might not be the item specified in the search criteria
When you perform an Advanced Search in the vSphere Web Client and specify a relationship between objects, the search results are correct, but the related object shown in the results might not be the object that you specified in the search criteria.
For example, if you search for all folders that have a host whose name contains example, the correct list of folders appears in the search results. However, the host listed in the related objects column might not be the host whose name contains example, but a host with a different name that is also located in that folder.
Some Chinese or Japanese characters do not display correctly in the vSphere Web Client
When you access the vSphere Web Client from a Linux system with the default language set to Chinese or Japanese, some text in the vSphere Web Client is displayed as rectangular boxes instead of the correct Chinese or Japanese characters.
Workaround: Install Linux with the default language set to English, and change the default language to Chinese or Japanese after installation.
The initial configuration wizard for the vCenter Server Appliance does not support static IP address configuration
When you log in to the vCenter Server Appliance Web interface for the first time after deployment, the configuration wizard starts and prompts you to accept the EULA and configure database options, vCenter Single Sign On, and Active Directory. The wizard does not present network configuration options. The vCenter Server Appliance is configured to use DHCP by default.
Workaround: If you completed the initial configuration wizard, changing to a static network configuration requires changing the SSL certificate of the appliance:
- On the Admin page of the vCenter Server Appliance Web interface, click the Toggle certificate setting button to change the Certificate regeneration enabled option to Yes.
- Configure the static IP address for the vCenter Server Appliance.
If you have not yet completed the initial configuration wizard, do the following:
- Log in to the vCenter Server Appliance Web interface.
- Accept the EULA and then click Cancel.
- Configure the network.
If you change the host name or IP address, you will be disconnected from the Web interface. Log in again using the new host name or IP address.
- On the vCenter Server page, click the Summary tab.
- Click the Launch button next to Setup wizard. Complete the setup wizard to finish the initial configuration of the appliance.
If you use vCenter Server to deploy the vCenter Server Appliance as an OVF, you can configure a static IP address during deployment. However, this applies only to environments that have a vCenter Server instance deployed.
Host name cannot be changed in vCenter Server Appliance Web interface
Attempting to change the host name in the vCenter Server Appliance Web interface might fail. This issue occurs when an appliance is configured to use a static IP address and host name. From the Network' tab, if you edit both the host name and IP address and then save these settings, only the IP address changes. The host name remains unchanged.
Workaround: If you need to change both the host name and the IP address, make the changes in two separate operations.
Changing MTU for independent hardware iSCSI in the vSphere Client requires that you enable Jumbo Frames first
When you use the vSphere Client to modify the MTU parameter on the Advanced Settings dialog box, you need to check the Jumbo Frame box first. Otherwise, the MTU change does not propagate to the independent hardware adapter. In the vSphere Web Client, the Jumbo Frame box is not present, so you change the value in the MTU input box.
In the vSphere Client:
In the vSphere Web Client:
- Select a host from the inventory panel.
- Click the Configuration tab and click Storage Adapters in the Hardware panel.
- Select an independent hardware adapter from the list of storage adapters.
- Click Properties, and click Advanced.
- Enable Jumbo Frames by checking the Jumbo Frame box.
- Edit the value in the MTU entry box and click OK.
Note: If you enable Jumbo Frames, but for the MTU size enter the value that does not exceed 1500 Bytes, the Jumbo Frames enablement is ignored.
- Browse to the host in the vSphere Web Client object navigator.
- Click the Manage tab, and click Storage.
- Click Storage Adapters, and select the independent hardware iSCSI adapter from the list of adapters.
- Under Adapter Details, click the Advanced Options tab and click Edit.
- Change the value of the MTU parameter.
Cannot log in to vCenter Server after you replace SSL certificates
After you replace the SSL certificates for vCenter Server, you might not be able to log in to the server. This is because vCenter Server is not restarted when you replace SSL certificates. You must restart the server to refresh the certificate for Single Sign On.
Workaround: Restart vCenter Server after you replace SSL certificates.
Java IO exception appears in log file when you start vCenter Single Sign On on vCenter Server Appliance
When you start vCenter Single Sign On on a vCenter Server Appliance, a Java IO exception might appear in /var/log/vmware/sso/catalina.out.
For example: java.io.IOException: ClientAbortException: java.net.SocketException: Broken pipe
In addition, when you stop the Single Sign On server on the vCenter Server Appliance, a memory leak error might appear in /var/log/vmware/sso/catalina.out.
For example:SEVERE: The web application [/ims] appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak.
vCenter Server might fail to start or you cannot log in to the vSphere Web Client after you restart the Single Sign On server system
When you restart the machine where vCenter Single Sign On is installed, changes to the system might occur. For example, updates are applied to the operating system, the machine name changes, or the machine is added or removed from an Active Directory domain. These changes might cause the Single Sign On server to become unresponsive, even though Single Sign On is running. As a result, vCenter Server does not start. This can also happen if you clone or change the parameters of a virtual machine where Single Sign On is installed (for example, the amount of RAM, the number of CPUs, the MAC address, and so on).
Workaround: Perform the following steps.
- On the system where Single Sign On is installed, locate the Single Sign On installation directory and run the following command from the utils folder:
rsautil manage-secrets -a recover -m masterPassword
- Restart the Single Sign On service.
- Start the vCenter Server service.
Active Directory domain to which vCenter Server system belongs does not appear in the Single Sign On server list of identity sources
On Windows, if vCenter Server is installed on a machine that is joined to an Active Directory domain, the domain users do not appear in the vSphere Client or the vSphere Web Client. On Linux, the error message Unable to retrieve domain user appears.
Workaround: Configure a reverse forward lookup zone, a related pointer record, and synchronize the system clock.
- To add a reverse forward lookup zone in the DC controller, see Adding a Reverse Lookup Zone on the Microsoft Web site.
- To synchronize the clock, see Kerberos Troubleshooting Tips on the Microsoft Web site.
The vCenter Server appliance does not support Active Directory configuration using IPv6
If you attempt to configure Active Directory on the vCenter Server appliance using IPv6, the configuration fails.
Workaround: Configure Active Directory on the vCenter Server appliance using IPv4.
Storage profiles previously created on the vCenter Server Appliance are not visible after backup and restore of the Inventory Service database
After you back up and restore the Inventory Service database, storage profiles that you previously created on the vCenter Server Appliance are not visible.
- Log in to the vCenter Server Appliance Web console at https://ip-address-of-appliance:5480.
- Restart the vmware-SPS service.
When the service is restarted, storage profiles are visible again.
The vCenter Server Appliance does not support IPv6 addresses in the proxy setting
If you attempt to enter an IPv6 address for the proxy setting on the vCenter Server Appliance Web console Networking page, the configuration fails.
Workaround: Use an IPv4 address for the proxy setting for the vCenter Server Appliance.
The vSphere Web Client login page takes several minutes to open after certain operations
Typically, when you open the vSphere Web Client URL in a browser, you can expect the login page to open immediately. But if you just completed the installation, or if you restart the vSphere Web Client service, or configure the vCenter Server Appliance, the login page does not open immediately. You might see a blank page for a few minutes followed by an HTTP 404 page.
Workaround: Wait for few minutes and try refreshing the page again. If after 2-4 minutes, you refresh the page, the login page opens correctly.
On Linux systems, the font appears incorrectly on some vSphere Web Client pages
The Linux and UNIX shell (*nix/*nux) Web hosting services do not apply the Adobe Flex Spark skins correctly on some vSphere Web Client pages. For example, bold fonts in titles do not appear as bold.
Workaround: Install the Microsoft True Type Core Fonts, msttcorefonts, for your operating system. For example, on Ubuntu systems, type sudo apt-get install msttcorefonts at the command prompt.
Cannot log into the vSphere Web Client with Windows session credentials
The vSphere Web Client does not support logging in with Windows session credentials when you are logged into Windows as a local operating system user. When you log into the vSphere Web Client with Windows session credentials, you must be an Active Directory user of a domain which exists as an identity source in vCenter Single Sign On.
Note: Logging in with Windows session credentials is not supported for vCenter Server 5.0 systems.
Workaround: To use Windows session credentials to log into the vSphere Web Client from a browser on a Windows system, you must log into the Windows system as an Active Directory user of a domain which exists as an identity source in vCenter Single Sign On.
When you click Log Browser in the vSphere Web Client, an Unauthorized Access error appears
When you click the Log Browser link in the vSphere Web Client, an error message appears: Exception: https://<system-address>:12443/vmwb/logbrowser: Unauthorized access. This error occurs after you replace the default vCenter Single Sign On server's SSL certificate, either directly or by regenerating the certificate in the vCenter Server Appliance.
- Log in to the vSphere Web Client as a Single Sign On administrator.
- Navigate to Administration > Sign-on and Discovery > Configuration, and click the STS Certificate tab.
- Click Edit.
- Select the Single Sign On SSL keystore.
- If Single Sign On is running on a Windows system, select the following file:
C:Program FilesVMwareInfrastructureSSOServersecurityserver-identity.jks (default path)
- If Single Sign On is running on Linux (vCenter Server Appliance), select the following file:
/usr/lib/vmware-sso/security/server.jks (default path)
- Open the Single Sign On server.xml file with a text editor or browser.
- On Windows:
C:Program FilesVMwareInfrastructureSSOServerconfserver.xml (default path)
- On Linux:
/usr/lib/vmware-sso/conf/server.xml (default path)
- Search for keystorePass='...' on the Connector element. The string in quotes is your password.
- Enter the password in the vSphere Web Client when prompted.
- Select only the displayed chain.
- Click OK and enter the password again.
- Restart the following services: the vSphere Web Client, vCenter Server, vCenter Inventory Service, and the VMware Log Browser. You do not need to restart Single Sign On.
Authentication fails when vCenter Single Sign On system (System-Domain) users attempt to log into the vSphere Web Client
The default password policy for vCenter Single Sign On system users specifies that passwords expire in 365 days. However, vCenter Single Sign On does not issue a warning when a user's password is approaching expiration.
Workaround: vCenter Single Sign On administrator users can change expired passwords for System-Domain users. Request that an administrator resets your password. If you are a Single Sign On administrator user, use the ssopass command-line tool to reset the password.
- Open a terminal window and navigate to C:Program FilesVMwareInfrastructureSSOServerssolscli
- Run the following command.
- Enter the current password for the user, even if it has expired.
- Enter the new password and enter it again for confirmation.
On Linux (vCenter Server Appliance):
- Open a terminal window and navigate to /usr/lib/vmware-sso/bin.
- Run the following command.
- Enter the current password for the user, even if it has expired.
- Enter the new password and enter it again for confirmation.
Cannot use Windows session authentication in the vSphere Web Client when vCenter Single Sign On is configured for high availability
Using Windows session authentication requires several consecutive calls to be made to Single Sign On and all of the calls must go to the same server. Because the Security Token Service (STS) client does not accept cookies that are sent from the STS, there is no guarantee that the calls will go to the same server in a high-availability configuration.
vCenter Server takes an unusually long time to start and the vSphere Client might time out
When a large number of permissions are assigned to objects in the vCenter Server inventory, the vCenter Server service does not start as quickly as expected as vCenter Server verifies that the users and groups exist in the identity source. Also, the connection to the vSphere Client might time out when you log in with Windows session credentials. The following messages appear in the vCenter Server logs while the service is starting:
[SSO] [SsoAdminFacadeImpl] [FindGroup]
[UserDirectorySso] GetUserInfo (DOMAIN *USER OR GROUP*, true) res: DOMAIN *USER OR GROUP*
[UserDirectorySso] NormalizeUserName (DOMAIN *USER OR GROUP*, false) re: DOMAIN *USER OR GROUP*
Workaround: Minimize the number of permissions that you assign to objects, or use inheritance from a higher level object to reduce the number of individual permission assignments.
Virtual Machine compatibility upgrade from ESX 3.x and later (VM version 4) incorrectly configures the Windows virtual machine Flexible adapter to the Windows system default driver
If you have a Windows guest operating system with a Flexible network adapter that is configured for the VMware Accelerated AMD PCnet Adapter driver, when you upgrade the virtual machine compatibility from ESX 3.x and later (VM version 4) to any later compatibility setting, for example, ESXi 4.x and later (VM version 7),Windows configures the flexible adapter to the Windows AMD PCNET Family PCI Ethernet Adapter default driver.
This misconfiguration occurs because the VMware Tools drivers are unsigned and Windows picks up the signed default Windows driver. Flexible adapter network settings that existed before the compatibility upgrade are lost, and the network speed of the NIC changes from 1Gbps to 10Mbps.
Workaround: Configure the Flexible network adapters to use the VMXNET driver from the Windows guest OS after you upgrade the virtual machine's compatibility. If your guest is updated with ESXi5.1 VMware Tools, the VMXNET driver is installed in the following location: C:Program FilesCommon FilesVMwareDriversvmxnet.
When you install VMware Tools on a virtual machine and reboot, the network becomes unusable
On virtual machines with CentOS 6.3 and Oracle Linux 6.3 operating systems, the network becomes unusable after a successful installation of VMware Tools and a reboot of the virtual machine. When you attempt to manually get the IP address from a DHCP server or set a static IP address from the command line, the error Cannot allocate memory appears.
The problem is that the Flexible network adapter, which is used by default, is not a good choice for those operating systems.
Workaround: Change the network adapter from Flexible to E1000 or VMXNET 3, as follows:
- Run the vmware-uninstall-tools.pl command to uninstall VMware Tools.
- Power off the virtual machine.
- In the vSphere Web Client, right-click the virtual machine and select Edit Settings.
- Click Virtual Hardware, and remove the current network adapter by clicking the Remove icon.
- Add a new Network adapter, and choose the adapter type E1000 or VMXNET 3.
- Power on the virtual machine.
- Reinstall VMware Tools.
Clone or migration operations that involve non-VMFS virtual disks on ESXi fail with an error
No matter whether you use the vmkfstools command or the client to perform a clone, copy, or migration operation on the virtual disks of hosted formats, the operation fails with the following error message: The system cannot find the file specified.
Workaround: To perform a clone, copy, or migration operation on the virtual disks of hosted formats, you need to load the VMkernel multiextent module into ESXi.
- Log in to ESXi Shell and load the multiextent module.
# vmkload_mod multiextent
- Check if any of your virtual machine disks are of a hosted type. Hosted disks end with the -s00x.vmdk extension.
- Convert virtual disks in hosted format to one of the VMFS formats.
- Clone source hosted disk test1.vmdk to test2.vmdk.
# vmkfstools -i test1.vmdk test2.vmdk -d zeroedthick eagerzereodthick thin
- Delete the hosted disk test1.vmdk after successful cloning.
# vmkfstools -U test1.vmdk
- Rename the cloned vmfs type disk test2.vmdk to test1.vmdk.
# vmkfstools -E test2.vmdk test1.vmdk
- Unload the multiextent module.
# vmkload_mod -u multiextent
Customizing a Windows virtual machine fails during the clone or deployment process
In vCenter Server, guest customization of a Windows 2008, Windows 2008 R2, or Windows 7 virtual machine fails with an error: Windows Setup encountered an internal error while loading or searching for an unattended answer file. This issue occurs because the customization specification contains any of the following characters &, >, <, ', or ' in any of the following fields: Computer Name, Registered Owner Name, or Registered Organization Name.
Workaround: Do not use special characters for any of these fields.
The vSphere Client and the vSphere Web Client allow to create a virtual disk with the 2TB-1MB size, while the maximum supported size is 2TB-512Bytes
If you create a virtual disk with the vSphere Client and the vSphere Web Client, you can create a virtual disk with the maximum size of 2TB-1MB. However, the maximum supported size of a virtual disk is 2TB-512Bytes.
Workaround: Use the vmkfstools command to create the virtual disk with the size of 2TB-512Bytes:
vmkfstools -c --createvirtualdisk disk_size
A virtual machine does not have an IP address assigned to it and does not appear operational
This issue is caused by a LUN reset request initiated from a guest OS. This issue is specific to IBM XIV Fibre Channel array with software FCoE configured in ESXi hosts. Virtual machines that reside on the LUN show the following problems:
- No IP address is assigned to the virtual machines.
- Virtual machines cannot power on or power off.
- No mouse cursor is showing inside the console. As a result, there is no way to control or interact with the affected virtual machine inside the guest OS.
Workaround: From your ESXi host, reset the LUN where virtual machines that experience troubles reside.
- Run the following command to get the LUN's information:
# vmkfstools -P /vmfs/volumes/DATASTORE_NAME
- Search for the following line in the output to obtain the LUN's UID:
Partitions spanned (on 'lvm'): eui.001738004XXXXXX:1
eui.001738004XXXXXX is the device UID.
- Run the following command to reset the LUN:
# vmkfstools -L lunreset /vmfs/devices/disks/eui.001738004XXXXXX
- If a non-responsive virtual machine resides on a datastore that has multiple LUNs associated with it, for example, added extents, perform the LUN reset for all datastore extents.
VMware HA and Fault Tolerance Issues
New Attempts to use Storage vMotion to migrate multiple linked-clone virtual machines fail
This failure typically affects linked-clone virtual machines. The failure occurs when the size of delta disks is 1MB and the Content Based Read Cache (CBRC) feature has been enabled in ESXi hosts. You see the following error message:
The source detected that the destination failed to resume.
Workaround: Use one of the following methods to avoid Storage vMotion failures:
Use 4KB as the delta disk size.
Instead of using Storage vMotion, migrate powered-off virtual machines to a new datastore.
Supported Hardware Issues
Fault tolerant virtual machines crash when set to record statistics information on a vCenter Server beta build
The vmx*3 feature allows users to run the stats vmx to collect performance statistics for debugging support issues. The stats vmx is not compatible when Fault Tolerance is enabled on a vCenter Server beta build.
Workaround: When enabling Fault Tolerance, ensure that the virtual machine is not set to record statistics on a beta build of vCenter Server.
In a vSphere HA cluster using Fault Tolerance, virtual machines might no longer be protected if an All Paths Down (APD) error occurs on all nodes
In a vSphere HA cluster, if there is APD on primary and secondary nodes for the datastore that hosts a virtual machine, the virtual machine might become unprotected. This is due to a failure to start the Secondary VM as the new Primary VM that results from a timing issue with APD reporting that could cause the virtual machine to become unknown. This issue does not seem occur in a cluster with a smaller number of fault tolerant virtual machines
- From vCenter Server, un-register the virtual machine and then re-register it using the same name as before. The virtual machine comes back up on the old primary node.
- Reconfigure the vSphere HA cluster and Fault Tolerance setup as it was previously configured.
PCI Unknown Unknown status is displayed in vCenter Server on the Apple Mac Pro server
The hardware status tab in vSphere 5.1 displays Unknown Unknown for some PCI devices on the Apple Mac Pro. This is because of missing hardware descriptions for these PCI devices on the Apple Mac Pro. The display error in the hardware status tab does not prevent these PCI devices from functioning.
PCI Unknown Unknown status is displayed in vCenter Server on the AMD PileDriver
The hardware status tab in vSphere 5.1 displays Unknown Unknown for some PCI devices on the AMD PileDriver. This is because of missing hardware descriptions for these PCI devices on the AMD PileDriver. The display error in the hardware status tab does not prevent these PCI devices from functioning.
DPM is not supported on the Apple Mac Pro server
The vSphere 5.1 distributed power management (DPM) feature is not supported on the Apple Mac Pro. Do not add the Apple Mac Pro to a cluster that has DPM enabled. If the host enters 'Standby' state, it fails to exit the standby state when the power on command is issued and displays an operation timed out error. The Apple Mac Pro cannot wake from the software power off command that is used by vSphere when putting a host in standby state.
Workaround: If the Apple Mac Pro host enters 'Standby' you must power on the host by physically pressing the power button.
IPMI is not supported on the Apple Mac Pro server
The hardware status tab in vSphere 5.1 does not display correct data or there is missing data for some of the hardware components on the Apple Mac Pro. This is because IPMI is not supported on the Apple Mac Pro.
After a network or storage interruption, syslog over TCP, syslog over SSL, and storage logging do not restart automatically.
After a network or storage interruption, the syslog service does not restart automatically in certain configurations. These configurations include syslog over TCP, syslog over SSL, and the interrupt storage logging.
Workaround: Restart syslog explicitly by running the following command:
esxcli system syslog reload You can also configure syslog over UDP, which restarts automatically.
Windows Server 2012 Failover Clustering is not supported
If you try to create a cluster for Failover Clustering in Windows Server 2012, and select to run validation tests, the wizard completes the validation tests with warnings, and after that returns to running the validation tests again. The wizard in the Windows Server 2012 guest operating system does not continue to the cluster creation stage.
The vSphere Web Client log browser does not display some log types
On Windows installations of vCenter Server and the vSphere Web Client, the log browser does not display the following log types:
- Lookup Server
The issue does not occur in vLogBrowser in VMware Workbench.
Workaround: Generate and download a log bundle. Use a text editor to view the log files.