How to migrate Azure Managed Disk to different subscription and region – Part II

On the previous post I describe what need to do to move Azure Managed Disks between subscriptions and after that between regions (see link HERE). Although I didn’t explore the steps mention to move between regions.

Here are the step-by-steps of each stage, mention on the previous post, of how to move the Azure Managed Disk between Azure Regions:

1. Stop the virtual machine from migrating

1. Navigate to the Azure portal (https://portal.azure.com)
2. Click Virtual Machines on the left-hand menu, then select the virtual machine to be migrated
3. Click Stop

2. Enable the Export function to generate a single URL containing the VHD of the managed disk to migrate

1. On the selected virtual machine, click on Disks

2. Select the managed disk that you want to migrate

3. Click Export

4. Click on the Generate URL button

5. Copy this unique URL pointing to the target VHD file to the Notepad or any other clipboard.

3. Create a storage disk in the target region of the new subscription

1. So now, we need to create a storage account in the target region on the target subscription

2. Create a Container (folder) containing the VHD file to use and retrieve the connection information to that storage account:

2.1. On the Azure portal, select All Services.
2.2. Scroll to storage, and then select storage accounts
2.3. On the Storage Accounts window, click Add
2.4. Select the subscription in which you want to create the storage account, as well as the target resource group
2.5. Enter the name for your storage account
2.6. Select the location of your storage account (target region)
2.7. Leave all other fields to their default value
2.8. Click Verify + Create to review your storage account settings and create the account.

3. After the storage account is created, click Blob on the container

4. On the Name field, type VHDs

5. Click the OK button to confirm. This folder will contain the VHD file copied to the new region.

6. Click VHDs and then select Properties

7. Copy the URL to the Notepad (example: https://tempmanagedisk.blob.core.windows.net/vhds)

8. Click access keys and copy the Key1 key to the Notepad.

4. Use the AzCopy command from an Azure virtual machine (this option will decrease the copying time) to copy the data (VHD file) from the managed disk to a storage account created in the target region of the new subscription

AzCopy is a command-line utility designed to copy data from/to an Azure Blob, to a file or to a Table using simple commands with optimum performance. You can copy data between a file system and a storage account, or between storage accounts.

To start, you need to download and then install the latest version of the AzCopy utility from the following link aka.ms/downloadazcopy on a Windows virtual machine hosted in Azure. This was the way that I found to speed up the process of transferring the data between managed disks.

So, let start with the steps to copy the data:

1. Run a command prompt from the Azure virtual machine

2. Select the C:\Program Files (x86) \microsoft SDKs\Azure\AzCopy Directory (the utility does not modify the path).

3. Type the command to copy the data from the source managed disk to the target storage account previously created in a target subscription:
        azcopy /source:”<URL_FROM_VHD>” /dest:”<URL_VHD_DESTINATION>” /destkey:”<KEY1>”

5. From the VHD in the storage account, create a managed disk

After the copy is completed, we need to create a managed disk from the VHD copied.

1. Click All services

2. Select disks and Add

3. Enter the name of the managed disk to be created from the VHD file copied to the Storage account

4. Select the target subscription, the target resource group, and especially the target region

5. From the source Type drop-down menu, select Storage Blob, and then click the Browse button

6. Select the target storage account

7. Select the VHDs container

8. Select the copied VHD file and then validate by clicking the Select button

9. Finally enter the size in GiB and then click the Create button.

6. From the previously managed disk created, recreate a virtual machine

Now that the managed disk is on a different region and subscription, the final step is to create a virtual machine from the managed disk.

1. On the Azure Portal, navigate to Disks

2. Click on the managed disk that was created

3. Create a virtual machine

4. Follow the steps to create the virtual machine.

With these 6 steps, we copied a managed disk from an Azure virtual machine from region A to region B of another subscription, and then recreated the virtual machine.

Finally, be aware that it is possible to enable migration of managed disks between 2 subscriptions from the Azure portal GUI, but this method does not allow you to change the region of the virtual machine (thus the managed disk) and is only valid if the source virtual machine is not backed up.

To enable this feature, run the following 2 commands from a PowerShell Azure window and the source subscription:

Register-AzureRmProviderFeature -FeatureName ManagedResourcesMove -ProviderNamespace Microsoft.Compute

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute

Cheers,Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

How to migrate Azure Managed Disk to different subscription and region – Part I

On a recent project, I was asked to help move some virtual machines from a MSDN Subscription to a CSP subscription. With this move, we use the opportunity to consolidate on a different region as well. This last aspect makes the move a little more complex that was described on the Move resources to new resource group or subscription documentation.

The migration of resources between different or within the same subscription is relatively simple in Azure but does not apply to all resources. And unfortunately, these VMs were configured with managed disks, supporting the operating system and the data of the virtual machines are not part of it, at least at the time I write these lines.

The following link lists the services that can be moved, as well as those that cannot, such as managed disks: Move resources to new resource group or subscription

From the link above, in a few PowerShell lines, it is possible to migrate a managed disk from a subscription A to a B subscription, although within the same region. The New-AzureRmDiskConfig command provides the -Location parameter, which must specify the same source and target membership region. Here is the code used:

###SETTING THE VARIABLES###
#1#SOURCE OF MANAGED DISKS##
#Provide the subscription Id of the subscription where managed disk exists
$SourceSubscriptionId='<SOURCE_SUBSCRIPTION_ID>’
#Provide the name of your resource group where managed disk exists
$SourceResourceGroupName='<SOURCE_RESOURCE_GROUP>’
#Provide the name of the managed disk
$ManagedDiskName='<NAME_MANAGED_DISK>’
#2#TARGET DESTINATION OF MANAGED DISKS##
#Provide the subscription Id of the subscription where managed disk will be copied to
#If managed disk is copied to the same subscription then you can skip this step
$TargetSubscriptionId='<TARGET_SUBSCRIPTION_ID>’
#Name of the resource group where snapshot will be copied to
$TargetResourceGroupName='<TARGET_RESOURCE_GROUP>’
###SCRIPT###
#Provide the credentials to the Azure Portal
Connect-AzureRmAccount
#Set the context to the subscription Id where Managed Disk exists
Select-AzureRmSubscription -SubscriptionId $SourceSubscriptionId
#Get the source managed disk
$ManagedDisk= Get-AzureRMDisk -ResourceGroupName $SourceResourceGroupName -DiskName $ManagedDiskName
#Set the context to the subscription Id where managed disk will be copied to
#If snapshot is copied to the same subscription then you can skip this step
Select-AzureRmSubscription -SubscriptionId $TargetSubscriptionId
$DiskConfig = New-AzureRmDiskConfig -SourceResourceId $ManagedDisk.Id -Location $ManagedDisk.Location -CreateOption Copy
#Create a new managed disk in the target subscription and resource group
New-AzureRmDisk -Disk $DiskConfig -DiskName “testpp06” -ResourceGroupName $TargetResourceGroupName

As you probably thinking, the initial goal is complete, although we need to move the VMs to a different region. In this case, we just achieved the first part, because the managed disk was copied from the subscription A to the subscription B, but not in another region.

After a few tests, this is the method that I use. I’m sure that you will find other methods, but I found this very simple for this case. In the future post, I might script these steps, for automation purposes.

  1. Stop the virtual machine to migrate
  2. Enable the Export function to generate a single URL containing the VHD of the managed disk to be migrated
  3. Create a storage disk in the target region of the new subscription
  4. Use the AzCopy command from an Azure virtual machine (this option will decrease the copying time) to copy the data (VHD file) from the managed disk to a storage account created in the target region of the new subscription
  5. From the VHD in the storage account, create a managed disk
  6. From the previously managed disk created, recreate the virtual machine

Cheers,Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Unresponsive Azure VM

Another day I was at one of my costumers, and a system engineer come to me asking me if I could help him troubleshoot an issue with an unresponsive Azure VM. I love this moments, specially when I can always learn new ways that users are using Azure.

OK, lets move to the issue. Here is the list of issues that he reports to me:

  • No RDP into VM
  • VM not “pingable” from the network (either on prem or on Azure)
  • Remote PowerShell not available

Usually when this kind of issues happen, I always recommend to redeploy (see picture below).

But what does the redeploy on an Azure VM does to fix the issue. Sometimes the VM running on the host/node on Azure, get “stuck” on a state that makes the VM seems inaccessible from the network, although from the monitoring the VM is still running. By redeploy the Azure VM, you are redeploying the VM on another host/node in the same Azure datacenter.

What this mean? Means that Azure will shutdown automatically your VM, move it to another host/node available with the capacity to run and then power it back. All of this process will retain the configuration, the resources associated and the disks.

How to redeploy an Azure VM

You have to option, either through the Azure Portal or through PowerShell

Azure Portal

  • On Azure Portal, navigate to the VM. Down on the left under Support + troubleshooting area, you will find the Redeploy.

  • When you select Redeploy, it will appear a page explaining what will happen. Then click Redeploy
  • After that you will see the status the VM changing to Updating. When the status change to Running the redeploy is finish and now you can access the VM.

PowerShell

If you want to use the Azure Cloud Shell or the PowerShell on your machine the command is the same.

Set-AzureRmVM -Redeploy -ResourceGroupName “<RESOURCE_GROUP>” -Name “<VM_Name>”

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Serial Console access on Azure Virtual Machine

Finally come the day that Microsoft was able to announce this feature. Accessing the serial console on an Azure VM is a huge step forward. But why is so important? It’s huge! Sometimes when our friend Mr Murphy comes and makes everything goes south, you are in a certain way limited on the diagnostic tools that you have, to troubleshoot the cause of that machine is not booting. Have access to the boot of the server (Linux or Windows) is crucial at this time. Serial Console access will end those day of redeploy a VM using the same disk, when this option is viable, off course. You can see the announcement here.

But let’s dive into the Accessing the Serial Console. On each VM that you have running on Azure, under the SUPPORT + TROUBLESHOOTING, you will find the Serial console (preview).

When you click on that, automatically start to connect to the Serial Console of that VM.

After a few seconds, finishes the connection. And show me this screen. But I can’t do anything.

If you scroll up, then some light at the end of the tunnel. OK, I need to enable the SAC (Special Administrative Console) on the server.

To access the Serial Console on the server you need the enable it. To enable, just follow the steps below:

  1. Connect to your VM through RDP (in this case a Windows VM)
  2. Open the cmd with elevated (administrative privileges)
  3. From the cmd prompt run the following commands
    bcdedit /ems {current} on
    bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
  4. Reboot the VM

And then, you have access to the serial console of your server.

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Azure VNet-to-VNet VPN configuration – Part 3

In this blog post series, I will cover what you need to configure to create a VNet-to-VNet VPN between to Azure regions on the same subscription. Although is about the same configuration if you want to configure two different VNets on different subscriptions. You can see the part 1 post here and the part 2 here.

So, at this moment I have both networks setup with their gateways configured. Although I need to connect them to each other. For this I only have to choose one of them to setup the connection. Because I’m on the same subscription, this is one of the difference. If I want to connect different VNets on different subscription, I have to setup the connection on both sides. What they need to have in common is the Shared Key.

It’s exactly the same when setup a Site-to-Site VPN. One of the requirements after setup the networks, is connecting them with the Shared Key

How to connect two VNet gateways using Azure Portal

After this running successful, we need to connect both networks. To be able to do it just follow the steps bellow:

  1. On the VNet created, navigate to Connections (in this case I used the network that I configured with PowerShell – SW-EUS2-WUS2-VPN)
  2. Click Add
  3. When the Add connection blade open, you need to configure all the requirement fields:
    1. Name – This is where you insert the name of the VPN connection.
    2. Connection type – This is where you define which of connection want to use. VNet-to-VNet is used between two networks on Azure, Site-to-Site is used between a Azure network and on premise network. ExpressRoute is used between an Azure network and an existing circuit.
    3. First virtual network gateway – This is the network that you are configuring from.
    4. Second virtual network gateway – This where you want to connect. In this case, is the other region.
    5. Shared key – This is the key that is shared on both side to stablish the connection. This key only accepts number and/or letters.
  4. Then click OK
  5. After the connection it’s created, it will connect automatically.

 

 

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga