This post originally from Pebkac.io and reproduced with permission.
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 Attachparameter with the
Set-AzureRmVMOSDiskcmdlet, 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
- 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) Ed – This is a release client remember!
- A lot of scenarios will require IP forwarding to be enabled on your CHR NIC. This can only be done with PowerShell, set the
EnableIPForwardingproperty to true on a NIC object and then update with
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 Amazon (AWS) on EC2 instances.