Troubleshoot VMware ESXi/ESX to iSCSI array connectivity:
Note: This A rescan is required after every storage presentation change to the environment.
1.Log into the ESXi/ESX host and verify that the VMkernel interface (vmk) on the host can vmkping the iSCSI targets with this command:
# vmkping target_ip
If you are running an ESX host, also check that Service Console interface (vswif) on the host can ping the iSCSI target with:
# ping target_ip
Note: Pinging the storage array only applies when using the Software iSCSI initiator. In ESXi, ping and ping6 both run vmkping. For more information about vmkping, see Testing VMkernel network connectivity with the vmkping command (1003728).
2.Use netcat (nc) to verify that you can reach the iSCSI TCP port (default 3260) on the storage array from the host:
# nc -z target_ip 3260
Example output:
Connection to 10.1.10.100 3260 port [tcp/http] succeeded!
Note: The netcat command is available with ESX 4.x and ESXi 4.1 and later.
3.Verify that the host Hardware Bus Adapters (HBAs) are able to access the shared storage. For more information, see Obtaining LUN pathing information for ESX or ESXi hosts (1003973).
4.Confirm that no firewall is interfering with iSCSI traffic. For details on the ports and firewall requirements for iSCSI, see Port and firewall requirements for NFS and SW iSCSI traffic (1021626). For more information, see Troubleshooting network connection issues caused by firewall configuration (1007911).
Note: Check the SAN and switch configuration, especially if you are using jumbo frames (supported from ESX 4.x). To test the ping to a storage array with jumbo frames from an ESXi/ESX host, run this command:
# vmkping -s MTUSIZE IPADDRESS_OF_SAN -d
Where MTUSIZE is 9000 – (a header of) 216, which is 8784, and the -d option indicates “do not fragment”.
5.Ensure that the LUNs are presented to the ESXi/ESX hosts. On the array side, ensure that the LUN IQNs and access control list (ACL) allow the ESXi/ESX host HBAs to access the array targets. For more information, see Troubleshooting LUN connectivity issues on ESXi/ESX hosts (1003955).
Additionally ensure that the HOST ID on the array for the LUN (on ESX it shows up under LUN ID) is less than 255 for the LUN. The maximum LUN ID is 255. Any LUN that has a HOST ID greater than 255 may not show as available under Storage Adapters, though on the array they may reside in the same storage group as the other LUNS that have host IDs less than 255. This limitation exists in all versions of ESXi/ESX from ESX 2.x to ESXi 5.x. This information can be found in the maximums guide for the particular version of ESXi/ESX having the issue.
6.Verify that a rescan of the HBAs displays presented LUNs in the Storage Adapters view of an ESXi/ESX host. For more information, see Performing a rescan of the storage on an ESXi/ESX host (1003988).
7.Verify your CHAP authentication. If CHAP is configured on the array, ensure that the authentication settings for the ESXi/ESX hosts are the same as the settings on the array. For more information, see Checking CHAP authentication on the ESXi/ESX host (1004029).
8.Consider pinging any ESXi/ESX host iSCSI initiator (HBA) from the array’s targets. This is done from the iSCSI host.
9.Verify that the storage array is listed on the Storage/SAN Compatibility Guide. For more information, see Confirming ESXi/ESX host hardware (System, Storage, and I/O) compatibility (1003916).
Note: Some array vendors have a minimum-recommended microcode/firmware version to operate with VMware ESXi/ESX. This information can be obtained from the array vendor and the VMware Hardware Compatibility Guide.
10.Verify that the physical hardware is functioning correctly, including:
◦The Storage Processors (sometimes known as heads) on the array
◦The storage array itself
◦Check the SAN and switch configuration, especially if you are using jumbo frames (supported from ESX 4.x). To test the ping to a storage array with jumbo frames from ESXi/ESX, run this command:
# vmkping -s MTUSIZE STORAGE_ARRAY_IPADDRESS
Where MTUSIZE is 9000 – (a header of) 216, which is 8784.
Note: Consult your storage array vendor if you require assistance.
11.Perform some form of network packet tracing and analysis, if required. For more information, see:
◦Capturing virtual switch traffic with tcpdump and other utilities (1000880)
◦Troubleshooting network issues by capturing and sniffing network traffic via tcpdump (1004090)
Do you have anything on XenApp 7.5 + HDX 3D? This is super helpful, but there is even less information on sizing for XenApp when GPUs are involved.
Reply
Unfortunately we don’t yet have any concrete sizing data for XenApp with graphics but this is Tee’d up for us to tackle next. I’ll add some of the architectural considerations which will hopefully help.
Reply
Two questions:
1. Did you include antivirus in your XenApp scalability considerations? If not, physical box overhead with Win 2012 R2 and 1 AV instance is minimal, when compared to 6 PVS streamed VMs outfitted with 6 AV instances respectively (I am not recommending to go physical though).
2. When suggesting PVS cache in RAM to improve scalability of XenApp workloads, do you consider CPU, not the IO, to be the main culprit? After all, you only have 20 cores in a 2 socket box, while there are numerous options to fix storage IO.
PS. Some of your pictures are not visible
Reply
Hi Alex,
1) Yes, we always use antivirus in all testing that we do at Dell. Real world simulation is paramount. Antivirus used here is still our standard McAfee product, not VDI-optimized.
2) Yes, CPU is almost always the limiting factor and exhausts first, ultimately dictating the limits of compute scale. You can see here that PVS cache in RAM didn’t change the scale equation, even though it did use slightly less CPU, but it all but eliminates the disk IO problem. We didn’t go too deep on the higher IO use cases with cache in RAM but this can obviously be considered a poor man’s Atlantis ILIO.
Thanks for stopping by!
Reply