routeros-qemu-chr
在 QEMU 中執行 MikroTik RouterOS CHR
MikroTik RouterOS CHR 提供功能完整的虛擬路由器,適用於測試與開發,但設定過程需要處理 QEMU 選項、VirtIO 驅動程式及韌體配置。本技能提供完整指南,協助您使用加速功能執行 CHR、正確設定 VirtIO,並整合 REST API。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「routeros-qemu-chr」。 以 KVM 加速及連接埠 9180 REST API 啟動 CHR
預期結果:
QEMU 以硬體加速啟動。RouterOS 約 5 秒內完成啟動。來自 http://127.0.0.1:9180/ 的 HTTP 200 回應確認就緒狀態。REST API 可透過 http://127.0.0.1:9180/rest/ 以管理員憑證存取。
正在使用「routeros-qemu-chr」。 在 GitHub Actions Ubuntu 執行器上啟用 KVM
預期結果:
已在 /etc/udev/rules.d/99-kvm4all.rules 建立 udev 規則。KVM 裝置權限已更新為 0666。QEMU 成功開啟 /dev/kvm 進行硬體加速。啟動時間從約 30 秒縮短至約 5 秒。
正在使用「routeros-qemu-chr」。 為 RouterOS 服務配置連接埠轉發
預期結果:
主機連接埠對應:9180→80(REST API)、9122→22(SSH)、9728→8728(API)、9729→8729(API-SSL)、9291→8291(WinBox)。服務可透過主機的 localhost 連接埠存取。
安全審計
低風險Documentation and reference skill for running RouterOS CHR in QEMU. Static analysis flagged 343 patterns, but evaluation reveals these are false positives: shell backtick notation in markdown code examples (not execution), sudo in GitHub Actions CI (expected), MD5 references in kernel history docs (not actual usage), and legitimate acceleration detection commands. All network access targets MikroTik infrastructure for downloading CHR images. Risk level set to LOW due to external command patterns in documentation examples, but no actual malicious code present.
高風險問題 (4)
中風險問題 (3)
低風險問題 (2)
風險因素
品質評分
你能建構什麼
CI 中的自動化 RouterOS REST API 測試
將 RouterOS CHR 作為 CI 測試環境執行,以驗證 REST API 呼叫、產生 RAML 結構描述,以及測試 /app YAML 配置,無需手動設定路由器。
開發與學習環境
啟動免費授權的 CHR 執行個體,以探索 RouterOS 功能、測試防火牆規則、實驗橋接技術,並在無需實體設備的情況下學習網路概念。
多架構測試
使用 QEMU 搭配適當的韌體(x86 使用 SeaBIOS、ARM 使用 UEFI)及加速選項,在 x86_64 與 aarch64 兩種架構上測試 RouterOS 配置。
試試這些提示
協助我在 QEMU 中設定 RouterOS CHR。我需要下載最新穩定版映像檔,並以 KVM 加速及連接埠 9180 啟動 REST API。
撰寫一個 GitHub Actions 工作流程,下載 RouterOS CHR 並啟動(若有 KVM 則使用 KVM,否則回退至 TCG),等待啟動完成後執行 REST API 測試。
在 macOS Apple Silicon 上配置 QEMU 以啟動 RouterOS CHR aarch64。包含 UEFI pflash 設定及明確的 virtio-blk-pci 裝置配置。
RouterOS CHR 啟動失敗,畫面空白。磁碟映像檔在 aarch64 上使用 if=virtio。可能出了什麼問題?我該如何修正?
最佳實務
- 在 aarch64 上使用明確的 -device virtio-blk-pci,而非 if=virtio 簡寫,以避免導致無聲啟動失敗的 MMIO trap
- 在啟用 KVM 之前檢查 /dev/kvm 是否可寫入(而非僅檢查是否存在),並在 KVM 不可用時一律優雅地回退至 TCG
- 使用類似 tcp::9180-:80 的連接埠轉發模式,而非硬編碼 localhost IP,使配置更具可攜性與可重用性
避免
- 不要在 aarch64 架構上使用 if=virtio — 這會解析為 MMIO,而 RouterOS 不支援此模式,將導致無聲的啟動失敗
- 不要略過 KVM 權限檢查 — /dev/kvm 可能存在但無法讀取,且 QEMU 在權限錯誤時不會自動回退至 TCG
- 不要在並行 CI 建構中使用 git pull && git push — 請使用 retry-with-rebase 模式,避免因競爭條件導致推送被拒絕
常見問題
免費 CHR 授權的速度限制為何?
為什麼 QEMU Guest Agent 在 HVF 加速下無法運作?
我該如何選擇 SeaBIOS 或 UEFI 來啟動 CHR?
為什麼我的 aarch64 CHR 使用 if=virtio 時卡在啟動階段?
我可以同時執行多個 CHR 執行個體嗎?
我應該使用哪種加速方式?
開發者詳情
檔案結構