The architecture team, which doesn't know the Microsoft environment, wants to migrate all Exchange infrastructures to a virtualization environment using VMware.
From my experience this is a great error. What do you think?
Requires Free Membership to View
When you register, my team of editors will also send you the latest expert resources covering all areas of server virtualization, such as platforms, architectures and strategies, server hardware, managing virtual environments, application issues and more.
Cathleen A. Gagne, Senior Editorial Director
Do you want the bad news or the good news first? We'll start with the bad news: your architecture team is partly correct. There is absolutely no reason why you should not be able to virtualize your four Exchange Front-End servers (or Client Access servers as they are called in Exchange 12 terminology). Even under stress, a virtual machine (VM) with a single CPU and 512MB-1GB of RAM should be plenty for an Outlook Web Access (OWA) server.
The good news is that you can tell your architecture team to hold off on any plans to virtualize the Exchange Back-End servers (Mailbox servers in Exchange 12). While technically this plan of action is not a problem, it falters under heavy performance loads. This is because of the extremely high amount of disk IO that Exchange causes. Virtual disk files simply cannot keep up with what Exchange can throw at them when Exchange is being hit hard. There is a loop-hole however -- raw device mappings (RDM). You can configure a VM to talk directly to a LUN on your SAN using RDMs. This does make it possible to virtualize Back-End Exchange servers with satisfactory performance. For more information about how to configure RDMs please see VMware's ESX 2.5.x documentation on accessing raw disksor VI3 documentation.
One last note. In ESX 2.5.x you can configure VMs to access physical disks directly or with RDMs, but VI3 only supports direct disk access through RDMs.
This was first published in August 2006