When Ronald Reagan said, “Trust, but verify,” he was talking about DBAs working with their VMware sysadmins.
As a consultant, I get to see a lot of SQL Server implementations – both successes and failures. The successes have one thing in common: transparency. The database administrators, VMware admins, and storage admins have clear, open discussions about the way their respective systems are configured. They give read-only access to other teams so everyone can double-check to make sure everything is working well. After all, these teams share a common goal – fast, reliable applications for end users.
You can easily get read-only access to the VMware vSphere Client, the tool VMware admins use to manage your virtualization environment. Here’s how:
1. Walk over to your sysadmins and show them this blog post.
This is the hardest step in the entire process.
The rest of the steps are simple and predictable: click a button, get a result. This step, however, involves complex, unpredictable meatbags. Soft skills are the hardest one to master, and finessing this is outside of the scope of this particular article. Start by brushing up with my Consulting Lines series.
You need to walk over there because you’re asking for access into their domain. This implies that you don’t trust them. You do, but like Reagan said, you just need to verify.
2. Open VMware vSphere, Home, Hosts and Clusters.
The vSphere Client is a thick front end that connects to Virtual Center, a service that keeps an eye on your hosts and guests. In the vSphere Client, click Home, Hosts and Clusters. Here’s a screenshot of what you’ll see:
On the left side, click on the thing you want access to – which brings up the first question for your VMware admins: what do you need read-only access to? Your VMware sysadmins may have built a separate cluster just for SQL Server use, or your VMs may be intermingled with other virtual machines.
On the right side, click the Permissions tab, right-click, and click Add Permissions.
3. Add the DBA domain group.
In the Add Permissions popup, click Add. In the dropdown for domain, choose your Active Directory domain, and in the Users and Groups dropdown, click Show Groups First. Your screen will look like this:
In my lab, I’ve created an Active Directory group called “Database Administrators” that includes me, Jeremiah, Kendra, and Tim. That way, anytime I need to grant additional permissions for the DBAs (like when I build a new SQL VM that they’ll need to administer), I can just use that domain group instead of individual user accounts.
Click your own DBA group’s name, click Add, and click OK. On the right side of the Assign Permissions window, the Read-Only permission will be defaulted, and that’s fine – click OK. Presto, you’re in.
If you click on child objects in the left tree (like one of your SQL VMs) and click the Permissions tab, you’ll notice that your read-only permissions have propagated to this object too.
4. Install the VMware vSphere client on your desktop.
The client is a free download from VMware.com as part of other products, but the easiest way to get it is to simply point your web browser at one of your in-house VMware hosts. In my lab, here’s what that looks like:
Click the Download vSphere Client link and the installer will come flying through the tubes. Yes, the installer includes Visual J#, and yes, I laugh at that too.
5. Launch the vSphere Client and start poking around.
After the installation finishes, double-click the VMware vSphere Client icon. You’ll need to enter the name or IP address of your Virtual Center server – ask your sysadmins for that. Check the box labeled “Use Windows session credentials,” and thanks to the magic of Active Directory, you’ll be poking around in virtualization in no time. (Actually, it takes about 30 seconds to launch the dang thing.)
Want to Learn More?
Check out Virtualization, Storage, and Hardware for the DBA. It’s our 5-hour training video series explaining how to buy the right hardware, configure it, and set up SQL Server for the best performance and reliability. Here’s a preview:
Amen Brent! I’ve had access into VCenter for about 6 months now. I also have access into our SAN monitoring system as well, so I can “Trust but verify” with my Storage Admin. We’re all human after all, and mistakes happen. Think about the coolness of thin-provisioning, when a 300GB LUN is made inside a 350MB volume. I lived through that when a LUN went quickly offline after doing a move of existing log files to a newly provisioned LUN and volume. I now “Trust byt verify” everything.
I was trying to access the 3 hour video on how to manage SQL Server in VMware and it appears to be broken.
It’s no longer for sale.
When will you make your 3 hour video available for sale. Would love to have it.
Sridhar – we don’t have anything to announce at this time. 😀
Why is it not for sale any more?
Tony – actually, it is! Go ahead and check out the bottom of the post for the latest links.
Another way of putting this is Trust But *Visualize*. Those of us who’ve done any kind of PC support, whether for work or just for our moms, know that there’s just no substitute for seeing what’s going on either via some kind of screen sharing technology or being in the room. It can cut troubleshooting time down drastically.
I thought this was an excellent article which is why I wanted to ask you a follow-up question. If you work for a company that supports customer’s VMware installations (i.e.. you are one company and customer is another company) is it feasible to ask customer for a read-only access to their VMware tools? If not, what could be done instead to understand events that affect VM installations you support remotely?
Ivan – thanks, I appreciate it. Yes, as I write in the post, it makes sense to ask for read-only permissions into VMware.
Brent, Thank you very much again and please accept apologies for misspelling your name. I should know better and I deserver Ivan 🙂