A lot has changed since I first wrote about CHR in Microsoft Azure. The latest RouterOS is 6.37 and our routers are working better than ever.

To update my earlier observations:

• CHR VMs will now gracefully Start and Stop without the risk of them ending up in an inconsistent state.
• Recent RouterOS upgrades we've performed have completed without issue.
• You still need to convert the Mikrotik supplied VHDX to VHD before uploading.
• Redeploying/resizing a CHR will result in the software ID changing.
• We get much better performance by using Standard VM SKUs as opposed to Basic

As promised, here are the basic steps to get one up and running. I'm time poor so I'm assuming you already know your way around the ARM portal and can connect to your Azure account with the PowerShell module.

Firstly, to save you the time of converting the Mikrotik VHDX, here's a VHD of 6.37.1 I prepared earlier.

You'll need a resource group, NIC, and storage account if you don't already have these. It's also a good idea to attach a public IP address to the NIC, and set up a security group allowing winbox access, if you don't have VPN access to your Azure environment, or a pre-existing jump host. Note that your new CHR will have a blank password, so be conscious of exposing it to the internet in this configuration.

Upload the VHD to your storage account using PowerShell, or the Azure Storage Explorer. This VHD will be attached to your CHR, so name it accordingly.

You can then modify the following PowerShell for VM creation:

$SubscriptionId = "12345678-1234-1234-a123-1a23b4cde56f"
$VMName = "vm-chr-test"
$ResourceGroupName = "rg-test-env"
$StorageAccountName = "sa-pebkac-test"
$LocationName = "US West"
$VMSize = "Standard F1"
$InterfaceName = "nic-chr-test"
$SourceImageUri = "https://$StorageAccountName.blob.core.windows.net/vhds/vm-chr-disk1.vhd"

$StorageAccount = Get-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageAccountName
$Interface = Get-AzureRmNetworkInterface -Name $InterfaceName -ResourceGroupName $ResourceGroupName
$VirtualMachine = New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize
$VirtualMachine = Add-AzureRmVMNetworkInterface -VM $VirtualMachine -Id $Interface.Id
$VirtualMachine = Set-AzureRmVMOSDisk -VM $VirtualMachine -Name $VMName -VhdUri $SourceImageUri -Caching "ReadWrite" -CreateOption "Attach" -Linux
New-AzureRmVM -ResourceGroupName $ResourceGroupName -Location $LocationName -VM $VirtualMachine -Verbose

After this, your VM will take a few minutes to create, and you'll be able to login and continue configuration.

Here's one of our busy VPN routers cruising along:

At the time of writing, Mikrotik's current CHR build is 6.35rc49.

While purported to work in a Hyper-V VM, there are no instructions I could find to get one up and running in Microsoft Azure (with ARM).

Knowing that it should be theoretically possible, given Azure utilises a hypervisor with the same origins as Hyper-V, I went down the rabbit hole.

The salient points are as follows:

• It works! We have stable CHRs in ARM VMs supporting production workloads.
• You must convert the Mikrotik supplied VHDX to a VHD before uploading to Azure's blob storage, as Azure doesn't support the newer format. (I installed the Hyper-V role on my Windows box, which includes a utility to do the conversion)
• You must use the -CreateOption Attach parameter with the Set-AzureRmVMOSDisk cmdlet, otherwise you'll end up with an Azure VM object stuck in a "Provisioning" or "Creating" state. You can just use the URL for the VHD you upload to blob storage for the -VhdUri parameter.
• The CHR VM doesn't respond to Stop or Restart requests from the Resource Manager Portal or PowerShell cmdlets. Attempting these actions can put the CHR VM into an inconsistent state.
• You can safely delete CHR VMs and the disks are left intact in blob storage and can be re-attached to a new VM. (Would need to re-license)
• You can restart the router from within Winbox / CLI as well as perform upgrades. (Back up your config first, sometimes the upgrades fail)
• A lot of scenarios will require IP forwarding to be enabled on your CHR NIC. This can only be done with PowerShell, set the EnableIPForwarding property to true on a NIC object and then update with Set-AzureRmNetworkInterface. Update: IP Forwarding can now be enabled from the Azure Portal in the NIC IP Properties.

If Mikrotik are not forthcoming with some proper Azure instructions, I'll try and expand on these notes with a full set of step by step instructions.

NB: If you're at the point where you're still choosing your cloud provider, CHR is presently much more mature in AWS on EC2 instances.