With the introduction of Hyper-V 3.0 and vSphere 5.1 both major virtualization vendors have introduced SAN free live migration solutions. To give a quick recap live migration is the ability to migrate a virtual machine from one physical host to another physical host without interruption of service for the target virtual machine. In the past, the one consistent requirement in both Hyper-V and vSphere has been that you had to have a SAN in common between the two hosts. The primary challenge for the SAN requirement was the cost and complexity associated with operating a SAN. This put one of the most beneficial features of hypervisors out of the reach for small organizations. Another challenge is the inability to migrate virtual machines between hosts homed to different SANs. It’s been a common challenge to perform maintenance on a SAN or change the class of storage associated with a VM but not have anywhere to move it without downtime.
Microsoft and VMware approach SAN free migration in two different ways. Microsoft leverages the improvements in their SMB protocol in Windows Server 2012. SMB has had a reputation for being an inefficient protocol for years. NFS and iSCSI have been the default method for providing storage over a TCP/IP network. Microsoft now claims that SMB is efficient enough to compete with NFS and iSCSI in offering the backend storage needed to host VM’s. It’s this new performance boost that Microsoft leverages as the foundation of SANs free live migration. Instead of storing the VM on a traditional NFS volume or iSCSI LUN, Hyper-V can now store VHD files on a standard Windows Files Share. The file server doesn’t have to run Hyper-V itself. It just needs to be a Windows Server 2012 OS and could be virtual itself. In essence you still have the shared storage requirement but get a new shared storage option. You still however get many of the performance advantages during live migration as you do in NFS, iSCSI and Fibre Channel based solutions.
VMware takes a different approach by combining standard vMotion with Storage vMotion. Instead of migrating just the VM’s memory and CPU state from one host to another, the storage is migrated as well. So, you can have two hosts with local storage perform migrations between the two hosts. This offers a greater level of flexibility over the Hyper-V approach. The obvious disadvantage would be performance as large VM’s would take a long time to replicate even over a fast network. There also could be performance related issues for both Storage and Network I/O. However, this is a great new feature for allowing the migration of VM’s from one SAN to another SAN. It doesn’t offer much in the form of protection as shared storage is still the way to go if you are looking to protect workloads.
Both solutions are great new features of the platforms. Microsoft uses a little marketing magic to technically achieve “SANs” free live migration but it is still a very useful feature while VMware makes a natural evolution to live storage migration between two hosts with no shared storage. Do you see a use case for SANs free migration in your environment?