Welcome to OUR GLOBAL IT COMMUNITY.

Very nice post, Kevin.

In my experience, servers very rarely chew up a lot of CPU unless they are very heavily utilized, and RAM isn't an issue when dealing with ESX server on a powerful box - we've always been able to run a ton of VMs at once, even with a lot of activity on each.

The performance issue almost always comes down to disk access - we would have SQL Server boxes returning results in 10x the time they should have because so many of the applications were reading from the disk (internal RAID array) at once.

Moving everything to a SAN and keeping the worst offenders segmented helped make everything run smoothly across the board.

Very nice post, Kevin. If I may, I would just like to remind Joseph that he can use Pass Through Disks for high I/O applications hosted on VMs, such as SQL and Exchange Mailbox servers. That will allow the VM to work against the disk in a manner that is very much the same speed and performance of a non VM machine.

Some other resources :
http://www.vmware.com/solutions/business-critic...
http://msexchangeteam.com/archive/2009/01/22/45...

mwvisa1
http://www.experts-exchange.com

Joseph,

My experiences with virtualization, especially dealing with hosting platforms such as VMWare's ESX server where the host operating system is capable of addressing large amounts of memory (e.g., 128GB) as well as taking full advantage of quad core processors (e.g., being able to allocate as individual CPUs), is that the guest operating systems seem to perform a little better with respect to the amount of memory and disk space needed; therefore, running light-weight web servers, etc. can run on 512MB of memory efficiently as an example. With the neat tools that graphically show CPU and memory utilization over a long period of time, you can really fine tune your standards for base (simple) servers to maximize the number you can have running. So advice here is to get beefy hardware, but still follow the principles of do more with less.

Now as to the mix, you definitely want to be cognisant of what is placed where unless you have a server with multiple RAID / Disk controllers and connectivity to a SAN.

My understanding is that if you have the resources to avoid putting MS SQL Server and MS Exchange on the same host then you should do so 100%. One compromise if in a farm situation is to have active node for a SQL cluster for example running on VM host 1 and passive (not really for SQL, but the one not being actively connected to by users) partner on VM host 2 and then switch that with Exchange having primary box on VM host 2. This way, you have some fault tolerance, but can operate at a more optimal state when all is running well. When there is an issue with one system, you can function in a less optimal (degraded) state while you recover services.

If you couple this with fine tuning the resource allocation per VM, you should be able to get a good mix, balancing application load. Just watch the CPU shares as what happens a lot is when memory is taxed then you move to paging which adds to your I/O which could in turn add to your CPU utilization keeping up with all the I/O. So you can have an application that is memory intensive with one that is I/O intensive and they end up clashing on CPU cycles.

To help some of this going back to standardization or tricks, one thing to push is separation of duties of servers again. Now that you can virtualize, push your vendors more to "divorce" the components / tiers of their application or only shop for those that have done so already. For example, some shops abuse the ease of Microsoft development and code in such a way that you must have their application server running on Windows with IIS and SQL also on this server. Aside from the huge security surface area discussion we can have, consider how much easier of a time you will have figuring out where to place these systems if you can crank out a base VM image for a web server, then a slightly beefier one for the application server and placing database on your existing SQL farm / instance(s).

Consider also that some applications again because they are Microsoft shops they build their application in all Windows but the application uses a Java Application Server and MySQL running on Windows. Nothing wrong with that of course, but again consider if you can run the MySQL on its own system maybe even Linux and having a Java Application Server on Apache or Tomcat or WebSphere Application Studio or the platform in your environment already optimized for Java and these kinds of web applications, then you can spread out this application wisely across systems without having to consider that every web application is also a SQL server is also an application server is also a file server, ad nauseam.

It may seem like a small point, but made a huge difference for me building a large IIS web farm running in VM. I simply moved the static files portion of the servers to a system that handles files (I/O) best (i.e., our File Server cluster) and then all that sits on the VMs are 10s or 100s of IIS web front-end servers that I can put up in a few minutes (at least strictly speaking of build time with deploy templates -- obviously organizational change processes take a bit longer, but even then the cycle is greatly shortened).

Anyway, sorry to have rambled on a bit, so to summarize or speak to questions specifically:

Is it a good idea to host two Exchange VMs on a single physical host?
+No I do not think it is a good idea to run two Exchange VMs on the same physical host (unless you are testing and this is a cost savings measure and not a production configuration).

Or is it better to mix an Exchange VM with a SQL host?
+Would not mix SQL and Exchange either; however, could mix Active SQL - Passive Exchange and Passive SQL - Active Exchange on two different VM hosts. And per my IIS separation comment, you can separate the web front end for OWA and it can run on SQL server VM host with Exchange store on other box.

Should I instead mix seven desktop VDI VMs with a single Exchange VM?
+The 7 desktop VDIs with Exchange would be better setup (under the premise they are still less intensive than a production SQL server).

Hope that was helpful.

Respectfully yours,

Kevin (aka mwvisa1)
http://www.experts-exchange.com

P.S. Here is some documenation:

Microsoft's Support Policies / Recommendations Regarding Virtualizing Exchange
http://technet.microsoft.com/en-us/library/cc79...

Virtualization Best Practice for SQL Server WebCast
(already passed, so can view online or download once registered)
http://msevents.microsoft.com/CUI/WebCastEventD...

Virtualization Best Practice for Exchange WebCast
(same as above)
http://msevents.microsoft.com/CUI/WebCastEventD...