Pros and cons of running SQL Server 2005 through virtualization on VMWare

SQL Server 2005
I have been asked to provide pros and cons for running SQL Server 2005 on one hardware (VMWare) for multiple groups of DBAs. The proposed plan is to have SQL Server 2005 Standard Edition with system administrators managing the server and DBAs not allowed to logon directly to the server (only through the Management Studio client). My questions are:

  1. How can we segregate our databases from other groups of DBAs?
  2. How do I prove it is not the best practice to manage SQL Server 2005 through virtualization?
  3. Is there going to be an issue with licensing if we run SQL Server 2005 on VMWare?

Answer Wiki


1. There are two ways to segregate databases from one set of DBAs or another. #1 Setup separate servers or instances and not give those DBAs rights to the server or instance. #2 Don’t give the DBAs sysadmin rights to the database. #2 is basically useless as the DBAs can’t do their job without sysadmin rights to the SQL Server. #1 is the method pretty much everyone uses.

2. Virtualizing SQL Servers is just fine, so long as the SQL Server’s can function with the resources they are given. If you hardware is a Quad Core, Quad Chip server with 64 Gigs of RAM, and your SQL Servers only need 2 CPUs and 2 Gigs of RAM, then virtualizing them will be just fine. If your SQL Servers need massive amounts of CPU power and RAM, then virtualizing them won’t work so well. This post may help.

3. Each virtual machine needs to be licenses just like it’s a physical machine. If you are using the CAL licensing method then each guest OS which has SQL Server installed needs to have a Server license. If you are using the CPU licensing then how ever many CPUs the guest OS has will each need a CPU license.

Do keep in mind that DBAs do need access to the OS. Unless of course the SAs want to be responsible for installing SQL hot fixes and service packs, keeping an eye on free space for the database server, handling DTC issues that come up (if you are using DTC), possibly debugging SSIS packages which work from the Developers desktop but not when scheduled on the SQL Server. Not to mention the installation of SQL Server. Odds are the sysadmin doesn’t know how the DBAs want everything laid out on the system (binary files, system databases, data files, log files, tempdb files, etc)

As a DBA is an SA told me that I wasn’t going to have access to the server (not physical access, but access via RDP) there would be a battle to say the least.

Discuss This Question: 3  Replies

Send me notifications when members answer or reply to this question.
  • Denny Cherry
    68,960 pointsBadges:
  • JennyMack
    You might want to check out Anil Desai's crash course in virtualization. He outlines which servers and applications are good candidates for virtualization.
    4,280 pointsBadges:
  • Hollecar
    A few questions? Are your dba's developers? Sql server dba's are the system admins for the sql server. Why would you restrict your dba's from the surface area of the sql server? Are your regular server admins qualified to be Sql server admins? It sounds like you are referring to restricting sql server developers not sql server dba's.
    10 pointsBadges:

Forgot Password


Your password has been sent to:

To follow this tag...




Share this item with your network: