PAVMUG Session – Virtualizing Business Critical Apps

For the September 2011 PAVMUG all day meeting, I participated in four sessions. To me, the session with the most audience participation was about virtualizing business critical applications. My session really dug deep into Microsoft Exchange but also covered some basics around SQL and Oracle. I wanted to expand some of the ideas that were discussed during the session and post the presentation slides.

The Benefits of Virtualization

First off, vSphere 5 provides for VMs that can have up to 32 vCores and 1TB vRAM. You can get up to 160 cores and 2TB RAM on each host. That’s a crap-load of compute power! With this scalability, vSphere 5 can handle the largest enterprise workloads so everyone can enjoy the benefits of virtualization. The obvious benefits of VMware vMotion, DRS and HA are available to ESXi clusters managed with vCenter Server. The less obvious benefits coming from the portability of VMs are the ability to use VADP to back up an entire VM (See my cautions below!) or use replication for disaster recovery. You also can create a clone of a running VM and put it in a zone that is isolated with a vShield so that you can perform development testing or patch testing. Physical systems can easily be converted to production VMs using VMware Converter so that you can enjoy the benefits of server consolidation (See my cautions below!). Creating templates that use guest customization will allow for rapid deployment of additional workloads.


Most ISVs support running your applications within VMware, including Microsoft and Oracle! Check out the support policies using the links below:http://www.vmware.com/support/policies/ms_support_statement.html

Windows Server Virtualization Validation Program



Most of the studies performed show that there is a performance overhead of 5%-15%, but by scaling out, you may be able to achieve smaller overhead. You should never have to worry about this overhead as long as you follow the application-specific recommendations published by the ISVs and VMware. All of these configurations are more about the settings of the VM or the underlying OS and application. The design of the vSphere environment is important, but it has more to do with providing sufficient resources for the dependent workloads.

For more information check out http://www.vmware.com/solutions/business-critical-apps/

Virtualizing Exchange

A study done by VMware shows that we can scale to 16,000 users with sendmail latencies lower than 500ms and transaction latencies of only 184ms with a 32% CPU utilization. That was using only 8 VMs. So if your Exchange guy says you can’t virtualize email you have some ammunition to prove why you can do it. Check out the new whitepaper Microsoft Exchange Server 2010 Performance on vSphere 5.

Exchange Best Practices

Most of the performance configurations can be found in the recommendations published by Microsoft on TechNet hereherehere and here.

Some of the recommendations for virtualizing Exchange are pretty reasonable. The first is to separate the various roles into separate VMs. I will be posting later on the benefits of running on Windows Datacenter Edition licensing, but trust me – it’s worth it.

Take a modular, building block approach. Limit the mail servers to 500 or 1000 users with two vCPUs and 16GB vRAM. Match that up in a 1:1 ratio with a Hub / Client Access server with 8GB vRAM. Take a look at TechNet’s Mailbox Server Processor Capacity Planning.

Make sure you pay attention to the back end storage IO capabilities (use RAID10 when appropriate). Also pay attention to the passive storage in DAGs and size your mail servers to handle it’s own active load and any passive loads that could potentially fail over to it. Use DAGs for site to site failover. If you are using DAGs solely for local availability, consider the less complex alternative of using VMware HA and the cost of losing mailboxes for the time it takes for an HA failover to occur.

For the VMs themselves, make sure you “right size” the vRAM and vCPU count. Too little will produce a performance issue. Too much will waste resources, especially in the new licensing model. Leverage the paravirtual IO devices, like the PVSCSI controller and the VMXNet3 NIC. Also be sure to flip on the hardware assisted CPU and memory virtualization in the server BIOS.

For more information about virtualizing Exchange check out http://www.vmware.com/go/exchange.


It appears as if the process of taking and deleting a snapshot that is associated with a VADP based backup can cause Exchange DAGs to fail over. From what we have seen, this may be associated with the VSS quiece and timeout settings of the DAG. For local DAGs, this may be a non-issue, but it could cause email performance issues if the DAGs fail over to other datacenters. If testing in your environment shows that this process causes a DAG failover and it is determined that this is unacceptable, use an Exchange client for backing up the mailbox servers.

Virtualizing SQL

Virtualizing Microsoft SQL will result in a performance hit of 14% or less, depending on the configuration. And this is on vSphere 4, so vSphere 5 will produce even better results. Check out this whitepaper for more information. According to VMware, “VMware vSphere 5.0 can match or exceed native performance for more than 99% of SQL instances. A recent TPC-E workload study demonstrated that in typical situations, virtual machines provide 90% to 98% of the native physical performance, even for larger 8 vCPU configurations.” Check it out on http://www.vmware.com/go/sql.

SQL Best Practices

The best performing database is one that is dedicated on it’s own VM. Whenever possible, only create one database per VM. If you are using Windows Datacenter Edition, licensing costs won’t be a problem. Although your DBA may complain about the additional work involved with maintenance activities, the benefit of isolated workloads and granular security isolation usually outweighs the extra work. If you want to reduce licensing obligations either create a dedicated ESXi cluster for just SQL databases or use DRS groups to create ESXi “Sub-clusters” and license only the physical CPUs that could potentially host a SQL workload.

For the VMs themselves, make sure you “right size” the vRAM and vCPU count. Too little will produce a performance issue. Too much will waste resources, especially in the new licensing model. Leverage the paravirtual IO devices, like the PVSCSI controller and the VMXNet3 NIC. Also be sure to flip on the hardware assisted CPU and memory virtualization in the server BIOS.Set the memory reservation to the active working set at peak workloads (configured size and reservation could be the same). Use eagerzeroedthick VMFS volumes (check FT box on VM creation in vSphere 4). Separate your disks bt workload – data, logs and tempDB.

Virtualizing Oracle

Basically, see above! Although the terminology may be different between Oracle and SQL, the basic principles of sizing and configurations are similar.http://www.vmware.com/go/oracle.

Common Best Practices

First and foremost, follow the proper methodology. Assess your present performance and model it. Have your VMware consultant use Capacity Planner or use the Microsoft Assessment and Planning Toolkit or Platespin Recon. Make sure you pay attention to disk IO and the required spindles to meet the load. You will probably end up with more space than needed. Make sure you design your virtual datacenter according to the data collected in the assessment and allow for growth. (its like crack – you’ll want more.)

The performance differences between VMFS and RDMs are minimal. Check out http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf. With that being said, data that already resides on shared storage should remain untouched during the migration from physical to virtual. VMware converter can ignore these disks and only convert the disks that reside on DAS.


When performing P2V conversions, make sure you shut down ALL transactional services, like MSSQL and Exchange. The IO related to these services could cause P2V performance issues or the act of running a P2V could corrupt data. Always perform a full backup before starting any migration.

Once the workloads are migrated, monitor them with the stock performance gathering that comes with vCenter Server or use more robust tools like vCenter Operations, CapacityIQ or Veeam Monitor to monitor performance of the VMs. COmpare this data to the data gathered in the assessment stage.

Additional Resources

Configuration Maximums for VMware vSphere 5.0

Setup for Failover Clustering and Microsoft Cluster Service

vSphere Networking [pdf | epub | mobi]
vSphere Storage [pdf | epub | mobi]
vSphere Security [pdf | epub | mobi]
vSphere Resource Management [pdf | epub | mobi]
vSphere Availability [pdf | epub | mobi]
vSphere Monitoring and Performance [pdf | epubmobi]

So what are you waiting for? Get out there and virtualize!