User guide

Technical white paper | HP Enterprise Virtual Array Storage and VMware vSphere 4.x and 5.x configuration best practices
61
Validating the better balanced configuration
You can review the output of EVAperf (as shown in Figure C-9) to verify that controller throughput is now better balanced.
Run the following command:
evaperf hps –sz <array_name> -cont X –dur Y
Figure C-9. Improved I/O distribution
The system now has much better I/O distribution.
Appendix D: Caveat for data-in-place upgrades and Continuous Access EVA
The vSphere datastore may become invisible after one of the following actions:
• Performing a data-in-place upgrade from one EVA controller model to another
• Using Continuous Access EVA to replicate from one EVA model to another
Following these actions, ESX treats the new datastore as being a snapshot and, by default, does not display it.
Why is the datastore treated as a snapshot?
When building the VMFS file system on a logical unit, ESX writes metadata to the Logical Volume Manager (LVM) header that
includes the following information:
• Vdisk ID (such as Vdisk 1)
• SCSI inquiry string for the storage (such as HSV300); also known as the product ID (PID) or model string
• Unique Network Address Authority (NAA)-type Vdisk identifier, also known as the Worldwide Node LUN ID of the Vdisk
If any of these attributes changes after you create the new datastore, ESX treats the volume as a snapshot because the new
Vdisk information will not match the metadata written on disk.
Example
Consider the data-in-place migration example shown in Figure D-1, where existing HSV300 controllers are being replaced
with HSV450 controllers.
Figure D-1. Replacing EVAs and controllers