I wanted to share these three VMware Knowledge Base articles.
KB Article: 2007269
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:
This is caused by an issue in the handling of the vpxa agent upgrade.
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.
For more information about updating ESXi, see Updating ESX 4.x to a newer released update (1016209).”
KB Article: 2007108
ESXi 5.x boot delays when configured for Software iSCSI
- 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:[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 [email protected] addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) err=4
iscsid: Login Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 [email protected] addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) Reason: 00040000 (Initiator Connection Failure)
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.
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:
MAC Address: 00:1b:21:59:16:e8
MAC Address Valid: true
IPv4 Subnet Mask: 255.255.255.0
Vlan Supported: true
Vlan ID: 10
Reserved Ports: 63488~65536
TCP Checksum: false
Link Up: true
Current Speed: 10000
Rx Packets: 656558
Tx Packets: 111264
NIC Driver: ixgbe
NIC Driver Version: 18.104.22.168.2-10vmw-NAPI
NIC Firmware Version: 0.9-3
Compliant Status: compliant
VswitchUuid: 26 46 30 50 c0 cf df 1e-52 ef ab d7 a2 ab 96 f9
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”
KB Article: 2007427
- 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
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.
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.
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:
- 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).
- From your ESXi 5.0 host, issue this
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.
Without disabling the UNMAP feature, you might experience timeouts with operations such as Storage vMotions and Virtual Machine Snapshot Consolidation.
To be alerted when this article is updated, click Subscribe to Document in the Actions box.
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.