Here's my config :
-VI 3
-HP pClass blades connected to an HP EVA6000
- latest HP firmware on the 6000
- hosts setup as VMWare (per HP best practices)
-LUNS presented for VMFS volumes (no troubles here)
-LUNS presented to all blades and setup as raw device mappings to a virtual Microsoft SQL Server Cluster (using MS Clustering Services)
- setup per VMWare's best practices on VM MS Clusters (unless I missed a critical setup, which I won't discount).
Here's the problem. There are approximately a half-dozen LUN's presented in this way. When going to add new storage (VMFS volumes), it is taking anywhere between 6-7 minutes to finish up with the SCSI reservation timeouts on these LUNs (confirmed that this is the issue by tailing /var/log/vmkernel).
No other LUNS have problems... just the ones that are presented to the cluster. We have other RAW device mappings to Windows VM's that work fine (and don't have the reservation conflict issue).
I was originally getting timeouts in the client, but increasing the timeout value to 10 minutes in the client makes it so I can add storage, but it is taking quite a long time (10 blades need to have this done).
The problem occurs when accessing the configuration either through VC or directly on the host itself.
Here's my question... is there any way to make ESX not touch those LUNs when performing tasks like adding new storage or this something I have to live with? Also-- am I doing it all wrong and is there some configuration that results in this not happening?
We have no performance issues, problems with fail-overs or anything else. The only problems come when trying to work with the storage.
Any thoughts or suggestions are much appreciated.
--Brad Watson
