Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Release Date: 11/15/07Document Last Updated: 11/15/07 Download Now Download Size: 40.0 MB Download Filename: ESX-1002424.tgz md5sum: 6b666d525062b5ccc8bbb5b09fbcebfb Product VersionsESX Server 3.0.2Patch ClassificationCriticalSupersedesESX-1001907Virtual Machine Migration or Reboot RequiredYesESX Server Host Reboot RequiredYesPRs Fixed159395,179129,191749,171388,182137,186845, 203545Affected HardwareN/AAffected SoftwareOEM Windows guest operating systemsRPMs UpdatedVMware-esx-vmkernel, VMware-esx-vmx, VMware-esx-appsRelated CVE numbersN/A Summary This patch fixes the following issues: Fixes an issue where a malformed IP packet might cause the ESX Server host to stop responding. This fix checks IP header information, and rejects malformed IP packets. Fixes an issue where the ESX Server host might stop responding due to vmklinux heap allocation failure. vmklinux is a module loaded on top of vmkernel that creates its own heap for memory allocation/free requests from within the module. During module creation, the kernel can be set up for minimum and maximum heap sizes of 256KB and 20MB. Based on the type of heap this module creates (low memory heap), fragmentation of large pages (physical pages of 2MB) might prevent vmkernel from increasing the heap size. This in turn might result in memory allocation requests failing within vmklinux module. The fix avoids these failures by making vmkernel grow the vmklinux heap to 10MB early on during boot time, when there shouldn't be any large page fragmentation. Fixes an issue of incorrect display of the hardware system manufacturer and product name on the guest operating system. Adding SMBIOS.reflectHost=TRUE option in the virtual machine configuration file should display the host system manufacturer and product name on the guest operating system as well. Instead, the guest operating system might display "VMware." Fixes an issue where some firmware versions of IBM SVC storage array return a status of Target Not Ready during failover, whenever IBM SVC LUN(s) are un-presented. A flaw in handling the return status by the ESX Server host's IBM SVC storage array specific multi-pathing code might cause the ESX Server host environment to become unresponsive. This fix modifies the multi-pathing code to update the Target Not Ready time for a path whenever the status is received, and marks the path as closed. Fixes an issue where a Reverse Address Resolution Protocol (RARP) broadcast might be sent to multiple vmnics. The ESX Server host normally registers a virtual machine with a switch through a transmission of a RARP broadcast packet that contains the MAC address of the virtual machine. In a topology of NIC teams connected to two or more switches, the virtual machine does not register with the switch. For this reason, the RARP packets are sent through multiple interfaces. This works for a single switch, as a Content-Addressable Memory (CAM) table can only update one entry at atime. However, when ESX Server NIC teams are connected to a cascade switch, a race condition leads to an attempt to update the CAM table of both switches with conflicting entries, with the result that both entries are discarded, leaving the virtual machine unregistered with the switch. Provides a new mechanism to support OEM Windows Server 2003 System Locked Preinstallation (SLP). Virtual machines running an OEM version of Microsoft Windows Server 2003 might prompt for reactivating the operating system when the virtual machine is migrated through a VMotion operation to a different ESX Server host with or without a different release version. This fix does away with the requirement to reactivate the operating system. Fixes an issue where vmkping and ramcheck commands fail in ESX Server 3.0.2 Update 1 or ESX Server 3.0.2 with patch bundle ESX-1001907 installed.
Symptoms The following symptoms might be seen in systems without this patch: Faulty information on an IP header might cause checksum calculation operations to falter, resulting in system failure. In a scenario where the ESX Server host becomes unresponsive due to vmklinux heap allocation failure, messages similar to the following might be logged in vmkernel log: 23:02:36:34.253 cpu6:1037)WARNING: HeapMgr: 715: Could not allocate large pages: Out of memory 23:02:36:34.253 cpu6:1037)WARNING: HeapMgr: 882: Failed to allocate/xmap large pages. 23:02:36:34.253 cpu6:1037)WARNING: HeapMgr: 1058: Could not add memory to heap allocator HeapMgrLowMem. 23:02:36:34.253 cpu6:1037)WARNING: Heap: 1271: Could not allocate 1114112 bytes for dynamic heap vmklinux. Request returned Out of memory 23:02:36:34.253 cpu6:1037)WARNING: Heap: 1370: Heap_Align(vmklinux, 432/432 bytes, 4 align) failed. caller: 0x7bd7fc 23:02:36:34.253 cpu6:1037)WARNING: LinSCSI: 273: No memory available! Called from 0x7bd7fc Even when the SMBIOS.reflectHost=TRUE option was set in virtual machine configuration, the system manufacturer and product name was being displayed as "VMware" in the guest operating system. The issue where IBM SVC storage arrays return a status of Target Not Ready during failover have been observed with versions of IBM SVC versions lower that 4.2. A Reverse Address Resolution Protocol (RARP) broadcast might be sent to multiple vmnics in the following scenario: 1. Set up VMotion between two ESX 3.0.2 Server hosts. 2. Both ESX server hosts should have quad port or dual port NICs. Two NICs should be connected to one Cisco switch and rest two to another Cisco switch. 3. Both Cisco switches should have cascade cable connection. 4. Ping the VMotion virtual machine continuously and perform VMotion around ten times. 5. At a certain point during VMotion, the virtual machine becomes unreachable. The race condition occurs at this point. Due to the race condition, the virtual machine becomes unreachable for around 40-50 ping requests. The race is due to the RARP being sent out on the two interfaces. Because the switches are expandable, it takes time for the switches to consolidate their CAM table. Systems running OEM BIOS locked Windows operating system might prompt for reactivating the operating sytem in the following scenario: 1. Install any version of OEM BIOS locked Windows operating system. 2. Power on, log in, and observe no prompts for activation. 3. Migrate virtual machine to ESX Server 3.0.x running on OEM hardware. 4. Set SMBIOS.reflectHost=True 5.The operating system prompts for activation. 6. After 30 days of prompting, the operating system automatically disables login. The vmkping command is a utility to help identify possible VMkernel network mis-configurations. The ramcheck command is a utility to run memory diagnostics while ESX Server is running. Execution of the vmkping or ramcheck command in the service console might fail with the following error message: syscall version mismatch (compiled: 0x7616c4e3, kernel: 0x50f63116) Deployment Considerations This patch resolves the symptoms discussed above. Download Instructions Download and verify the patch bundle as follows: 1. Download patch ESX-1002424 from http://www.vmware.com/download/vi/vi3_patches.html . <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 2. Log in to the ESX Server service console as root. 3. Create a local depot directory. # mkdir -p /var/updates Note: VMware recommends that you use the updates directory. 4. Change your working directory to /var/updates . # cd /var/updates 5. Download the tar file into the /var/updates directory. 6. Verify the integrity of the downloaded tar file: # md5sum ESX-1002424.tgz The md5 checksum output should match the following: 6b666d525062b5ccc8bbb5b09fbcebfb ESX-1002424.tgz 7. Extract the compressed tar archive: # tar -xvzf ESX-1002424.tgz 8. Change to the newly created directory, /var/updates/ESX-1002424: # cd ESX-1002424 Installation Instructions Note: All virtual machines on the host must be either shut down or migrated using VMotion before applying the patch. A reboot of the ESX Server host is required after applying the patch. After you download and extract the archive, and if you are in the directory that you previously created, use the following command to install the update: # esxupdate update To run esxupdate from a different directory, you must specify the bundle path in the command: # esxupdate -r file://<directory>/ESX-1002424 update For example, if the host is called depot: # esxupdate -r file:///depot/var/updates/ESX-1002424 update During the update process, logs appear on the terminal. You can specify the verbosity of esxupdate logs by using the -v option as shown below. # esxupdate -v 10 file://<directory>/ESX-1002424 update For more information how to use esxupdate, see the Patch Management for ESX Server 3 tech note at http://www.vmware.com/pdf/esx3_esxupdate.pdf .