Knowledge Base

Summaries and Symptoms

• VirtualCenter allows administrators to have fine-grained privileges. A directory traversal vulnerability might allow administrators to increase these privileges. In order to leverage this flaw, the administrator would need to have the Datastore.FileManagement privilege.
  The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2008-4281 to this issue.
  
  
• VMware privilege escalation on 32-bit and 64-bit guest operating systems: A flaw in VMware's CPU hardware emulation might allow the virtual CPU to incorrectly handle the trap flag. Exploitation of this flaw could lead to a privilege escalation on guest operating systems. An attacker would need to have a user account on the guest operating system and would need to have the ability to run applications.
  
  The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2008-4915 this issue.
  
  
• Previously, the root password expiration information was not preserved across hostd restarts. A new tag called rootPasswdExpiration is added to the /etc/vmware/hostd/config.xml file. If this rootPasswdExpiration tag is set to True, then the number of days to expiration will be preserved across hostd restarts.
  
  After setting the rootPasswdExpiration tag in the /etc/vmware/hostd/config.xml file as True, run the following command:
  
  chage -M <X> root
  
  Here, X is the number of days until expiration.
  
  Example: The command chage -M <60> root indicates the root password expires after 60 days.
  
  Note: Because the default value of rootPasswdExpiration tag is set as False, this fix will not impact customers who do not want the root password to expire.

Other issues fixed in this patch (and their relevant symptoms, if applicable) include:

• The vmware-config-tools.pl script overwrites fstab entries.
  
  Symptoms: If you edit the /etc/fstab file on your ESX host, and then later run the vmware-config-tools.pl script, the script overwrites the fstab file and loses your changes.
  
  
• The esxcfg-vswitch -L command now works as expected and with the same functionality as in 3.0.x.
  
  Symptoms: During a scripted installation, the following two commands did not result in a bonded pair of active network adapters on virtual switch VS_VM1. Instead, vmnic3 became the active adapter and vmnic4 became the standby adapter.
  
  esxcfg-vswitch -L vmnic3 VS_VM1
  esxcfg-vswitch -L vmnic4 VS_VM1
  
  
• Fixes the issue described in KB 1005345, “Service Console Might Lose Network Connectivity on a Server with More than 128GB of Memory Installed.” For details about this issue, see http://kb.vmware.com/kb/1005375.
  
  
• In the VI Client, adding the software iSCSI target address in the Dynamic Discovery tab takes a long time.
  
  The long delay occurs because a target discovery is triggered each time a discovery address is added. After adding the discovery address, you must rescan so the VMkernel can find new targets from the added discovery address. This triggers a target discovery again. The target discovery performed after the addition of each discovery address is redundant and only adds unnecessary delays.
  
  This change removes the target discovery performed after each discovery address addition, thereby reducing the time taken for the operation.
  
  
• The vmware-cmd stop trysoft command now works as documented.
  
  The command first attempts to perform the power transition operation with vmPowerOpMode_Soft. If this fails, the same operation is performed with vmPowerOpMode_Hard. In previous versions of ESX Server 3.x, if the soft operation failed, the hard operation was not attempted. The command worked correctly in ESX Server 2.5.
  
  
• For German, Japanese, or Simplified Chinese language support, when you use Virtual Infrastructure Web Access or the VI Client with your ESX host, the language pack must be on the host and the default locale set to your desired language. Starting with ESX 3.5 Update 3, the language pack files are installed on all hosts and do not need to be copied to the host before changing the locale.
  
  To set the default locale on the host:
  
  
  
  • Edit the /etc/vmware/hostd/config.xml file to enable the correct default locale.
    
    Find the following lines in config.xml :
    
    <locale>
    <DefaultLocale>en_US</DefaultLocale>
    </locale>
    
    For German, replace the lines with the following:
    
    <locale>
    <DefaultLocale>de_DE</DefaultLocale>
    </locale>
    
    For Japanese, replace the lines with the following:
    
    <locale>
    <DefaultLocale>ja_JP</DefaultLocale>
    </locale>
    
    For Simplified Chinese, replace the lines with the following:
    
    <locale>
    <DefaultLocale>zh_CN</DefaultLocale>
    </locale>
    
    
  • Type the following commands to restart Web Access and host agent services:
    
    service mgmt-vmware restart
    service vmware-webAccess restart
    
    
• Intel Pro/1000 gigabit Ethernet device drivers (e1000) in some guests allocate MTU bytes for rx buffers, but tell the device the size of the rx buffer is 2048 bytes. If these buffers fall on the edge of the guest physical memory range, the virtual e1000 device could wedge during rx with the following messages in the VMkernel logs:
  
  WARNING: Alloc: ppn=0xc0000 out of range: 0x0-0xc0000 (count=3)
  WARNING: P2MCache: GetPhysMemRange failed: PPN 0xc0000 canBlock 0 status Bad parameter.
  
  This patch fixes this problem.
  
  
