Is anyone running SQL 2008 on a ESX?

[Jay_2]

We have a new in-house programming team who have requested SQL 2008 to develop and run their aps. They use Microsoft Visual Studio and the app, once finsihed, will need to use a centralised SQL databse.

Also, what version of SQL 2008 would you advise for this?

thanks.

 

[Thuleman]

There are still a bunch of folks who insist on running databases on physical servers for performance reasons. From the sound of it though it would seem that in your case running SQL 2008 in a VM shouldn't be an issue performance wise.

As far as which version ...., you should ask the dev team that question.

 

[Cobalt2112]

We're not doing it, but if you have an 8 or 16 cpu ESX box then it should be OK to run SQL 2K8 on a VM with a few CPUs and 4+ GB of RAM. But, the price of an additional quad box to just run 2K8 may be more cost effective.

PS: Why not run multiple DB instances on different ports? You may not need an additional box. Google it.

http://www.mssqltips.com/tip.asp?tip=1048

http://www.sqlmag.com/Article/ArticleID/97439/sql_server_97439.html

 

[lopoetve]

Yeah, lots of them out there.

As a note, 1vcpu will 99% of the time OUTPERFORM 2 or 4.

People giving more than one vCPU - you're cutting performance. I guarantee it. ESX scheduling works differently than you expect.

http://www.vmware.com/pdf/esx3_ready_time.pdf

 

[sabregen]

Yeah, lots of them out there.

As a note, 1vcpu will 99% of the time OUTPERFORM 2 or 4.

People giving more than one vCPU - you're cutting performance. I guarantee it. ESX scheduling works differently than you expect.

http://www.vmware.com/pdf/esx3_ready_time.pdf

I've experienced this myself. It takes a while for sys admins to grasp the idea of letting the ESX scheduler handle the requests, and only grant 1 vCPU to the VM, it just defies the logic that they have come to know over the years. In most cases though, multiple vCPUs does indeed kill performance.

 

[lopoetve]

I've experienced this myself. It takes a while for sys admins to grasp the idea of letting the ESX scheduler handle the requests, and only grant 1 vCPU to the VM, it just defies the logic that they have come to know over the years. In most cases though, multiple vCPUs does indeed kill performance.

The only exception is if you've got something that's truly designed to require (note: REQUIRE) multiple concurrent hardware threads. Don't know of much out there that does except a few things I wrote myself

 

[agrikk]

I've experienced this myself. It takes a while for sys admins to grasp the idea of letting the ESX scheduler handle the requests, and only grant 1 vCPU to the VM, it just defies the logic that they have come to know over the years. In most cases though, multiple vCPUs does indeed kill performance.

Is this true for all apps or just SQL within a VM?

 

[lopoetve]

Is this true for all apps or just SQL within a VM?

all apps that do not require true concurrent hardware threads.

 

[exawatt]

Yeah, lots of them out there.

As a note, 1vcpu will 99% of the time OUTPERFORM 2 or 4.

People giving more than one vCPU - you're cutting performance. I guarantee it. ESX scheduling works differently than you expect.

http://www.vmware.com/pdf/esx3_ready_time.pdf

I would agree but I have had 2 different 2003 servers running inventory applications that improved 100% by adding a second vcpu.
But yes I would always start with 1 and if needed add another.

 

[[wizard]]

we run 2 instances sql 2005 databases on 2 vm's, each on it's own esx host with several other virtual servers on them. one of the databases run our large sharepoint enviroment, the other runs our crm, altiris, and other tools like websense and our monitoring software.

everyone has always told us to put the sql database on physical machines, being more concerned with platter time than cpu time. we have each of the sql databases running on their own LUNs that lay on our emc san equipment.

never had a problem with performance, but whenever i called microsoft about unrelated sql backup job issues, i had to convince them that the vmware tray icon was just for looks.

ymmv, but i will not hesitate to do the same with the 2008 server as soon as the developers start requesting.

all of our esx servers are running on hp dl380s with dual quad core cpus and 16-24gb of ram each.

the way these sql database servers where created has them running 4 vcpu's each... i think i'll be changing that during our next outage.

 

[lopoetve]

we run 2 instances sql 2005 databases on 2 vm's, each on it's own esx host with several other virtual servers on them. one of the databases run our large sharepoint enviroment, the other runs our crm, altiris, and other tools like websense and our monitoring software.

everyone has always told us to put the sql database on physical machines, being more concerned with platter time than cpu time. we have each of the sql databases running on their own LUNs that lay on our emc san equipment.

never had a problem with performance, but whenever i called microsoft about unrelated sql backup job issues, i had to convince them that the vmware tray icon was just for looks.

ymmv, but i will not hesitate to do the same with the 2008 server as soon as the developers start requesting.

all of our esx servers are running on hp dl380s with dual quad core cpus and 16-24gb of ram each.

the way these sql database servers where created has them running 4 vcpu's each... i think i'll be changing that during our next outage.

definitely give the CPU change a try- it's something that needs testing, and SQL is one of the few things that can sometimes benefit from it, but you won't know till you try.