Volume Group LUN IDs Exceed the ESXi Limit
A PowerStore 1200T hosts a VMware vSphere 7.0 U3 cluster of four ESXi hosts. The storage admin creates a volume group named VG-ORACLE containing 12 thin volumes, each 2 TB, and maps the group to host group ESXi-Prod. PowerStore Manager shows all 12 volumes as mapped and healthy. On the ESXi side, each host sees only 10 of the 12 volumes after a rescan; the two missing volumes are the last two created. The mapping details show the visible volumes use LUN IDs 0 through 9, while the two missing volumes were automatically assigned LUN IDs 256 and 257. The customer needs the two volumes visible today without rebooting hosts or disrupting the 10 working volumes. No data has been written to the missing volumes.
1. What is the most likely reason the two volumes are not visible, and what evidence supports it?
Read the worked answer
The most likely reason is the ESXi LUN ID limit. ESXi presents SCSI LUN IDs in the range 0-255, so a volume mapped with LUN ID 256 or 257 will not be visible even though the array reports it as mapped and healthy. The evidence is strong: exactly the two volumes with IDs outside the range are missing, the other ten with IDs 0-9 are visible, and all twelve are mapped to the same host group.
This is not a zoning or path problem because the hosts see the other volumes from the same array through the same paths. It is also not a volume-size issue. The fault is in the LUN ID assignment within the volume group mapping.
2. Describe the safest fix in PowerStore Manager, including checks before and after.
Read the worked answer
In PowerStore Manager, open the volume group mapping for VG-ORACLE and edit the LUN IDs for the two missing volumes. Assign unused IDs within the ESXi-supported range, such as 10 and 11, or any free IDs below 256. Confirm that no other volume in the host group uses those IDs. Do not change the IDs of the ten working volumes, because that could cause unnecessary device re-enumeration on the hosts.
After saving the mapping, rescan the storage adapters on each ESXi host. Verify that all 12 devices appear and that the two new devices are the expected volumes, not duplicates. Do not initialize or format them until the volume identity is confirmed. The change should be non-disruptive to the ten working volumes.
3. How would you prevent this on future volume groups?
Read the worked answer
Keep ESXi volume groups below the host's LUN limit and assign LUN IDs deliberately rather than relying entirely on automatic assignment. For ESXi, plan for no more than 256 LUNs per host and reserve headroom for other arrays and future growth. When creating a large volume group, review the assigned LUN IDs before mapping, or map volumes in smaller batches with known ID ranges.
Document the host OS limits for each platform, because Windows, Linux, and ESXi differ. Add a validation step after mapping: check the host's device count against the array's mapped count and investigate immediately if they differ. This avoids a repeat where the array says healthy but the host silently omits volumes.