CHR: RouterOS as a VM, and Why Every MikroTik Shop Needs One

Thirty-four articles into this series, every topic has assumed RouterOS running on MikroTik metal. The finale removes the metal: CHR — Cloud Hosted Router — is RouterOS packaged as a plain x86-64 virtual machine image. Same CLI, same features, same WinBox; runs on Proxmox, ESXi, Hyper-V, KVM anywhere, and every public cloud that boots a disk image.

Why care, when you have hardware? Because a CHR costs nothing to run at 1 Mbps forever, spins up in a minute, and that combination quietly solves three chronic problems: nowhere to test changes before production, nowhere cheap to anchor BGP sessions and VPN meshes, and nowhere to practice the sharp-edged procedures (upgrades, netinstall-adjacent recovery, that VRF service binding) without risking a real network. The best MikroTik deployments I’ve seen all have CHRs humming in supporting roles.

Licensing: Honest and Cheap

CHR licensing is refreshingly simple — perpetual, per-instance, tiered by upload speed limit per interface:

• free — 1 Mbps per interface, all features, forever. The lab tier.
• p1 — 1 Gbps, ~$45 one-time.
• p10 — 10 Gbps, ~$95.
• p-unlimited — no limit, ~$250.

A fresh CHR runs a 60-day full-speed trial (/system license renew with a mikrotik.com account to activate a trial or purchased tier). The limit is egress shaping per interface, not a feature gate — the free tier runs BGP, VPNs, containers, everything, just at 1 Mbps out per interface. For config-plane roles (route reflector, lab twin, monitoring target) that’s genuinely enough; the moment real traffic transits, you’re in p1+ territory. No subscriptions, no per-seat nonsense — buy the tier, keep it forever.

The licensing binds to the VM’s system identity; radical virtual-hardware changes can unbind it, so treat a licensed CHR like a pet, not cattle — or keep licenses in your mikrotik.com account ready to re-assign.

CHR on Proxmox

My Proxmox series covers the hypervisor side in depth; the CHR-specific recipe:

# On the Proxmox node — grab the raw disk image
wget https://download.mikrotik.com/routeros/7.20/chr-7.20.img.zip && unzip chr-7.20.img.zip

qm create 9101 --name chr-lab --memory 512 --cores 2 \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --ostype l26
qm importdisk 9101 chr-7.20.img local-lvm
qm set 9101 --scsi0 local-lvm:vm-9101-disk-0 --boot order=scsi0
qm start 9101

The details that matter:

virtio everywhere. virtio NICs and virtio/SCSI disk are the supported, performant path — emulated e1000/IDE work but waste CPU. CHR ships virtio drivers in-image; no guest-agent gymnastics needed.

Resources are tiny. 512 MB RAM and 2 vCPU run a full lab fine; a serious VPN concentrator or RR wants 1–2 GB and cores to match. The disk is ~128 MB used — CHR is the lightest router VM you’ll ever run (keep the virtual disk small; it can’t be shrunk later).

First boot: secure it immediately. CHR images boot with admin and no password, and cloud deployments especially are scanned within minutes. The first-boot article’s checklist applies with extra urgency — password, /ip service restrictions, firewall — before the VM gets a public route.

On public cloud (AWS/Azure/GCP marketplace images or raw-image import), the same logic plus cloud specifics: single-NIC instances mean router-on-a-stick patterns, provider fabric filters spoofed source MACs/IPs (breaks VRRP-style tricks), and jumbo frames depend on the VPC. CHR as a cloud VPN gateway — WireGuard/IPsec hub terminating branch tunnels next to your cloud workloads — is the single most common production CHR role I encounter.

Role 1: The Lab Twin

The killer app, referenced throughout this series: a CHR (or several) that mirrors production before changes touch metal.

The workflow — take the nightly /export from the backup article, sanitize the hardware-specific parts (interface names differ: ether1 maps fine, sfp-sfpplus1 won’t exist; strip RouterBOARD-only sections), import onto a reset CHR:

/system reset-configuration no-defaults=yes skip-backup=yes
# upload prod-export.rsc, then:
/import file-name=prod-export.rsc

Now rehearse: the 7.x upgrade before the fleet gets it (upgrade article’s channel discipline), the BGP filter change with a peer simulated by a second CHR, the VRF service binding that could lock you out, the Ansible playbook’s --check and real apply (API article — CI against a CHR twin is exactly what that pipeline wants). Multi-CHR topologies on isolated Proxmox bridges recreate entire failure scenarios — I’ve rebuilt customer meltdowns in twenty minutes of qm clone to understand what actually happened.

The free tier’s 1 Mbps doesn’t matter here at all: labs validate configuration, not throughput.

Role 2: Route Reflector and Infrastructure Glue

The BGP article ended with iBGP full-mesh pain; the classic fix is a route reflector, and an RR is pure control plane — sessions and RIB, nearly zero transit traffic. A free-tier CHR with 2 GB RAM makes an excellent RR for a network of hardware routers:

/routing bgp instance add name=core as=65000 router-id=10.255.0.100
/routing bgp connection add name=rr-client-r1 instance=core \
  remote.address=10.255.0.1 local.role=ibgp-rr

(local.role=ibgp-rr on the RR’s connections marks this box as reflector toward that client, per the v7 role model from the BGP article). The same “config-plane, not data-plane” logic makes CHR ideal as: BGP looking glass / monitoring session anchor, User Manager RADIUS server (AAA article — better there than on the edge box), Dude/monitoring host, and WireGuard rendezvous point for spoke-to-spoke meshes where data rides spoke-to-spoke and only coordination touches the hub.

Performance Expectations

When CHR does push packets (p1+): expect respectable but not ASIC-class numbers — it’s software forwarding on virtio, so throughput scales with CPU clock, vCPU count and packet size. Multi-gigabit with large packets on modern cores is realistic; 64-byte-packet PPS workloads are where hardware routers and the L3HW article’s silicon keep their crown. Fasttrack works on CHR and matters just as much as on metal. Measure on your host with iperf3 through (not to) the CHR before making promises — hypervisor, NIC offloads and NUMA placement swing results 2–3×.

Verification

/system license print          # tier, deadline if trial
/system resource print         # confirm virtio nics, cpu, and that 128MB disk
/interface print                # ether1..N mapped as expected
# and the lab-twin acceptance test:
/export verbose file=twin-check   # diff against the prod export you imported

Closing Thoughts — and a Series Postscript

CHR completes the MikroTik picture: metal at the edges where packets need pushing, silicon in the core where the L3HW article put it, and virtual instances everywhere judgment needs rehearsing or control planes need anchoring — at a license cost between zero and one restaurant dinner.

And that closes the RouterOS 7 Guide: thirty-five articles from first boot to virtualized fleets. The through-line, if there is one: RouterOS gives you enterprise capability at hobbyist prices and assumes you will supply the discipline — default-drop firewalls, filtered BGP, tested backups, a management plane that scans as silence. Supply it, and this platform runs networks far above its price class. The VyOS and Proxmox series on this site tell the same story on their own platforms; the discipline transfers, which is exactly the point.