Does DBA need (a read) access to virtualization infrastructure? And why? I am in charge of monitoring, troubleshooting, tuning and optimizing a few dozens production SQL Servers 2008 R2/2012 in my company that are being run inside VMWare virtual machines.  

I've requested a read-only access to VMWare infrastructure without much success. I feel that I should provide irrefutable and clear for non-technical people (company's management) proofs and illustrations why I need such access.

What are they?   

UPDATE:
Recently, I downloaded and "tried" Confio Ignite trial for monitoring "my" SQL Servers running inside (VMWare) virtual machines.    

  

Why is such access necessary?
Which of this info is important for DBA that cannot be got from Window's PerfMon VM counters?   



Related question:  


Can you explain me VM Performance Counters in Windows?
Short Answer: Yes.

There are many reasons but the few that stick to mind:

1.) Trust but verify - SQL cares a lot about its environment, the hardware or virtualized system it is on. When I help a company with SQL on VM issues it is normally a misconfigured VM. In many cases the idea of SQL on VM is about to be thrown away.

2.) DBAs should look at memory reservations, alerts and performance conditions, how overcrowded a physical host is ( or isn't) and understand how it works.

3.) DBAs are learning more and more about virtualization. Through excellent blog posts and SQL events, the VMware knowledge in the SQL dba community is rising. An extra set of eyes may help ensure things are well tuned and future proofed.

4.) Prove yourself... If you've done everything right and built a great environment, show it off. Read access to center isn't going to destroy your system and you can show those pesky DBAa everything is up to snuff. And if it isn't? Don't you want to know? ;-)