Help with Consolidation Analysis results

[bbricker]

My Virtual Center Consolidation analysis has completed on a physical server I am analyzing for putting in VMware for the last few days. I do not want to P2V it though, as it is a Windows 2000 SQL server that I am going to rebuild from scratch as a Win2k3 x64 + SQL 2005 x64. So, without doing the actual P2V process (I assume it will start that when I proceed with "Plan Consolidation"), how can I find out what Virtual Center Consolidation is recommending for my new VM? I want to know if it recommends 2 vSMP procs and how much memory.

thanks

[VMmatty · Accepted solution]

The Consolidation software build into vCenter is like a super scaled down version of VMware Capacity Planner that is available only to VMware partners. That tool can give you more information on how to size the workload based on its current utilization. You can use Perfmon on the physical server to get an idea of the total utilization of the CPU, memory, disk, etc. Unfortunately you won't get those details with the Capacity Planner tool build into vCenter.

What are the specs of the physical server?

[bbricker]

Well that's just simply irritating. Nothing worse than a completely crippled tool that gives you virtually no information... they should rather have just left the "feature" out of Virtual Center if it wasn't going to be useful 😐

Anyway- the physical box is a SQL 2000 Enterprise DB server with 2 processors and 8GB ram. It's a fairly old Dell 6650 server so I am curious as to if I can get away with a single processor in my VM so that I can use the new Fault Tollerance that I've been looking forward to. The ESX server is a brand new Dell R710 fully loaded. The current server is part of an MSCS cluster which I've had serveral issues with and will not continue to use -- so I'm very anxious to move to FT, if I can use a single proc. That was the kind of info I was hoping to get the Consolidation Planner to tell me but I guess knowing how many vSMP's to add is just too much detail for it to give me without paying a VMWare specialist to come look at it for me... rolling eyes (sorry for the rant, been dealing with Dell and VMware on SnS renewal issues for a month and the run around and delays has turned me quite sour!)

Anyway- Perfmon shows average % CPU usage at around 17% so I think that is a good sign. Average % PhysicalDisk idle time is at about 84%, and average memory Pages/sec seems to be changing constantly but was around 8 last I checked, with spikes to 130+. I'm no expert with Perfmon, these were all counters already set by the application people that monitor that SQL server.

[VMmatty]

I agree that the Capacity Planner plug-in for vCenter is practically useless. It is useful to find servers that are particularly bad virtualization candidates but beyond that it doesn't do much.

I think you'd most likely be ok with a single CPU on a modern processor for your SQL server. It is fairly easy to add an additional processor to a VM if you find that you are bound by CPU instead of another resource. I assume you're using a 64-bit version of Windows 2000 so that you can take advantage of all 8GB of RAM?

One thing I'll throw out there is that VMware Fault Tolerance is not the same as MSCS clusters and, in my opinion, shouldn't be thought of in the same way. If your SQL server were to crash or bluescreen, but copies of the FT VM would bluescreen at the same time. FT should only be used to protect against hardware level failures, whereas a cluster can help protect against both hardware and application level failures. FT certainly has its place and is a powerful too, but I think it's important to understand that it isn't the same as MSCS clustering.

[bbricker]

Thanks for the response. Windows 2000 doesn't have an x64 version option, but we are using the AWE memory with /PAE boot.ini trick to use all the memory. The new server will be Win2003 x64 and SQL x64 though.

That is a good point about FT versus MSCS that I really hadn't thought of. I don't believe we've ever had a software/application crash or BSOD with our SQL server though, and I would hope that becomes even less likely in a VM environment (I've never seen a VM crash here, knock on wood). But regardless, that is something I need to keep in mind and I appreciate you bringing that to my attention.

[VMmatty]

VMs do still bluescreen unfortunately (I've sadly seen it firsthand) but you're right that it should be less frequent because you're removing the hardware from the equation. Don't get me wrong, I really like FT as a feature to protect applications from hardware failures. It's especially useful for applications that don't have any kind of clustering available. I just don't think it's really the same as MSCS clusters and both have their places.

If you think you may need to go up to multiple vCPUs on that SQL server then just be careful about relying on FT. Right now FT doesn’t work with more than one vCPU so I'd hate to see you get stuck in a situation where you're relying on FT for your design and you suddenly lose the ability to use it. Hopefully that restriction changes in the future.