• The vmware-cmd utility commands fail on the service console. This issue is fixed, with the exception of vmware-cmd -s getconfig and vmware-cmd -s getresource . These commands still display some error messages.
  
  
• If you configure NIC teaming for beaconing and disconnect a NIC from a team of two NICs, a message similar to the following appears:
  
  Removing from config file only.
  
  The vmnic is also removed from the port group.
  
  After you apply this patch, a suitable message similar to the following is displayed:
  
  Need uplink: <vmnic name> for beaconing. (Minimum 2 required).
  
  The vmnic also stays in the port group.
  
  
• Running a VMware Consolidated Backup command (file-level or full backup) on 32-bit or 64-bit Windows 2003 virtual machines displays a VMware Tools Not Running message in the Summary tab of VirtualCenter, even though VMware Tools is still running.
  
  
• Data is retrieved from VPD Page 0x85 using the alternateName property in the SCSI LUN of a SCSI-3 compatible device. This feature helps the host utilities of NetApp to communicate with ESX 3.5 releases.
  
  
• This change improves performance for NetWare guests by fixing compatibility issues between the E1000.LAN driver and E1000 virtual NIC emulation.
  
  
• Include SCSI sense codes in ESX 3.5 VMkernel logs.
  
  ESX 3.5 filters all SCSI sense codes out of /var/log/vmkernel by default. The absence of SCSI sense codes affects the troubleshooting and root cause analysis of storage issues. Without these codes, it is difficult to determine what has occurred at specific times on devices external to ESX.
  
  After applying this patch, SCSI sense codes are included in VMkernel logs, by default.
  
  
• The disk partition information is not current, which causes various problems, such as Inventory is not updated and datastores are not created, extended, expanded, or removed. The following error message might be seen:
  
  Error during the configuration of the host:Failed to update disk partition information.
  
  
• The virtual machine system BIOS has been updated to SMBIOS version 2.4.
  
  
• Virtual machines that use the enhanced vmxnet network adapter cannot be booted from the network. This issue causes guest installations using PXE to fail.
  
  
• Add support for the new firmware version of LSI Engenio DS4000 series storage arrays (DS4200, DS4700, DS4800). This allows path failover to work as expected.
  
  
• A shared LUN's properties page is shown blank of information, or shows the previous size of the LUN, after an adapter rescan on another host in the cluster that shares the same volume.
  
  
• Because of BIOS MTRR issues on certain platforms, ESX previously failed to boot unless the VMkernel force36BitMTRRMask boot option was set to false. This change enables full support for memory up to 64GB with no need to specify a boot option.
  
  Note: As a result of this change, the force36BitMTRRMask VMkernel boot option is no longer supported. If the option is set, the result is no operation (NOP) and boot succeeds as if the option had not been specified.
  
  
• This patch resolves an issue where sending a fax from a virtual machine using the serial port on the ESX host causes data loss such as missing lines and unclear information.
  
  Note: You must activate this fix by adding serial<n>.hardwareFlowControl = “TRUE” to the .vmx file after patch installation.
  
  
• vCPU per Core Limit Now at 20: The limit on vCPUs per core has been raised from 8 (or 11 for VDI workloads) to 20. This change only raises the supported limit. The change does not include any additional performance optimizations. Raising the limit allows users more flexibility to configure systems based on specific workloads and to get the most advantage from increasingly faster processors. The achievable number of vCPUs per core will depend on the workload and specifics of the hardware. It is expected that most deployments will remain within the previous range of 8-11 vCPUs per core. For more information, see the ESX CPU Considerations section of the VI3 Performance Best Practices and Benchmarking Guidelines.
  
  
• Network connectivity might be lost when network teaming is used and teaming policy is based on port ID.
  
  
• This change raises the maximum number of physical CPUs per NUMA node from 16 to 32. This change supports systems like the dual-node IBM x3950 M2, which can have up to four Dunnington packages per node, and can result in more than 16 cores in a node. On these systems, ESX now can boot with all the physical CPUs. Currently, ESX supports a maximum of 32 physical CPUs per system.
  
  Symptoms: Without this patch, a problem is seen in some dual-node system configurations with Dunnington processors where the number of physical CPUs on a node are greater than 16. The following sysalert is generated:
  
  SRAT node <num> has <num> logical processors, exceeding the limit of 16.
  
  As a result, the excess physical CPUs in the node are discarded and the system comes up with fewer physical CPUs than are actually present.
  
  
• Minor change in QLogic driver to reduce logging of Debug scsi underrun messages in the VMkernel log, /var/log/vmkernel .
  
  
• The ESX service console becomes read-only when the SVC firmware is upgraded online or when the controller is reset. ESX should recognize the path as down and recover later when the controller is back online.
  
  
• Lost ESX Host network connection while running VMware consolidated Backup (VCB).
  

Deployment Considerations

Patch Download and Installation

See the VMware Update Manager Administration Guide for instructions on using Update Manager to download and install patches to automatically update ESX Server 3.5 hosts.

To update ESX Server 3.5 hosts when not using Update Manager, download the most recent patch bundle from http://www.vmware.com/download/vi/vi3_patches_35.html and install the bundle using esxupdate from the command line of the host. For more information, see the ESX Server 3 Patch Management Guide .