My two previous columns on Exchange Server virtualization generated a lot of thought-provoking feedback (see "Exchange Server Virtualization: Microsoft's Support," April 17, 2008, and "Exchange Server Virtualization: Hyper-V Possibilities," April 24, 2008). So I decided to address it in one more column (but probably with more to follow after Microsoft releases Hyper-V and clarifies its support position on virtualizing Exchange Server 2007). First, let me reiterate that Microsoft does not officially support non-Microsoft virtualization software for Exchange 2007 or Exchange Server 2003, so consider the rest of this column in light of how you'd get support if you choose to use such virtualization in those environments.
One frequent question people have about virtualization is what you can productively virtualize. Lab and demo environments are an obvious choice. Whenever I do presentations, I use a virtualized environment that includes a Windows Server 2003 domain controller (DC); an Exchange 2007 SP1 server with the Mailbox, Hub Transport, Client Access, and Unified Messaging (UM) server roles; a Microsoft Office Communications Server 2007 Standard Edition server; and a Microsoft Office Communicator Web Access server. This setup gives me a stable, reusable environment that I can quickly return to a known state.
If you're thinking about virtualizing production servers, you should consider which roles make good virtualization candidates. Technically, any Exchange 2007 role and any Exchange 2003 server (front end or back end) can be virtualized. As a practical matter, the best candidates for virtualization are the roles that don't store persistent data. For example, the Hub Transport and Client Access roles are good candidates in Exchange 2007 because—unlike the Mailbox server role—they don't store much unique data (except in the transport dumpster on Client Access servers) and can thus be quickly and easily replaced or moved to another physical host. I don't recommend virtualizing the UM server role because its audio quality depends directly on having adequate RAM and processing power. For very small environments, or those with only a few concurrent UM calls, you might be able to get away with virtualizing the UM role.
I'm not enthusiastic about virtualizing mailbox servers for several reasons. First, capacity planning and sizing are tricky. You won't find much good public data about mailbox server sizing in virtualized environments, especially for Exchange 2007. The proper allocation of physical and virtual CPUs and RAM is critical to getting good performance, so you should plan on doing extensive performance testing with Microsoft Exchange Load Simulator (LoadSim) or Exchange Load Generator (LoadGen) to validate the configuration.
There are many potential surprises lurking in this area. For example, Dell and VMware jointly published a paper, "Microsoft Exchange Server 2003 Performance on VMware ESX Server 3," that contains performance and sizing data from a variety of configurations, showing that two virtual machines (VMs), each with a single virtual CPU, provide better performance than a single VM with two virtual CPUs. However, if you take the same physical hardware that was running the VMs and run Exchange directly on it, you'll get significantly better performance, which means you must counterbalance the benefits of virtualization against the performance difference between physical and virtual hardware. If you're using VMs that connect to SAN storage, you might potentially have to deal with bottlenecks on the VMs themselves, on the SANs, or on the physical hosts that hold the VMs.
As a result of my last two columns, I have a unique opportunity: The Microsoft team that owns Exchange virtualization reached out to me to help connect them with people who are currently using virtualization in their production environment. They're eager to talk to real-world customers, so if you're interested in sharing your Exchange virtualization experiences, drop me a note at [email protected].