During my travels in my in-depth work with Microsoft Azure and dealings with the fabulous rhipe partners, I have seen a much needed gap in the Azure market and developed a tool completely based on PowerShell over 700 lines long to help Azure customers move / migrate virtual machines effortlessly, seamlessly and painlessly from Azure’s old ASM based Azure Service Management environment to Azure’s new ARM based Azure Resource Manager environment. The tool takes into account every possible combination in which you can have an ASM based virtual machine setup. In case you don’t know, ASM is the classic (IaaS v1) that uses cloud services and ARM is (IaaS v2) that doesn’t use cloud services.

Before today, there hasn’t really been a tool to fully automate the process of migrating existing virtual machine workloads from ASM > ARM. It has been a totally manual task up until now and it’s not exactly that easy to do for the average person. It’s on Microsoft’s roadmap move away from ASM and the sooner you move away from it and onto ARM, the better you will be.

Benefits of ARM:

• Logically group application workloads into a Resource Group which comprises of SQL, Storage, Compute, Networks etc. Logically organise all of the resources in your subscription into groups
• Role Based Access Control – delegate access to entire resource groups to anybody
• Parallel deployment using scale sets
• Repeatable deployment
• Deployment options using JSON templates, PowerShell and the web portal
• Use declarative templates to define your deployment
• Apply tags to resources
• Clarify billing for your organisation by viewing the rolled-up costs for the entire group or for a group of resources sharing the same tag
• Much better security and granularity of network endpoint NAT rules

The Azure virtual machine migration tool can automatically migrate Azure virtual machines from one subscription on ASM to another completely different subscription on ARM. This helps in the event you might have taken out a CSP based subscription which only supports ARM or if you have enterprise licensing and need to move VM workloads from a Pay-As-You-Go subscription to a subscription which is part of an enterprise enrolment.

The tool:

The Azure VM migration tool takes into consideration every possible scenario and combination for the source ASM based virtual machine, e.g.

• If the VM sits behind a cloud service with other VMs also behind the same cloud service.
• Whether there’s an ASM based load balancer used, it brings across the same load balancer endpoint rules.
• Any endpoint NAT rules, the same inbound NAT rules are setup on ARM
• Multiple disks, other than the OS disk, if there are several data disks attached to the VM, even if they are striped in Windows, LUN id’s are kept. This is good in the event you had multiple disks attached to Windows as a stripe, the stripe remains in tact.
• Multiple NICs, there’s the primary NIC and there’s secondary NICs, more than one NIC is catered for
• The existing virtual network, along with any subnets
• The same DNS configuration on the virtual network including the primary and secondary DNS addresses
• Both premium storage and standard storage is catered for
• Instance level public IP addresses and reserved IP addresses

When the Azure VM migration tool is run it asks for two sets of credentials, source Azure credentials and target Azure credentials while allowing to also choose a source and target Azure subscription. It then displays a list of all ASM based virtual machines. A single VM is picked to be migrated and the cloud service containing virtual machine is checked, then if there are more than one, all VMs behind the same cloud service are migrated across at the same time. The cloud service is a logical grouping of one or many virtual machines that each share a public IP address known as a VIP, generally for the purposes of high availability.

It’s a good idea to keep all virtual machines attached to the same virtual network grouped together by migrating these to the same Azure Resource Group. Further more, if you follow a rough ASM to ARM VM relationship of one virtual network to one Azure Resource Group, the tool will ensure there will be the same virtual network configured in the same Resource Group. If you had multiple virtual machines and cloud services attached to the same ASM virtual network, a replica ARM based virtual network will be created as you move the first virtual machine member of a virtual network, then subsequent virtual machines will naturally be attached to the same virtual network as they are moved across.

There is no perfect match of an ASM virtual machine configuration Vs am ARM virtual machine configuration. When virtual machines are migrated from ASM to ARM using the tool, the ARM based load balancer is used by default at all time except for the ‘basic’ family of virtual machines which don’t support the load balancer. The load balancer is used for non-basic virtual machines even if there is a single machine or many virtual machines, as the ARM based load balancer is the closest match to an ASM based cloud service.

In the case of the basic family of virtual machines, an NSG is created along with the same endpoint NAT rules and a dynamically assigned PIP.

If there is more than one virtual machine behind a cloud service which is set to the basic family, then all virtual machines behind this cloud service are migrated together but without a load balancer by using a NSG instead to keep the existing endpoint NAT rules in place.

The Azure DNS name of the source cloud service will change as ARM uses different Azure DNS names then that of ASM. You will be assigned a new region specific DNS name instead. If you have services running accessible from outside, ensure you have a low TTL in preparation to update your external DNS CNAME records.

In the case of moving a domain controller, you are given the option of keeping the same local IP address on the virtual machine which will be set as a statically assigned DHCP address. Please note, if your source VM has multiple NICs, this option effects all NICs. The default option is not to keep the same local IP address, as everything in Azure is DHCP based and no static IP addresses as best practice.

The tool will copy virtual machine disks (OS & Data) from an ASM based storage account to an ARM based storage account. The virtual machine being migrated needs to be shut down to ensure a successful copy. Prior to shutting down the virtual machine, you are given the option to specify whether you would like to start back up the source virtual machine upon completion of copying the disks. If your choose no, when the virtual machine is shut down, it is de-provisioned and loses it’s VIP. If you choose yes, the the virtual machine is not de-provisioned when it is shut down and the VIP is kept when it is started up again. Please note that the tool automatically includes all virtual machines behind the same cloud service to be migrated together, so this effects the entire cloud service of virtual machines.

Storage accounts are created automatically on the target Azure Resource group as per best practice, using a separate storage account for OS disks and a separate storage account for data disks.

It takes roughly 10 minutes to copy each disk (OS or data disk) in the same Azure datacenter. The more disks, the more time it will take. But the good news is that it doesn’t seem to copy white space in the VHD disk.

If the source virtual machine uses totally premium storage for both OS and data disks then a separate ‘standard’ ARM based storage account is created automatically for the purposes of boot diagnostics usage.

Instance level public IP address are setup in ARM for the non-basic family of virtual machines in which use the new load balancer. The Instance level public IP address is assigned directly to the NIC which is attached to the virtual machine. In the case of the basic family of virtual machines, as these don’t use a load balancer, they have a NIC already with a public IP address assigned and as a result don’t have an Instance level public IP address, as only one public IP address can be assigned to a NIC at any one time – so they sort of have an Instance level public IP address already setup.

Upon completion of running the tool, the tool displays an overview of information for the migrated virtual machine including new DNS names, IP addresses and connection information for remote desktop.

If you are interested in using the tool, the tool is available through http://rhipe.com, I developed it while I was working there, so it’s their IP. Please contact the freindly rhipe team: enquiries@rhipesolutions.com, or you can follow me on Twitter: @marckean for more great Azure stuff!

Video Demo: