Knowledge Base

Summaries and Symptoms

This patch provides pre-built kernel modules for SUSE Linux Enterprise 11 Service Pack 1 (32bit and 64bit) and provides the following updates:

• The OpenSSL 0.9.7a package for ESX service console is updated to openssl097a-0.9.7a-9.el5_4.2, which fixes a security issue. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2009-3555 to this issue.
  
  
• The GnuTLS RPM for ESX service console is updated to gnutls-1.4.1-3.el5_4.8, which fixes two security issues. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2009-2409 and CVE-2009-3555 to this issue.
  
  
• The NSS RPM and NSPR RPM for ESX service console are updated to nss-3.12.6-1.3235.vmw and nspr-4.8.4-1.3235.vmw respectively, which fix a security issue. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2009-3555 to this issue.
  
  
• The OpenSSL RPM for ESX service console is updated to openssl-0.9.8e-12.el5_4.6, which fixes security issues. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2009-3245, CVE-2009-3555, and CVE-2010-0433 to these issues.
  

This patch also fixes the following issues:

• The Health Status tab shows false alerts and zero readings for voltage and temperature sensors when you connect a vSphere Client to the vCenter Server that manages ESX hosts running on Unisys ES7000 Model 7600R Enterprise Servers or NEC Express5800/A1040.
  
  
• The ESX host fails and displays the following error on a purple screen:
  SetupVlanGroupDevice+0xdf
  UplinkProcessAsyncCallsHelperCB+0x126
  helpFunc+0x4cf
  This issue occurs because the vmklinux heap is out of memory when you create a VLAN Group for a virtual machine.
  
  
• When you try to connect a virtual machine on the ESX host to the CD-ROM on the host, the following warning message might be written to the VMkernel log file twice every second:
  WARNING: vmklinux26: SCSILinuxQueueCommand: cmd 0x00, cmd_len 12 should be 6
  When this issue continues, the logging of messages drains the memory of the virtual disk, and the ESX host stops responding.
  This issue occurs after upgrading from ESX 4.0 Embedded to ESX 4.0 Update 2.
  
  
• vCenter Site Recovery Manager fails and ESX host displays the following error:
  dr.secondary.fault.RdmDeviceNotFound
  The issue occurs only when ESX hosts that are using software iSCSI initiator cannot detect the RDM LUN. The RDM LUN is not visible to the host because the iSCSI daemon assigns the same target ID to two different targets during the SRM recovery.
  
  
• When a storage controller fails, the ESX software iSCSI initiator with default settings takes about 45 seconds to detect the problem and inform the ESX storage stack to initiate storage failover. For some array models, like those that use LSI controllers, this problem results in storage failover taking more than 60 seconds to complete after the I/O is sent from the virtual machines. This can cause I/O errors to be reported by applications and the guest operating system running in the virtual machine. This patch resolves this issue.
  
  After installing this patch, you can configure the parameters Noop Interval and Noop Timeout, by using vCenter Server or the vmkiscsi-tool in the service console. These parameters enable you to reduce the timeout value based on the storage arrays, so that the software iSCSI initiator can detect changes in the path state faster and initiate storage failovers.
  
  To configure Noop Interval and Noop Interval parameters in vCenter Server:

1. Log in to the vCenter Server as administrator using the vSphere Client.
2. Select the Configuration tab.
3. Click the Storage Adapters link in the Hardware panel.
4. Select the vmhba for the iSCSI software adapter.
5. Click the Properties link in the Details panel.
6. Click Advanced in the iSCSI Initiator Properties window.
7. Configure the required values for the Noop interval and Noop Timeout parameters.
   The default values of the parameters are Noop Interval is 40 and Noop Timeout is 10.

To configure Noop Interval and Noop Interval parameters by using the vmkiscsi-tool:

1. Log in as root in the ESX service console.
2. Enter the following command to set the Noop interval.
   vmkiscsi-tool -W -a "noop_out_interval=15" vmhba<nn>
3. Enter the following command to set the Noop Timeout.
   vmkiscsi-tool -W -a "noop_out_timeout=10" vmhba<nn>
4. Enter the following command to view the updated values.
   vmkiscsi-tool -W -l vmhba<nn>
   The default values of the parameters are Noop Interval is 40 and Noop Timeout is 10.
   
   

• If virtual machines are running on an ESX machine that is connected to arrays using LSI controllers and the firmware on the controllers is upgraded online, applications and the guest operating system might report I/O failures. Many arrays use an LSI controller. The following is a list of a few of the common arrays using LSI controllers:
  • IBM DS48xx series
  • IBM DS 3xxx series
  • Dell MD3xxx series
  • Sun STK Flexline series
    
    
