routeros-qemu-chr
在 QEMU 中运行 MikroTik RouterOS CHR
MikroTik RouterOS CHR 提供功能完整的虚拟路由器用于测试和开发,但设置过程需要处理 QEMU 选项、VirtIO 驱动和固件配置。本技能提供完整的指导,帮助用户使用加速功能运行 CHR、正确配置 VirtIO 并集成 REST API。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“routeros-qemu-chr”。 使用 KVM 加速启动 CHR 并在端口 9180 上启用 REST API
预期结果:
QEMU 以硬件加速启动。RouterOS 约 5 秒内完成启动。来自 http://127.0.0.1:9180/ 的 HTTP 200 响应确认就绪。REST API 可通过 http://127.0.0.1:9180/rest/ 使用 admin 凭据访问。
正在使用“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)
风险因素
质量评分
你能构建什么
自动化 RouterOS REST API CI 测试
将 RouterOS CHR 作为 CI 测试夹具运行,用于验证 REST API 调用、生成 RAML 模式以及测试 /app YAML 配置,无需手动设置路由器。
开发与学习环境
启动免费许可的 CHR 实例来探索 RouterOS 功能、测试防火墙规则、实验桥接配置,并学习网络知识,无需生产环境硬件。
多架构测试
使用 QEMU 在 x86_64 和 aarch64 两种架构上测试 RouterOS 配置,支持合适的固件(x86 使用 SeaBIOS,ARM 使用 UEFI)和加速选项。
试试这些提示
帮我设置 QEMU 中的 RouterOS CHR。我需要下载最新稳定版镜像并使用 KVM 加速启动,同时为 REST API 配置端口 9180。
编写一个 GitHub Actions 工作流,下载 RouterOS CHR,优先使用 KVM 启动(回退到 TCG),等待启动完成后运行 REST API 测试。
配置 QEMU 在 macOS Apple Silicon 上启动 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 实例吗?
我应该使用哪种加速方式?
开发者详情
文件结构