You may initially be disappointed that VMware ESX does not allow you to install drivers for storage and network controllers (depending on your environment). I have determined why this is, and it is for the better. Let’s go through why this is, what you loose and what you gain.
The drawback to ESX using the proprietary drivers is that tools that go along with your environment may not be available. This is most visible in the storage arena. For environments using a SAN, certain commands that are part of your driver on physical servers that are SAN-attached are not available. For both storage and networking, the esxcfg series of commands can usually get you the information you need if it can not be done within VirtualCenter. For me, this was initially a frustration, but then I saw the light.
The proprietary drivers are really a necessity for the VMware virtual machine file system (VMFS), which in my opinion is the most underrated technology provided by VMware. The benefit of using VMFS outweighs the learning curve required for the esxcfg series of commands.
One of the biggest issues I had when transitioning to VMware from general purpose servers was the storage provisioning. When the storage administrator would present storage to the VI3 environment, the logical unit number (LUN) serial number was the key identifier to the storage. Without the native SAN tool, determining the LUN serial number was a challenge which I shared earlier in a tip on this site. After a small investment in the commands available, I was able to address all required functionality within ESX.
Consider the benefits of VMFS coupled with the use of the proprietary drivers to enable other features such as traditional VMotion and Storage VMotion. More information on VMFS is available in the VMFS best practices white paper.