SQL Server 2K5 on VMWare

  • Has anyone had any experience of putting SQL Server 2K5 or even SQL Server 2K on VMWare.

    I am not a fan of this approach which is being suggested at the place I work. I have been aggainst this, but I have no experience or knowledge to back up why I am opposed to putting SQL Server on VMWare.

    I was hoping someone has had some experience with this environment and could let us know how well it worked or not.

    Dave Novak

  • If you are spending the money and doing it correctly, your company will be purchasing VMWare licenses and using a version of VMWare that directly virtualizes rather than running over Windows. Doing this works fine and SQL 2000 and SQL 2005 are fully supported. I have never had any issues doing this and proper virtualization in this way seems like a good idea to me.

    The "free" version of VMWare that runs on a windows operating system does not support SQL Server. Because of conflicts between the windows OS and VMWare, the read and write buffers do not report correctly and you can write something to disk and try to re-read the same information before it is actually accessible. You will typically see this in TempDB when something has been written to a hash table during a join operation. These errors are pretty unpredictable and lead to instability.

    So, my answer is don't cheap out when trying to do this.

  • Michael,

    Thanks for the info. We are using the ESX licensed version of VMWare. We have run into quite a few problems with the freeware version on other applications that we are not using it for anything.

    I appreciate the info on your experience with this environment and will go ahead accordingly.

    Dave Novak

  • Yes, we've used it in our non-production environments. We've also had a couple of cases with SQL Server 2005 Express Edition in production. A lot of it depends on the hardware config, just as with a physical server. It's probably not the solution you want for a transaction-heavy system in production, but it works well enough for lightweight stuff.

    Do you have any specific concerns?

    K. Brian Kelley
    @kbriankelley

  • We have been running SQL 2005 on an ESX server using VMWare since January. It has been running smoothly.

  • We successfully ran a 2K5 instance inside of an ESX session without any troubles at my previous employer. We were actually able to run it with less "hardware" than it would have needed if it were on its own box.

    There was an article, I believe in SQL Server Magazine, that we reviewed before setting this up. Some of the information didn't apply to our situation but it may be a good read for you.

    As one previous poster said, I also would not use this in a heavy transaction environment. Ours was not heavy and only had ~200 users so it was a good solution.

  • We have numerous instances of SQL 2000 & 2005 running under VM; works well if you understand the limitations(memory, cpu, overall performance). We generally are using it for our development and QA environments but we do have several used in production. For us it has saved $$ and allowed server consolidation.

    - Mike

  • It was my understanding that Microsoft does NOT support SQL Server running on VMWARE. Unfortunately I learned this after we had two test servers up and running on VMWARE. We had no problems but they were very low end apps. I personally would never run a prod SQL Server on VMWARE. But, that is just me. If others are doing it and it works great.

  • I've used SQL on VM and as long as the CPUs or RAM on the host aren't oversold then it isn't too bad. Of course, it could be faster because the host in my case was not set up to provide independent drive channels for logs vs indexes vs data files and other SQL Server tweaks. Therefore, I think the best approach to server consolidation for SQL is to pile multiple instances on one server that's dedicated to SQL Server's particular requirements which are often quite different than the generic VM server you get handed by the VM host admin. I've also worked somewhere that used this - there were consolidated DB servers and consolidated everything else servers. The DBAs had a strong say in how the DB servers were configured. It was a LOT better for everyone - management got consolidated servers and the DBAs got customized machines that were best performers compared to generic VMs. I would suggest you suggest the idea of consolidating all the SQL Servers but in this way instead of the VM way.

    If that doesn't work out, well, your host server may still meet your requirements; I advise you to go over these concerns (overselling, storage configuration) with the admin and/or whoever is in charge of spec'ing it out, point by point and not just in a general 'VM good/VM bad' way. Oh, and don't forget to ask about expandability; what if you determine you need another 2GB of RAM? Can your department simply buy it for the host and get it allocated to your VM or will it be some huge beauracratic deal? What if the host server only takes increments of 4GB?

  • This all has been some very good food for thought. It looks like the hardware folks here at my company are going to go the way of either a dual processer dual core blade or a quad processor dual core blade with a SAN for the storage. There will then be a second identical blade used for high availability. We will put multible instances on the blade. If we need additional development database servers, then I will suggest the virtual route instead of scrounging for a server we can use or purchasing a new one.

    Dave Novak

  • We use SQL 2000, 2005, and 2008 (non-production) on VMWARE. As most everyone else has stated, as long as you are smart about the configuration of the guest OS, you should be fine.

    Another member mentioned that Micro$oft does not support MSSQL on VMWARE. That is absolutely true, because they want you to use Virtual Server and Hypervisor. Both of which, in my humble opinion, do not measure up to VMWARE.

    Best of luck to you!

    Regards, Irish 

  • That's not 100% true of Microsoft's support policy with regards to Microsoft applications on non-Microsoft virtualization. That policy is stated here:

    Support policy for Microsoft software running in non-Microsoft hardware virtualization software[/url]

    K. Brian Kelley
    @kbriankelley

  • We have over a 100 servers running in a VMWare environment with no major issues. They are a mixture of test, dev and production, both SQL and non SQL.

    Within a year most of our applications should be running on a VMWare platform. This includes our production SAP servers as VMWare is now supported by SAP for productive environments (some of our dev and test instances are already running under VMWare).

  • My main production 2005 SQL Server is a physical box but recently I have deployed a new track of SQL Servers on VMWare and they have been running fine thus far. One thing we did to try to maximize the benefits of virtualization and keep SQL best practices intact was to break up the server in to several vmdk files (one for system, one for log files, one for database files, one for backups). Each vmdk file was further seperated on the SAN by being on different LUNS which are each on different physical shelves. All these configurations, coupled with VMWare's HA technology and a solid SQL backup scheme seems to be working pretty well for us thus far. We're also starting to delve into the Data Domain product which looks pretty cool. We'll probably start doing backups directly to DD soon.

    =============================================================
    /* Backups are worthless, Restores are priceless */

    Get your learn on at SQL University!
    Follow me on Twitter | Connect on LinkedIn
    My blog: http://sqlchicken.com
    My book: Pro Server 2008 Policy-Based Management

  • We've run both SQL 2K and 2K5 on VMWare in both prod and test environments. We even had a really beefy OLTP db suite running on it for 3 years with periodic limited performance issues only. Though it has been schmoove for the most part, nothing beats cold, hard, steel for your host system though when it comes to performance.

    I'd recommend it for lab and dev instances without a doubt. But forget trying to performance tune a test instance or prod instance on VM.

    - Tim Ford, SQL Server MVPhttp://www.sqlcruise.comhttp://www.thesqlagentman.com http://www.linkedin.com/in/timothyford

Viewing 15 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic. Login to reply