Hyper9's Brian Mortimore offers up his years of experience and provides his answer to "What are the gotchas involved with virtualizing a SQL database application?" in this blog post: 

In my work as a virtualization administrator, I have found that I need to know a little bit about everything. After all, 'virtually' anything can be virtualized, right? Right? At least that is what the vendors keep telling me. In reality, we know better. Some applications are difficult to virtualize for one reason or another. One of the most challenging things to virtualize are databases. Databases are, by definition, IO monsters. You put stuff in, store it, then take stuff out. Sounds simple. However, adding the extra virtualization layer to the disk IO can take a perfectly good database and turn it into an unusable slug when virtualized. The more IO intensive the requirements of the database are, the worse the performance of the database will be when virtualized.

There is no magic bullet. There is not one single thing that can be done to just make all virtualized databases work better. However, here are a couple of tricks that I use. Well... actually a script to gather data, and a strategy of knowing as much as I can about the databases to be virtualized up front.

Know The Databases You Are Virtualizing

This seems like common sense. But when push comes to shove, it is pretty easy to take a P2V tool and just run it on a database host, import it to a VM on a hypervisor platform and call it good. This methodology might get us up and running our migration quickly, but will it really tell us what we have, or what operational risks you might encounter when using the migrated database? How about performing an audit of the database server to be virtualized prior to the migration? What? You are not a DBA? You don't know how? Let me give a few quick easy pointers for the VI Admin.

Ask lots of questions of the DB owner. Good questions to ask are...

• How many simultaneous SQL connections are made to each database?   
• Are there any non-critical transactions taking place? (debug logging to the db, etc.)
• Is the data primarily read or written or a balance of the two?
• What databases are the biggest? What Tables?
• What databases/tables grow the fastest?
• What recovery model is being used for the database and why? Does it need Full recovery and all the logging that requires?
• What is the backup schedule?
• What databases are used most often?
• What are the SLA requirements for each database?
• I noticed that the xyz_log table is taking 90% of your db storage, is that intentional?

Once you have some info on what you are migrating, take this opportunity to see if there is anything that can be done to optimize the data and it's utilization prior to migration. You will need to talk to the application owner to do this effectively. Communicate everything. If you are migrating multiple database servers, make sure that the balance of what databases are on what host makes sense. Feel free to use the scripts below to assist in gathering this type of data...

Read the rest of his post to find his Script, find out more about the Expected Application SLA, finding your limits, and using RAW storage to minimize disk IO problems.