Hyper-V R3 Storage Migration

VMWare has had Storage VMotion available as an option for a while now and with SCVMM 2008 R2 Microsoft added Storage Quick Migration.  Storage Quick Migration worked well but there was downtime involved and it wasn’t an ideal solution.  In Hyper-V R3 Microsoft has added the ability to live migrate storage.

Select Move and the Move VM wizard will begin.  Select the type of move you want to perform.

Next select how you want to move the storage.  You can consolidate all the VM files to a single location, split the VM files to different locations or move only the VHD files.

In this sample we are moving all the files to a new location.  Specify the location and continue.

Depending on the size of the VM, the speed of the disk subsystem and host utilization this can take a few minutes.  But don’t be afraid as the VMs will continue to run as this process takes place.

Hyper-V R3 Storage Improvements

Windows Server 8 brings with it Hyper-V R3.  Within R3 there are quite a few new features and two specific to storage that I know a lot of people are looking forward too.  The first one I have been asked about hundreds of times and it is finally available in Windows 8 Hyper-V, virtual fibre channel HBAs.  You can now connect a Hyper-V R3 virtual machine to a fibre channel SAN.

The virtual FC HBA does have a few requirements:

• A server running Windows Server 8 with Hyper-V role installed.
• The server requires a Fibre Channel host bus adapters (HBAs) with a driver that supports Virtual Fibre Channel. 
• A virtual machine configured to use a virtual Fibre Channel adapter
• The VM OS must be Windows 2008, 2008 R2 or Windows Server 8
• Note you cannot boot from a virtual FC LUN

Windows Server 8 also brings a new disk type to Hyper-V R3, a VHDX.  Currently a VHD file is limited to 2040GB in size.  This is great for most workloads but in larger environments it can pose a challenge.  VHDX solves this by boosting the size of a VHDX file to a maximum 16TB (yes Terra).  Also of note is that Dynamically Expanding disks are now the recommended option.

In addition to this VHDX also changes the metadata structure in an effort to reduce data corruption.  VHDX also offers

• Larger block sizes for dynamic and differential disks.
• 4-KB logical sector virtual disk
• The ability to add custom metadata about the VHDX file
• Trim which allows the physical storage device to reclaim any unused space

It should be noted that only Windows Server 8 (host and VM) supports the VHDX file format at this time.

Live Migration NIC Binding

In a typical Hyper-V R2 cluster built on Microsoft’s best practices will have 6-8 NICs depending on the SAN type (iSCSI or FC) including:

• Management Network
• VM Network
• VM Network
• CSV Network
• Live Migration Network
• Cluster Heartbeat Network
• iSCSI MPIO (or FC adapter)
• iSCSI MPIO (or FC adapter)

One common issue that comes up in this scenario is failed Live Migrations, Quick Migrations will work but live ones will not.   When you attempt a Live Migration and it fails due to “A cluster network  is not available for this operation” it is caused by improper NIC Binding Order on the Hyper-V Hosts.  When this happens two events are created in the Microsoft\Windows\Hyper-V High Availability\Admin event log on the destination server.  Look for EventID 21126 and 21111

Your first thought will be to check that all the cluster resources are online and you will find they are.  When this happens you need to re-order the NIC binding for Live Migration to succeed.  To do this:

1. Open up the Network and Sharing Center
2. Click on Change Adapter Settings
3. Press the ALT key and click Advanced
4. Click Advanced Settings

Under the Adapters and Bindings tab move the Management Network virtual switch and the associated physical NIC to the top of the list and then place the rest of the NICs in any order.  Repeat this on all nodes in your Hyper-V Cluster.

Once you have completed this you will need to restart the Cluster Service on all nodes in the cluster.  You will need to do this via the Failover Cluster Manager and not Services.msc.  It should be noted that when you stop the cluster service on a node all running VMs will be quick migrated to other nodes.  Because of this it can take a while if there are a lot of running VMs in the cluster.