• Virtual machines are suspended and multiple storage alerts are raised on multiple ESX hosts resulting in an all-paths-down state. The VMkernel log file contains the following message:
  NMP: nmp_DeviceAttemptFailover: Retry world failover device. "naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" - failed to issue command due to Not found (APD), try again...
  This issue occurs because ESX does not accept new paths which are exported from EMC Symmetrix Storage after an ESX host boot-up or an all-paths-down state.
  
  
• When you upgrade virtual hardware from version 4 to version 7, the system does not retain the virtual NIC settings such as NetBIOS/WINS, network adapter binding order, protocol binding order, and so on. This patch includes an updated version of the VMware Upgrade Helper service which preserves all adapter settings.
  This issue occurs in Windows virtual machines when you upgrade from ESX 3.5 to ESX 4.0, and in Windows virtual machines which were using virtual hardware 4 on ESX 4.0, earlier. In ESX 4.0, the virtual NIC is moved to a different position on the virtual PCI bus, which causes Windows to treat it as a new hardware device.
  
  
• Virtual machines display increased memory usage in vmware-guestd and vmwareservice.exe. The memory footprint of the process continues to increase until the available memory is drained and the process cannot allocate any memory. This issue is more prominent when the guest operating system has a large number of IP addresses associated with it.
  
  
• Cloning or migrating a virtual machine with thin as the destination file format is significantly slower than cloning virtual machines with the destination file as thick. This issue occurs due to the large number of operations involved in the cloning of a thin virtual disk.
  Installing this patch reduces the operations involved in cloning targets with thin file formats and results in a faster thin to thin disk cloning.
  
  
• Virtual machines fail and ESX hosts lose access to the LUNs in an iSCSI SAN. These issues occur when the ESX software iSCSI initiator is used to connect to the EqualLogic arrays.
  When the I/O load is heavy, some iSCSI targets take more time to process I/O and task management function requests. This causes ESX to time out and cancel the I/O. The target might respond to the original I/O request after the request is canceled. This might cause the ESX software iSCSI initiator to drop the session and connect again. This process of session drop and re-connection affects I/O throughput.
  This patch prevents frequent session drops in a heavily loaded ESX software iSCSI setup.
  
  
• Storage vMotion of a virtual machine might stop responding at 18%, and might be completed after a long time, even though other Storage vMotion operations on the host might continue without any errors. If you try to cancel the Storage vMotion operation when it stops responding, the system disconnects the ESX host from the vCenter Server and automatically connects it after a few minutes.
  
  The vmware.log file might contain the following error:
  Could not perform clone using vmkernel data mover. Falling back to non-accelerated clone. Cannot allocate memory
  
  The VMkernel log file might contain the following error:
  status Out of memory copying 16777216 bytes from file offset 0 to file offset 0, bytesTransferred = 0 extentsTransferred: 0
  
  This issue occurs because the DataMover cannot allocate contiguous physical space when the host's kernel memory usage is around 50% and the memory is fragmented. The operation fails back to the Application layer data movement. The operation continues and succeeds, but might take more time when compared to the usual DataMove time. The DataMover requires 16MB of contiguous physical memory on the ESX host for each DataMover thread.
  This patch provides a fix to make DataMover work with fragmented memory.
  
  
• Virtual machines drop out of multicast groups because IGMP general queries do not reach the virtual machines when using VLAN. This problem occurs because the VLAN tags are not added to the IGMP Query packets or frames.
  
  
• When you configure VLAN ID on a dvportgroup and if the vDS is using a card that supports VLAN filtering to communicate with the other ESX hosts, the physical NIC might not be able to receive any traffic from outside, causing disruptions in network connectivity.
  
  
• The Network window in the vSphere 4 esxtop tool incorrectly reports a large number of dropped receive-packets (%DRPRX) for virtual machines that are using the e1000 virtual NIC with multicast traffic.
  
  
• The system time is automatically set ahead by 1 or 2 seconds and moves back randomly on Symmetric Multi-Processing (SMP) virtual machines running Linux 2.4 kernels on ESX 4.0.
  
  
• For Red Hat Enterprise Linux 5 Update 3 and later, performance of vmxnet3 vNIC is lower than vmxnet2/e1000 vNIC with the default MSI mode of interrupt settings.
  
  

Known Issue

1. Extract VMwareTools-4.0.0-<build number>.tar.gz file.
2. Delete the following lines from the vmware-install.pl file:
   if ($gOption{'default'}) {
   # If given --default, flush all other options.
   %gOption = ('default' => 1 );
   }
   
3. Save and close the file.

• This issue does not affect manual or automatic upgrade of the VMware Tools.
• This issue does not affect the manual installing of the VMware Tools without the -d/--default options.
  

Deployment Considerations

Replace the vmware-install.pl file on your machine with the file attached to this KB article.

Patch Download and Installation

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