Most enterprise virtualization deployments make use of a robust shared storage infrastructure. A high-performance SAN allows multiple hypervisors to access virtual machine disks and is the foundation for amazing virtualization benefits such as VMware vMotion and HA. There are other benefits, too.
Virtualization management tasks such as cloning existing virtual machines or deploying new ones from templates often involve slinging around multi-gigabyte chunks of data. It’s preferable to move or copy data on the SAN instead of the LAN because it can be faster, but more importantly, doing so reduces impact to other services that rely on the LAN.
Use the SAN, ESX!
VMware ESX will transfer VMs and templates over a SAN connection whenever possible but, if necessary, it also does a fine job of moving those bits over a standard LAN. This goes for VMs as well as templates because with VMware vSphere, templates live on SAN datastores, too — shared among multiple ESX hosts — not on network file shares. If templates were stored on a file server, there would be no choice other than to copy those multi-gigabyte files over the LAN and potentially impact other production traffic.
Nice design choice, VMware! [Actually, if you go back to the early days of VirtualCenter 1.x, templates could also be stored directly on the VC server and deployed over the network. That option was removed as of VC 2.0.]
So far, so good. Let’s take a look at how Hyper-V stacks up.
Obfuscating the Inequalities
In the tradition of the recent storage hot add/remove claims, Microsoft has again gone the extra mile to give the appearance of feature parity.
Take a look at this excerpt from the System Center Virtual Machine Manager 2008 R2 What’s New page:
SAN migration into and out of clustered hosts: This allows virtual machines to migrate into and out of clusters using a SAN transfer, which saves the time required for copying the virtual machine file over the network.
And the features page is even more dramatic, proclaiming:
Virtual machine images can be large and difficult to move over the network. VMM auto-detects SAN infrastructure and enables copying of virtual machine images over fiber at fast speeds, thus leveraging SAN investments.
Sounds good, just like VMware — and at one-sixth the price! But there is a small problem: it is not true.
Hyper-V uses the BITS service to transfer VMs over the LAN in almost all cases. There is a scenario where SCVMM can orchestrate the disconnection and reconnection of a SAN LUN, “transferring” a VM to another host. Enabling the feature requires additional configuration and some software from your SAN vendor. Of course, it also means going back to one VM per LUN and foregoing the wonders of CSV. Any takers?
The SCVMM Library Server
SCVMM 2008 R2 provides VM template functionality for Hyper-V. Templates and ISO images are stored in a Library, which uses standard Windows file services. Obviously, that means no SAN copying for template deployments, either — kind of like VMware VirtualCenter 1.0.
“SAN LUN disconnect and reconnect” just doesn’t have the same ring to it as “SAN transfer” but I’m not sure that is sufficient justification for these misleading marketing claims. And to use the word “copying” is simply dishonest.
Don’t make the mistake of assuming Hyper-V is just like VMware ESX. Compare for yourself — seeing is believing.