Page 1 of 2 12 LastLast
Results 1 to 15 of 17

Thread: Vmware

  1. #1
    Join Date
    May 2002
    Location
    Cape Town , South Africa
    Posts
    30

    Cool Unanswered: Vmware

    HI ALL ,

    Has anybody had any issues with SQL2005 on VMWARE?

    Thanx
    Burner

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Yes, I've had some problems running SQL2005 on VMWARE, but not as many problems as I have with SQLL2005 running without VMWARE.

    -PatP

  3. #3
    Join Date
    May 2002
    Location
    Cape Town , South Africa
    Posts
    30
    problems such as?

  4. #4
    Join Date
    Jun 2007
    Location
    Ohio, USA
    Posts
    142
    David Maxwell
    Data Integrity? Yeah, I've heard of that...

  5. #5
    Join Date
    May 2002
    Location
    Cape Town , South Africa
    Posts
    30
    Yeah I read and spoke to a MS rep this morning .But i would still like to know what type of issues and if anyone is running SQL2005 on VMWare successfully

  6. #6
    Join Date
    Oct 2006
    Location
    CA
    Posts
    210
    I'm also curious.

    I want to do some upgrade testing (to x64 and SQL 2000 to SQL 2005).

    I bought a spanking new 8-core processor (2x4-core) as an overpowered Domain Controller with my plan to dedicate several cores for this test server.

    I don't want to run production in an unsupported environment but is it fine as a test environment? In particular; are there "lots of shops" out there running SQL-2005 on a VMWARE v-machine successfully?

  7. #7
    Join Date
    Sep 2002
    Location
    Ohio
    Posts
    204
    Yes, we run a number of non-production SQL Server 2000 and 2005 databases on virtual machines. This is becoming our defacto standard for Dev and test servers.

    We have not had many issues that I am aware of. We have a pretty good server team and they have done a great job of getting the virtual machines ready for SQL Server. They only thing we haven't done is found an application with a test harness big enough to stress the I/O on the virtuals. I/O concerns are the last big hurdle to putting our first production databases on virtual machines.

  8. #8
    Join Date
    Oct 2006
    Location
    CA
    Posts
    210
    Thank You. That helps.

    In reading this MS Publication on VMWARE Domain Controller considerations it does make one skidish about what else is in the mix and what else is sharing the physical drives.

    I'm sort of thinking to not share physical drives between VMs, since my box is part Production (99% dormant Domain Controller), part Test. Wish I had a "server team" - settling for a "network guy" who's pretty good but can't know everything.

  9. #9
    Join Date
    Sep 2002
    Location
    Ohio
    Posts
    204
    Good point about the drives. I should point out that all of our database servers are SAN attached and that seems to work out well with the virtualized I/O. We have not had to deal with sharing of physical drives on a server.

  10. #10
    Join Date
    Jun 2007
    Location
    Ohio, USA
    Posts
    142
    In my experience, which I admit is a bit limited, most of the problems of running SQL over a VM are based on poor VM implementation. As long as your VM's are configured properly, you should expect proper performance out of SQL.

    Check with your vendors for their best practices for implementing SQL Server on their various platforms.
    David Maxwell
    Data Integrity? Yeah, I've heard of that...

  11. #11
    Join Date
    Jun 2004
    Location
    Long Island
    Posts
    696
    Quote Originally Posted by Burner
    Yeah I read and spoke to a MS rep this morning .But i would still like to know what type of issues and if anyone is running SQL2005 on VMWare successfully

    We've had no issues here, but our VMs are NOT production, only staging.

  12. #12
    Join Date
    Jun 2004
    Location
    Long Island
    Posts
    696
    Quote Originally Posted by vich
    I'm also curious.

    I want to do some upgrade testing (to x64 and SQL 2000 to SQL 2005).

    I bought a spanking new 8-core processor (2x4-core) as an overpowered Domain Controller with my plan to dedicate several cores for this test server.

    I don't want to run production in an unsupported environment but is it fine as a test environment? In particular; are there "lots of shops" out there running SQL-2005 on a VMWARE v-machine successfully?
    vich, just did a major upgrade from SQL2000SP3a to SQL2005x64 on A/A/P cluster, and a majority of our performance issues were related to statistics (run sp_updatestats nightly and parameter sniffing, simply flip flopped input variable to declared variable in sproc(s)), and these 2 steps seemed to have resolved a majority of our performance issues. H/W 4X4 Core, 64GB RAM, EMC SAN.
    Last edited by PMASchmed; 08-19-08 at 15:31.

  13. #13
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Aside from making a deadly mistake of running production on VM, having it for test/dev is not a problem. Issues are caused primarily by installing VM on non-VM-certified hardware. They manifest mostly through IO subsystem failures that are misreported by VM driver to the OS, and then misinterpreted by OS, which leads to total confusion when trying to identify the root cause. Check with your HW vendor.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  14. #14
    Join Date
    Oct 2006
    Location
    CA
    Posts
    210
    Quote Originally Posted by PMASchmed
    vich, just did a major upgrade from SQL2000SP3a to SQL2005x64 on A/A/P cluster, and a majority of our performance issues were related to statistics (run sp_updatestats nightly and parameter sniffing, simply flip flopped input variable to declared variable in sproc(s)), and these 2 steps seemed to have resolved a majority of our performance issues. H/W 4X4 Core, 64GB RAM, EMC SAN.
    So you're saying I should redefine all the SP input variables and not reference them within the SP beyond the initial value transfer. I'll dig out a conversion guide when I start testing but that's a great tip (that I'd certainly never have known to do). Thanks!

  15. #15
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    A simple definition of parameter sniffing is the act of modifying the passed parameter values, so you should review your procedures for cases tlike that.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •