I wanted to announce the availability of new book "[Virtualizing Microsoft Tier-1 Applications with vSphere 4|http://tinyurl.com/2cgk3fu]" that I have co-authored with Charles Windom and Alex Fontana.

As you all know Microsoft Windows-based servers dominate the server market, accounting for more than 70% revenue as well as server shipment in 2009, per IDC. Naturally, as these servers and applications running in there get virtualized, IT professionals are seeking guidelines and best practice recommendations for virtual deployment. Application administrators, e.g. managing Exchange and SQL Server, already have the subject matter expertise in their respective areas, and looking for virtualization specific knowledge. And that's exactly what this book is trying to address. Check it out and let me know what you think.

Also note that I spent lot more time discussing VMware's management products at VMware Virtualization Management Blog.

Several VMworld presentations and best practice documents suggest that customers create fresh VMs, and do NOT convert an existing physical server to a VM (P2V), especially in case of  Citrix XenApp/Presentation Server and Terminal Services. I frequently get asked why the rationale behind this - recommending against one of VMware's own products. So here's some explanation.

P2V using VMware Converter is usually more convenient, and faster to create VMs. However P2V can result in two key issues: larger VMs, and extra processes within a VM. Both can have serious impact for VM performance. 

Most server class machines today have 2 sockets or more with at least a single core processor in each socket. The newer machines have multi-core processors. Add to this the fact that almost all physical servers are over-provisioned, with average CPU utilization at best in teens. Consequently, P2V invariably ends up creating larger VMs. Larger VMs means higher SMP related virtualization overheads and reduced DRS effectiveness.

Also most OEM vendors may have admin tasks/services such as SNMP agents etc running in background on physical servers. These additional services can result in several performance issues such as IRQ conflicts, polling/interrupt driven processes; all of which will typically exaggerate virtualization overhead after P2V.

Citrix XenApp/Presentation server (CPS) and Terminal Services environments are especially sensitive to larger VMs, and extra processes within a VM. CPS and Terminal Services are multi-user environments, with each user session running a number of processes. Consequently this environments exhibits high number of context switches between various processes, lot of process creation and destruction and lot of paging and page faults. All these place a heavier load on the Memory Management Unit (MMU) as a result. The above two issues in P2V'ed VMs - SMP related virtualization overheads and having additional processes running in a P2V'ed VM just aggravates this further. Hence the best practice recommendation to start with fresh VMs. And stick as fewer virtual CPUs as you really need.

Of course, in real-life, production environments, performance is just one of the considerations e.g. you may have a old windows server with some legacy OS/application stack, for which you cannot do a fresh install, recompile or port to newer OS. And so P2V is the best available option. In that case, watch out for the following things:

• Before you Power on the new Virtual Machine after P2V, edit the VM settings to reduce the CPU count and memory, adjust the Windows HAL to UP version if needed, remove any other peripherals not required

• Before P2V or after the P2V'ed VM is powered on, turn off and disable all unneeded processes and services.

You will need to spend some additional cycles, but you can make it work.

The newer 2nd generation hardware assist processors - AMD Barcelona/Shanghai and Intel Nehalem - do enable MMU virtualization, and can hide these issues to some extent. Having a cleaner VM, though, will definitely benefit performance.  

Let me know if you have run into any other performance issues with P2V'ed VMs.

Recently I published the Microsoft SQL Server and VMware Infrastructure best practices white paper.

What’s the purpose of this paper?

Microsoft SQL Server is a very popular and widely deployed general purpose database server supported on Windows Sever operating systems. As customers embrace a “virtualize first” policy for all applications within their enterprises, they often need guidelines for deploying SQL Server in VMware Infrastructure. This paper helps to answer the two most common questions I get:

• How do we characterize our SQL Server databases for virtualization?

• What are the best practices for virtualizing SQL Server using VMware Infrastructure?

What’s key take away from this paper?

You can virtualize SQL Server successfully using VMware Infrastructure. Vast majority of SQL Server deployments are good candidates for virtualization and can benefit from improvements offered by a virtualized infrastructure — such as improved management, availability, and scalability — thus reducing overall TCO.

VMware Infrastructure also makes it simpler and less expensive to provide higher levels of availability for SQL Server by using key VMware Infrastructure 3 features such as DRS, HA, and the SRM plug-in. You can continue to leverage the most common SQL Server high availability implementations, such as failover clustering, database mirroring, and log shipping in VMware Infrastructure.

How would you characterize a SQL Server instance for virtualization?

To deploy a SQL Server instance successfully in VMware Infrastructure, you must clearly understand business, technical, availability, and other operational requirements for implementing the particular SQL Server instance. You must then establish a baseline, using data from the current running physical deployment. Using this baseline, you can create a short list of SQL Server instances to virtualize and determine the order in which you should virtualize the SQL Server instances. Together, the requirements and the baseline will help you design the architecture for VMware Infrastructure deployment.

What’s the most common mistake you come across when virtualizing SQL Server?

Storage configuration is critical to any successful database deployment, especially in virtual environments where you may consolidate many different SQL Server VMs on a single ESX host. The storage must be sized adequately to handle IO requirements for all the VMs consolidated on the ESX host. Most SQL Server performance issues in virtual environments can be traced to improper storage configuration.

It is critical that you follow best practice guidelines specific to Microsoft SQL Server and other vendor products in your environment as well as VMware Infrastructure best practice guidelines. In general, best practices in physical environments also apply to deployments on VMware Infrastructure without any changes.