# Run RouterOS CHR in QEMU

RouterOS CHR labs often fail because firmware, VirtIO, acceleration, and port forwarding differ by architecture. This skill provides tested QEMU patterns for local labs and CI workflows.

## Install

```bash
npx skillstore add tikoci/routeros-qemu-chr
```

## Metadata

- Status: approved
- Slug: tikoci-routeros-qemu-chr
- Skillstore revision: r1
- Version status: missing
- Tree hash: a3e229e83740470faac61fcd7aba5dc1578d3261e8dca44a2feb15d428448f22
- Author: tikoci
- GitHub username: tikoci
- License: MIT
- Repository: https://github.com/tikoci/routeros-skills/tree/main/routeros-qemu-chr
- Ref: 36e07d5e13068e5be64447e8f20b427cf2cbd21a
- Supported tools: Claude, Codex, Claude Code
- Audit status: complete
- Agent install advisory: confirmation\_required
- Manual install advisory: allowed
- Artifact signature: available
- Audit attestation: unavailable
- Human verification: not\_verified
- Risk factors: network, external\_commands, filesystem
- Quality score: 38
- Quality tier: warning
- Public page: https://skillstore.pages.dev/skills/tikoci-routeros-qemu-chr
- Manifest: https://skillstore.pages.dev/api/skills/tikoci-routeros-qemu-chr/manifest

## Capabilities

- Selects SeaBIOS or UEFI boot paths for CHR images.
- Explains VirtIO disk and network choices for x86\_64 and aarch64.
- Provides QEMU launch patterns for shell, Bun, and CI usage.
- Maps localhost port forwards for WebFig, REST, SSH, API, and WinBox.
- Documents CHR licensing behavior, trials, and common boot failures.

## Use Cases

- Build a Disposable RouterOS Lab: Create a local CHR VM for API testing, packet debugging, or training without hardware.
- Add RouterOS Integration Tests: Run CHR in GitHub Actions to validate REST, packages, and generated schemas.
- Diagnose CHR Boot Problems: Compare firmware, CPU, acceleration, and VirtIO choices when a VM stalls or times out.

## Prompt Templates

### Plan a CHR Lab

```
Plan a RouterOS CHR QEMU lab on my host. Ask for my host OS and CPU architecture if needed, then recommend the image, boot method, acceleration, RAM, disk, and port forwards.
```

### Debug a Boot Failure

```
Diagnose this CHR boot failure: [symptoms]. Compare firmware, machine type, disk interface, CPU model, and VirtIO transport. Give a prioritized fix list.
```

### Create a CI Workflow

```
Design a GitHub Actions workflow for a selected RouterOS CHR version. Include image download, disk conversion, QEMU startup, REST readiness checks, optional package upload, reboot handling, and safe cleanup.
```

### Design a Multi-Arch Matrix

```
Build a multi-architecture CHR test strategy for x86_64 and aarch64 hosts. Include acceleration fallback rules, unsupported combinations, boot timing expectations, and skip logic.
```

## Limitations

- Does not configure RouterOS services after the VM boots.
- Requires QEMU, CHR images, and valid local permissions.
- Some examples need sudo or KVM access on the host.
- Hardware acceleration depends on host OS and guest architecture.

## Best Practices

- Bind forwarded services to localhost unless remote access is required.
- Use per-instance temp paths for QEMU sockets, logs, and firmware variables.
- Confirm CHR license limits before testing throughput or package downloads.

## Anti Patterns

- Do not use aarch64 if=virtio shorthand for RouterOS disks.
- Do not assume KVM or HVF works across host and guest architectures.
- Do not reuse empty admin passwords outside disposable local CHR instances.

## Security Audit

- Audited at: 2026-07-07T07:29:05.039\+00:00
- Summary: No prompt injection, hidden exfiltration, or malicious intent was found. The skill is legitimate RouterOS CHR and QEMU guidance, but it includes privileged host changes, external downloads, VM process launch, local service exposure, and predictable temp paths. These risks should be documented and gated by user confirmation before execution.

## Stats

- Views: 112
- Downloads: 10
- Favorites: 0
- Popularity score: 0