Tips for Navigating SQL Server VM Conversions

By:   |   Comments (3)   |   Related: > Virtualization


I'm a SQL DBA and I just attended a meeting with the storage and server teams. They told me that within the next month they will be converting all our SQL Servers to VM. They didn't even ask my opinion!? What should I do?


I'm sorry to be the one to give you Dear Abby tough love but by the time you get to a meeting about converting your SQL servers to VM the decision has already been made and there isn't much you can do about it. The worst thing you can do is fight the change. The CIO, CTO, CFO, and all the other C's have crunched the numbers. It's a win-win for the company. Take a deep breadth and look around the room. You'll need most of those people.

Keep in mind the company isn't jumping off a bridge and pushing the technical envelope. VM technology has been around for a long time. Still, only recently have certain developments made it a more acceptable platform for high transaction applications like databases. Vendors have dramatically increased IO efficiencies and they've begun to write software which directly communicates with RDMS API's like SQL Server. Vendors such as VMWare and HyperVisor know that to truly take marketshare they have to account for these systems. A company can purchase faster, more expensive hardware knowing that the VM environment will better utilize the available capacity than if they purchased a physical system.

VM Checkpoints

OK. You're in the meeting and you've taken deep a breathe. You don't have to be a passive DBA - there are things you can and should do to control the environment. Here are some pointers:
  • Control your resources
  • Demand access to VM monitoring tools
  • Show management you're onboard but set expectations
  • Develop strong working relationships with the storage and server teams
  • Be part of the process
  • Read the documentation
  • Don't blame all post-VM errors on VM

Control Resources

What will most likely occur is you will have a physical SQL server running two quad-core processors. The server team will P2V the system (convert a physical server to VM) and you'll end up with one dual-core processor. You just went from eight to two processors. This will strike fear in your heart and especially in the heart of the customers utilizing the server (my advise - don't tell them). What you need to understand is the processors are 4x faster than your old processors and, if you need more, they can provision them with little to no downtime. Yes, I was skeptical at first and you should be too but 9 times out 10 it will be Ok. Still, understand the process but don't hesitate to ask for additional I/O provisioning if users complain. The company is still coming out ahead.

Perfmon Lies

I plan to write a tip called Perfmon Lies. I cannot even fathom the amount of scrambling vendors are going through knowing that any metric relying on Perfmon is of little to no value in a VM environment. VM is all about provisioning. If Perfmon shows your CPU running consistently at 90% than, in the year 2011, that's a good thing. The CIO will pat you on the back and say "thanks for optimizing our resources". If CPU hits 100% than VM will say "You look like you're stressed. Here you go but don't keep it for too long". As a DBA you still care about performance and that's why you need access to the tools that monitor the host. If you're using VMWare then VSphere is what you look at. Hey, but there are still VM monitoring counters in Perfmon so all is not lost.

Are you a Team Player?

The basic point here is don't fight the power. In fact, the data center power savings alone by implementing VM could pay for 20 DBAs. Let's not mention the reduced rack space. The point is that VM saves the company money. BIG money! But in a corporation money is relative to its competitors and, guess what, all the competitors are implementing VM. So what I say to management is "let's do VM, but let's do it right". Put customers first by responding to problems and managing expectations.

Do Not Unfriend

I've been in IT for a long, long time and skills come in waves. We've travelled from mainframes to desktops. We've gone from opensource to...well...non-opensource and back again. I remember when SAP skills were all the rage and then if you knew Peoplesoft you could write your own ticket. Now it's Infrastructure. I don't fault them. As a DBA I've seen exponential growths in storage and resource utilization. Something had to contain the flow. VM is the current solution to the problem of operational growth. What does this mean? The storage and server teams are padding their resumes with VM technology. That's OK. Be their friends because you need them more than ever.

Be Involved

This goes back to how in your first meeting you don't stick your head above the parapet. If you do then you instantly become an outsider, if you don't then you become a resource. As a resource you're an insider and will have a say in the process. Moving to VM is not a bad thing. Participate and contribute. The other teams will value your input and respect your observations.

Yes..Someone Did Bother to Document

Actually there are some exceedingly smart people out there who have documented how VM will affect SQL Server. It first depends on your VM solution and your hardware. Are you using VMWare? NetApp? Hyper-V? Regardless of the solution there is vendor documentation and people like me that ramble about this technology. Read about it. Educate yourself. What you do know may hurt you but what you don't know can also hurt you - you just won't see it coming.

Don't Blame Change

This is huge. When you or another department does a P2V and the next day the customer complains that they're getting login failures or SSPI issues please, please don't say its because of the VM conversion. I've been through more than 300 SQL P2Vs and I can attribute only about five problems to the conversion. All my problems were attributed to resource allocation. Once I/O was provisioned to the VM host everything was fine. There are some applications that might have problems but this is the exception and not the rule. I will not say there aren't problems but I haven't encountered showstoppers. For customers, converting to VM can be psychologically straining, as an IT professional it is your responsibility to calm their fears and ease their worries.

Next Steps
  • Brent Ozar broke the seal on the VM DBA jar: Virtualization Best Practices
  • Wow! Jeremy Kadlec talked about VM in 2007. What are you waiting for? Virtual Server Technologies and SQL Server
  • Guess what the next step will be? All test environments will be VM.
  • I'll be at the PASS SQLRally. Will you? My presentation is about the Enterprise DBA. Hope to see you there! Say hi and, by the way, I like aged Scotch. PASS SQLRally.

sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip

About the author
MSSQLTips author Scott Shaw Scott Shaw is a Lead SQL Server DBA with extensive experience running SQL Server in a virtualized environment.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips

Comments For This Article

Monday, February 28, 2011 - 12:45:59 PM - Ian Miller Back To Top (13064)

A couple of things that didn't really come through.  You really need to talk to the vendors of the Virtualization software that you are using.  Make sure that you follow their recommendations for virtualiziing SQL Server.  One other thing that we have found is to not accept commodity LUNs that your SAN/NAS Team provisions through to the VM Host.  You should still be using the appropriate RAID configurations for the type of transactions your SQL Server is providing.  The SAN team simply needs to provision the LUNs accordingly and pass that to the VM team.  The VM team can then allocate the LUN to a virtual disk for your VM to use exclusively.

Monday, February 28, 2011 - 12:06:11 PM - John Fox Back To Top (13061)
It would be nice to read about some dos and don'ts of running SQLServer on VMWare. I really don't like waiting for something to fail for our admins to discover that even thoughthe book says you can do something, it doesn't mean it will work. I know of two things. First, don't journal the database server. Our admins did that and discovered just how slow you can make a databse go. Second, SAN snapshots thorough a VM server defined volume are verrryyyyyyy sloooowwwww. What is a good DR method that allows for quick and transportable snapshots but provides some VM capability.

Monday, February 28, 2011 - 10:38:51 AM - alen Back To Top (13060)

you forgot to mention the DR benefits. the old SQL way was a huge book of documentation to change a bunch of things to point apps to new servers, etc. with VM you just ship you VM files over the network to a DR location and mount them on another vmware instance and change the IP

get free sql tips
agree to terms