Windows Server R2 and SMB 3.0 accelerate the dynamic migration process

Moving a virtual machine from one Microsoft Hyper-V host to another is not shocking news, but did you do it? Microsoft Server 2012 and R2 can easily implement this migration process through the graphical Hyper-V Manager. If you want to speed up the migration process like I do-even automating the process--powershell can help you. You can also speed up the migration process by using SMB 3.0 file sharing.

There are many motivations for migrating virtual machines from one host to another, from load balancing to the decommissioning of old hosts. One of the challenges of the past is to have downtime during the long migration process, but it will never happen again. Dynamic migration ensures the smooth migration of the entire virtual machine and its storage.

Microsoft dynamic Migration has three ways:

No shared live migration-during this migration, you migrate virtual machines and their storage from one server to another.

Dynamic storage migration-the virtual machine settings remain on the current host, but the virtual machine's storage (virtual hard disk) is migrated to another location.

Dynamic migration-allows virtual machines to be migrated from one cluster node to another.

In this article, I will focus on no shared real time migration, which is one of the most time-consuming of the three types. Although you can perform such a migration using System Center Virtual Machine Manager, I will implement it through the Hyper-V cmdlet in server 2012.

Hyper-V Cmdlet implementation Dynamic Migration Lab preparation

I like to try out new ideas and techniques in a lab environment, and you should try them before you make a production. My lab environment consists of a domain controller and two Hyper-V hosts (named S1 and S2). A virtual machine (named Server1) has been run on the S1. My goal is to migrate the virtual machines without affecting the normal activity of the customer.

Simply put, no shared real time migration means that a virtual machine and its storage are migrated smoothly from one Hyper-V host to another Hyper-V host without downtime. This is a complex background process, but Microsoft has improved its approach to make it quite simple.

I do all the administration on the client computer using PowerShell remoting or RSAT. If you do not have a client in your lab environment that performs these tasks, you can use the Hyper-V host running the virtual machine.

Check VM Status

Quickly check the status of the virtual machine to make sure everything is OK. Check the status and storage location of the current Hyper-V host:

Get-vm-name Server1 | Format-table-property Name, Path, state

PS c:> get-vmharddiskdrive-vmname Server1 | Format-table-property Vmname, Path

Enabling and performing dynamic migration

Setting the basic settings for a migration is simple. You need to enable the migration feature and select a mobile network. In a production environment, it is preferable to have more than one network interface card and drive the migration process in a separate network. For lab testing, it is possible to use an existing network because no end user will be affected.

To initiate virtual machine migration, enter the following command on two Hyper-V servers or use PowerShell remoting on the client.

PS c:> enable-vmmigration

To add a virtual machine migration network on two Hyper-V hosts:

PS c:> add-vmmigrationnetwork 192.168.3.0/24

Migrating a virtual machine and its storage to another Hyper-V host is now just a command. I'm now going to move the virtual machine to the S2 host and put the store in "C:hyperv". To test, I ping the virtual machine to see the communication during the migration process. The order is as follows:

PS c:> move-vm–name server1-destinationhost s2-destinationstoragepath c:hyperv

Performing migrations using SMB 3.0 sharing

If you really want to speed up the move process, you can use the new SMB 3.0 file share, whether the virtual machine is in a separate or a cluster. We have described earlier that SMB 3.0 includes many features, but most importantly, it improves performance.

First set up SMB 3.0 shares and permissions at the target location of the virtual machine store. You need to create share permissions for administrators and two hosts, and assign these permissions to NTFS. I created them on both Hyper-V hosts so I could move the virtual machines back and forth.

PS c:> new-smbshare-name share1-path c:hyperv-fullaccess companyadministrator, CompanyS1, CompanyS2

PS c:> set-smbpathacl-sharename Share1

The process of performing a migration using SMB sharing is similar to the previous:

PS c:> move-vm–name server1-destinationhost s2-destinationstoragepath s2share1

Some permissions issues may be encountered, especially when executed from the client. You can resolve it by enabling a delegate constraint between the host and the client.

Using dynamic migration to move virtual machine settings is simple, and it can be easily automated if you understand the PowerShell cmdlet. Alternatively, consider using the new SMB 3.0 share to increase your migration speed.