New VMware KB’s I deem Important.

I wanted to share these three VMware Knowledge Base articles.

ESXi 4.0 Update 2 hosts may experience a purple screen after vCenter Server is upgraded to 5.0

KB Article: 2007269

“

Symptoms

You may encounter an issue where:

• You have recently upgraded your vCenter Server to version 5.0
• You have ESXi 4.0 Update 2 hosts in the inventory of this vCenter Server
• After the vpxa agents are upgraded, the ESXi 4.0 Update 2 hosts experience a purple screen that includes this error:
  NOT_IMPLEMENTED bora/vmkernel/filesystems/visorfs/visorfsObj.c:3391

Cause

This is caused by an issue in the handling of the vpxa agent upgrade.

Resolution

This issue has been resolved in 4.0 Update 3. To avoid this issue, upgrade all ESXi 4.0 Update 2 hosts to at least version ESXi 4.0 Update 3 before upgrading vCenter Server to 5.0.

ESXi 4.0 Update 3 and later versions can be downloaded from the VMware Download Center.

Additional Information

For more information about updating ESXi, see Updating ESX 4.x to a newer released update (1016209).”

ESXi 5.x boot delays when configured for Software iSCSI

KB Article: 2007108

“

ESXi 5.x boot delays when configured for Software iSCSI

Symptoms

• ESXi 5.0 experiences a delay when booting during the the software-iscsi step.
• After the boot process completes, the sysboot.log file contains entries similar to:
  [fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][01:57:50.925338] sysboot: software-iscsi
  [02:28:22.330320] sysboot: restore-paths
• After the boot process completes, the syslog.log file contains entries similar to:
  iscsid: cannot make a connection to 192.168.1.20:3260 (101,Network is unreachable)
  iscsid: Notice: Reclaimed Channel (H34 T0 C1 oid=3)
  iscsid: session login failed with error 4,retryCount=3
  iscsid: Login Target Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) err=4
  iscsid: Login Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) Reason: 00040000 (Initiator Connection Failure)

Cause

This issue occurs because ESXi 5.0 attempts to connect to all configured or known targets from all configured software iSCSI portals. If a connection fails, ESXi 5.0 retries the connection 9 times. This can lead to a lengthy iSCSI discovery process, which increases the amount of time it takes to boot an ESXi 5.0 host.

Resolution

To minimize the amount of time the boot process spends discovering iSCSI targets, you can reduce the number of network portals and the number of targets.
To list the current number and configuration of an ESX host’s network portals, run the command:
esxcli iscsi networkportal list
The output is similar to:
vmhba34:
Adapter: vmhba34
Vmknic: vmk6
MAC Address: 00:1b:21:59:16:e8
MAC Address Valid: true
IPv4: 192.168.1.206
IPv4 Subnet Mask: 255.255.255.0
IPv6:
MTU: 1500
Vlan Supported: true
Vlan ID: 10
Reserved Ports: 63488~65536
TOE: false
TSO: true
TCP Checksum: false
Link Up: true
Current Speed: 10000
Rx Packets: 656558
Tx Packets: 111264
NIC Driver: ixgbe
NIC Driver Version: 2.0.84.8.2-10vmw-NAPI
NIC Firmware Version: 0.9-3
Compliant Status: compliant
NonCompliant Message:
NonCompliant Remedy:
Vswitch: dvSwitch0
PortGroup: DvsPortset-0
VswitchUuid: 26 46 30 50 c0 cf df 1e-52 ef ab d7 a2 ab 96 f9
PortGroupKey: dvportgroup-78003
PortKey: 1731
Duplex:
Path Status: active
Note: This is an example of one network portal (HBA34).
To list currently running targets, run the command:

vmkiscsi-tool -T vmhba##

For more information on reducing number of network portals and the number of targets, contact your array vendor”

Disabling VAAI Thin Provisioning Block Space Reclamation (UNMAP) in ESXi 5.0

KB Article: 2007427

“

Symptoms

• When performing a Storage vMotion or a Virtual Machine Snapshot you experience poor system performance.
• A Storage vMotion or Virtual Machine Snapshot fails or times out

Purpose

VMware introduced a new feature in vSphere 5.0 called Space Reclamation, as part of VAAI Block Thin Provisioning. Space reclamation is a garbage collection process that helps storage partners to efficiently reclaim deleted space in coordination with vSphere 5.0.

ESXi 5.0 issues UNMAP commands for Space Reclamation in critical regions during several operations with the expectation that the operation would complete quickly. Due to varied response times from the storage devices, UNMAP command can result in poor performance of the system and should be disabled on the ESXi 5.0 host.

This article shows how to disable the UNMAP command used for the Space Reclamation.

Cause

VAAI Thin Provisioning is enabled by default on devices that adheres to T10 standards. ESXi identifies Thin Provisioned LUNs and issue UNMAP commands to reclaim deleted space on the storage. The implementation and response times for the UNMAP command may vary significantly among storage arrays.

This variation of response times in critical regions could potentially interfere with operations such as Storage vMotion and Virtual Machine Snapshot consolidation.

Resolution

You can work around this issue on vSphere 5.0 hosts which have Thin Provisioned LUNs and T10 standard storage arrays.

Note: To verify that you have a T10 storage array, consult the VMware Compatibility Guide.

To avoid the use of UNMAP commands on Thin Provisioned LUNs:

1. Log into your host using Tech Support mode. For more information on using Tech Support mode see Tech Support Mode in ESXi 4.1 and 5.0 (1017910).
2. From your ESXi 5.0 host, issue this esxcli command:
   esxcli system settings advanced set --int-value 0 --option /VMFS3/EnableBlockDelete
   Note: This is a per-host setting and must be issued on each ESXi 5.0 host in your cluster.

Impact/Risks

Without disabling the UNMAP feature, you might experience timeouts with operations such as Storage vMotions and Virtual Machine Snapshot Consolidation.

Additional Information

To be alerted when this article is updated, click Subscribe to Document in the Actions box.

See Also

• Using Tech Support Mode in ESXi 4.1 and 5.0

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page. “

I thought it was important to share these.

Roger Lund

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]