Pardon the facetious Blog Post title, but I recently encountered and resolved this problem. It was a real head-scratcher until I stopped overlooking the obvious…
The environment had been installed and configured by someone else. So, I was hesitant to blow it all away and start from scratch. Besides, the Geek in me was curious to see if I could fix the problem. The most confusing part of the problem was that the servers could install vSphere to a SAN LUN and boot successfully from it.
I tried researching multiple articles via the Handy Field Consultant’s Guide (google.com), yet all I got were some bizarre explanations, none of which helped me.
As an experiment, I installed vSphere 5 on one of the test servers. Voila! I was able to write to the LUN. Oooooooooooooooh, it must be a DRIVER ISSUE?!?
I then used VMware Update Manager (VUM) to update the Cisco VIC (Palo) drivers on the remaining test server, and it also suddenly could write to the FC Storage.
Even though the servers were originally installed using the Cisco OEM vSphere 4.1 Build, an issue must have cropped up with interoperability between UCS and the SAN Switch vendor (non-Cisco) and\or the Storage Vendor (non-EMC and non-NetApp).
In any case, the appropriate driver is available either with VUM, vSphere 4.1 Update 2, or with vSphere 5.
So, if you are seeing similar behavior with your Cisco Blades and\or Rackmounts unable to create Datastores on provisioned disk, consider checking for new drivers, consulting your various vendors’ interoperability matrices, and testing on a single server as one of your troubleshooting steps.