Docs / Guests

文档 / 系统

Guest notes

系统说明

What each guest supports, and the specific things it does differently. Most of these you never have to think about -- AnyVM already applies them -- but when something behaves oddly, the reason is usually on this page.

每个系统支持什么，以及它有哪些跟别人不一样的地方。这些绝大多数你都不用操心， AnyVM 已经替你处理了 —— 但真出现什么奇怪现象时，原因通常就在这一页上。

Release lists live in the builders. Each builder repository publishes the authoritative list of releases it currently ships, and updates it as upstream cuts new ones. This page covers behaviour, not versions. 版本列表在 builder 那边。每个 builder 仓库都会公布它当前提供的版本清单，上游发新版就跟着更新。这一页讲的是行为，不是版本号。

FreeBSD

x86_64 · aarch64 · riscv64 · powerpc64 freebsd-builder

The broadest architecture coverage of any guest here, and the one to reach for first if you just want a BSD to test on. UEFI boot is enabled implicitly, so --uefi is unnecessary.

这里架构覆盖最广的一个系统。只是想随便找个 BSD 测东西的话，先用它。UEFI 启动是隐式打开的，不用再写 --uefi。

Desktop images ship for XFCE, GNOME and KDE: --release 15.1-xfce, 15.1-gnome, 15.1-kde6.

桌面镜像有 XFCE、GNOME 和 KDE 三种：--release 15.1-xfce、 15.1-gnome、15.1-kde6。

riscv64 is the one architecture upstream ships no packages for at all: pkg.FreeBSD.org has an empty FreeBSD:15:riscv64 repository. The 15.x riscv64 images therefore come with anyvm-org/freebsd-pkg-repo configured instead -- the ports tree cross-built with poudriere and published as signed release assets -- so pkg install works and --sync rsync and --sync sshfs are available there. 13.x and 14.x riscv64 have no such repository and stay on nfs, scp and tar.

riscv64 是唯一上游完全没有官方软件包的架构：pkg.FreeBSD.org 上 FreeBSD:15:riscv64 仓库是空的。所以 15.x 的 riscv64 镜像改用 anyvm-org/freebsd-pkg-repo：用 poudriere 交叉编译的 ports 树，签名后作为 release 资产发布。因此它们能直接 pkg install，也支持 --sync rsync 和 --sync sshfs。13.x 和 14.x 的 riscv64 没有这个仓库，仍然只有 nfs、scp 和 tar。

HardenedBSD

x86_64 hardenedbsd-builder

A security-hardened FreeBSD derivative (PaX ASLR and exploit mitigations baked into base). Upstream builds amd64 only and publishes no numbered releases: --release 15 follows the rolling 15-STABLE branch, and each builder release freezes one of its LATEST builds -- the same model NextBSD uses.

以安全加固为目标的 FreeBSD 衍生系统（PaX ASLR 等利用缓解直接进了 base）。上游只构建 amd64，也不发布带版本号的正式版：--release 15 跟随滚动的 15-STABLE 分支，每个 builder release 冻结其中一个 LATEST 构建 —— 和 NextBSD 是同一种模式。

All five sync backends work. rsync and fusefs-sshfs are pre-installed, and nfs, scp and tar need nothing extra -- behaviour matches FreeBSD throughout. 五种同步后端都可用。rsync 和 fusefs-sshfs 已预装，nfs、scp、tar 则不需要装任何东西 —— 行为和 FreeBSD 完全一致。
No release 14. Upstream still publishes 14-STABLE installers but has retired its binary package repository, so a 14 guest cannot even bootstrap pkg; only 15 ships. 没有 14 这个版本。上游虽然还在发 14-STABLE 安装镜像，但二进制软件包仓库已经下线，14 的客户机连 pkg 都无法引导，所以只提供 15。

OpenBSD

x86_64 · aarch64 · riscv64 · sparc64 openbsd-builder

Seven desktop environments are published -- 7.9-xfce, -gnome, -kde6, -mate, -lxqt, -lumina, -enlightenment -- more than any other guest.

一共发布了七种桌面环境 —— 7.9-xfce、-gnome、 -kde6、-mate、-lxqt、-lumina、 -enlightenment —— 比任何其他系统都多。

sparc64 needs patched firmware. The OpenBIOS that QEMU bundles crashes every OpenBSD 7.3-and-later sparc64 kernel on cold boot. AnyVM downloads a rebuilt OpenBIOS and passes it via -bios automatically; the builder compiles it from source and publishes it as a release asset. sparc64 is console-only, no graphics. sparc64 需要打过补丁的固件。QEMU 自带的 OpenBIOS 会让 7.3 及以后的每一个 OpenBSD sparc64 内核在冷启动时崩溃。AnyVM 会自动下载重新编译过的 OpenBIOS，通过 -bios 传进去；这个固件由 builder 从源码编译并作为 release 附件发布。sparc64 只有控制台，没有图形界面。
aarch64 boots slowly. The boot timeout defaults to 1200 seconds instead of the usual 600, because OpenBSD arm64 takes that long under emulation. An explicit --boot-timeout-sec always wins. aarch64 启动很慢。启动超时默认给到 1200 秒而不是通常的 600 秒，因为 OpenBSD arm64 在模拟下确实要这么久。你自己写的 --boot-timeout-sec 永远优先。

NetBSD

x86_64 · aarch64 · riscv64 · sparc64 netbsd-builder

sparc64 syncs with scp, not rsync. The QEMU sun4u machine boots only off the CMD646 PCI IDE controller, whose TCG emulation loses interrupts under sustained concurrent network and disk DMA. A live sshfs or nfs mount drives exactly that pattern and wedges the guest, and the base image ships no rsync. A one-shot scp avoids both. Override with --sync if you know what you are doing. sparc64 用 scp 同步，不用 rsync。 QEMU 的 sun4u 机器只能从 CMD646 这块 PCI IDE 控制器启动，而它的 TCG 模拟在网络和磁盘 DMA 持续并发时会丢中断。sshfs 或 nfs 的实时挂载正好制造这种压力，会把虚拟机卡死；而基础镜像里又没有 rsync。一次性的 scp 两个问题都避开了。你确实清楚自己在做什么的话，可以用 --sync 覆盖。
sparc64 is console-only here too.这里的 sparc64 同样只有控制台。
Fast boot: the 11.0-microvm release variant. Same install and userspace as 11.0, but anyvm boots NetBSD's official MICROVM kernel directly on QEMU's microvm machine type — no BIOS, no PCI, no ACPI, virtio over MMIO — cutting boot-to-ssh about 4x (7.4s vs 29.6s under KVM). Use --release 11.0-microvm. x86_64 and Linux hosts only for now; the console is serial. No nfs sync (the MICROVM kernel has no NFS client); rsync, scp, sshfs and tar all work. 快速启动：11.0-microvm 发行变体。 安装内容和用户态与 11.0 完全相同，但 anyvm 会在 QEMU 的 microvm 机型上直接引导 NetBSD 官方的 MICROVM 内核 —— 没有 BIOS、PCI 和 ACPI，virtio 走 MMIO —— 到 ssh 可用的启动时间缩短约 4 倍（KVM 下 7.4 秒 vs 29.6 秒）。用 --release 11.0-microvm 启用。目前仅支持 x86_64 和 Linux 宿主；控制台是串口。不支持 nfs 同步（MICROVM 内核没有 NFS 客户端）；rsync、 scp、sshfs、tar 都可用。

DragonFlyBSD

x86_64 dragonflybsd-builder

The guest most sensitive to the host PMU. Exposing hardware performance counters through -cpu host can trigger intermittent general-protection faults in wrmsr during early boot, which showed up as random boot failures across CI runners with different Intel generations. The PMU is therefore off by default for every guest; pass --enable-pmu only if you need perf-style profiling inside the VM.

对宿主 PMU 最敏感的一个系统。通过 -cpu host 把硬件性能计数器暴露进去，可能让早期启动阶段的 wrmsr 偶发触发一般保护错误 —— 表现出来就是在不同代 Intel 的 CI 机器上随机启动失败。所以 PMU 对所有系统默认关闭；只有你确实要在虚拟机里做 perf 那类性能分析时，才加 --enable-pmu。

MidnightBSD

x86_64 midnightbsd-builder

A FreeBSD derivative with the mport package system. Nothing special is needed to run it.

FreeBSD 的衍生版，用自己的 mport 包管理系统。跑它不需要任何特殊处理。

GhostBSD

x86_64 ghostbsd-builder

A desktop-first FreeBSD derivative -- MATE is the default image, with 26.1-xfce and 26.1-gershwin also published.

以桌面为先的 FreeBSD 衍生版 —— 默认镜像是 MATE，另外还发布了 26.1-xfce 和 26.1-gershwin。

Skips WHPX on Windows hosts. Its boot aborts under the Windows Hypervisor Platform with failed to decode instruction f 10, so AnyVM runs it under TCG there rather than letting it fail. Slower, but it boots. 在 Windows 宿主上跳过 WHPX。它在 Windows Hypervisor Platform 下启动会中止，报 failed to decode instruction f 10，所以 AnyVM 在那儿直接让它走 TCG，而不是眼看着它失败。慢一些，但能起来。

NextBSD

x86_64 · aarch64 nextbsd-builder

FreeBSD with Mach IPC and launchd as PID 1 -- there is no rc.d. Built from a rolling upstream tag, so the release you get is resolved at build time.

带 Mach IPC 的 FreeBSD，PID 1 是 launchd —— 没有 rc.d。它从上游的滚动标签构建，所以你拿到的是哪个版本，在构建时才定。

OPNsense

x86_64 opnsense-builder

A FreeBSD-derived firewall appliance, built from upstream's preinstalled nano image. You get root SSH into a fully configured appliance -- the console shows OPNsense's numbered menu, and the web GUI is on the guest's port 443 if you forward it. Release 26.7.

基于 FreeBSD 的防火墙设备系统，用上游预装好的 nano 镜像构建。你拿到的是一台配置完毕、可 root SSH 的设备 —— 控制台是 OPNsense 的数字菜单，转发 443 端口就能开它的 Web 管理界面。版本 26.7。

No sshfs. OPNsense's own package repository carries no fusefs-sshfs, so folder sync is rsync, scp, nfs or tar. 没有 sshfs。OPNsense 自己的软件仓库里没有 fusefs-sshfs，目录共享用 rsync、scp、 nfs 或 tar。
The root shell is csh. A command passed with -- cmd runs under csh, where Bourne-isms like 2>&1 are syntax errors -- wrap in sh -c '...' when in doubt. Durable configuration lives in /conf/config.xml, not in rc files. root 的 shell 是 csh。用 -- cmd 传进去的命令在 csh 下执行，2>&1 这类 Bourne 写法是语法错误 —— 拿不准就包一层 sh -c '...'。持久配置在 /conf/config.xml 里，不在 rc 文件里。

Solaris

x86_64 solaris-builder

Oracle Solaris 11. A heavy guest: under TCG it needs a long boot window, which AnyVM already allows for by raising the default timeout to 1800 seconds whenever no hardware acceleration is available.

Oracle Solaris 11。比较重的一个系统：在 TCG 下启动要等很久，AnyVM 已经考虑到了 —— 只要没有硬件加速可用，默认超时就自动提到 1800 秒。

OmniOS

x86_64 omnios-builder

An illumos distribution aimed at servers and storage. Stable LTS releases alongside the rolling bloody line, depending on what the builder currently publishes.

面向服务器和存储的 illumos 发行版。有稳定的 LTS 版本，也有滚动的 bloody 线，具体看 builder 当前发布了哪些。

OpenIndiana

x86_64 openindiana-builder

The community continuation of OpenSolaris, with a full package repository and a desktop available.

OpenSolaris 的社区续作，有完整的软件仓库，也有桌面可用。

Tribblix

x86_64 tribblix-builder

A lightweight illumos distribution with its own zap package manager and a retro window manager.

轻量级 illumos 发行版，有自己的 zap 包管理器和一个复古风窗口管理器。

Historical note. Images before v2.0.3 froze a CPU-vendor-specific libc_hwcap variant into /lib/libc.so.1 at build time, which crash-looped under KVM on the other vendor's CPU. Current images ship the capability-neutral libc that boots on both Intel and AMD and re-optimises per CPU on first boot. Only reach for --tcg if you must run a pre-2.0.3 image on a mismatched host. 历史遗留问题。v2.0.3 之前的镜像在构建时把某一家 CPU 专用的 libc_hwcap 变体固化进了 /lib/libc.so.1，换到另一家的 CPU 上用 KVM 跑就会崩溃重启循环。现在的镜像装的是不挑 CPU 特性的通用 libc，Intel 和 AMD 都能起来，首次启动时再按当前 CPU 重新优化。只有当你非得在不匹配的宿主上跑 2.0.3 之前的镜像时，才需要动用 --tcg。

Ubuntu

x86_64 · aarch64 · riscv64 · ppc64le · s390x ubuntu-builder

The widest spread of emulated architectures, and consequently the guest with the most QEMU-version sensitivity. Every case below is handled for you on a Linux x86_64 host: when the system QEMU is too old, AnyVM downloads and uses a pinned QEMU 10.2.3 for exactly that combination.

模拟架构铺得最开的一个系统，因此也是对 QEMU 版本最挑剔的一个。下面这些情况在 Linux x86_64 宿主上都替你处理好了：系统自带的 QEMU 太旧时，AnyVM 会下载一个固定的 QEMU 10.2.3，只用在那一种组合上。

Architecture架构	What it needs, and why需要什么，为什么
aarch64	Defaults to `-cpu cortex-a72`. Under `-cpu max` the distro QEMU 8.2 aborts with a `regime_is_user` assertion when the 26.04 kernel uses VHE. 默认用 `-cpu cortex-a72`。用 `-cpu max` 时，26.04 的内核一旦启用 VHE，发行版自带的 QEMU 8.2 就会在 `regime_is_user` 断言处中止。
riscv64	26.04 requires QEMU 9.1 or newer and selects `-cpu rva23s64` automatically -- the RVA23 userspace baseline and the 7.0 kernel do not run on QEMU 8.2. 22.04 and 24.04 are fine on stock QEMU. 26.04 需要 QEMU 9.1 或更新，并会自动选 `-cpu rva23s64` —— RVA23 的用户态基线和 7.0 内核在 QEMU 8.2 上跑不起来。22.04 和 24.04 用系统自带的 QEMU 就行。
s390x	Wants QEMU 10 or newer; the distro 8.2 intermittently freezes guest systemd at startup, a TCG-only bug. On a real IBM Z host with `/dev/kvm`, KVM is used automatically and stock QEMU is fine. 需要 QEMU 10 或更新；发行版的 8.2 会偶发地把虚拟机里的 systemd 冻在启动阶段，这是个只在 TCG 下出现的 bug。在真正的 IBM Z 机器上（有 `/dev/kvm`）会自动走 KVM，系统自带的 QEMU 就够。
ppc64le	22.04 requires QEMU 10 or newer: under the distro 8.2 pseries TCG the jammy python3.10 segfaults, so every cloud-init and apt run crashes. 24.04 and 26.04 work on stock QEMU. 22.04 需要 QEMU 10 或更新：在发行版 8.2 的 pseries TCG 下， jammy 的 python3.10 会段错误，于是每次 cloud-init 和 apt 都崩。24.04 和 26.04 用自带的 QEMU 没问题。

Debian

x86_64 · aarch64 · riscv64 · ppc64le debian-builder

Built from Debian's official cloud images (the full-driver generic variant). Two releases ship -- 12 (bookworm) and 13 (trixie) -- on four architectures each, except riscv64, which exists for 13 only: it became a Debian release architecture in trixie. rsync, sshfs and the NFS client are pre-installed, so all five sync backends work on every arch.

用 Debian 官方云镜像构建（全驱动的 generic 变体）。提供两个版本 —— 12（bookworm）和 13（trixie），各四种架构；只有 riscv64 例外，仅 13 提供：它从 trixie 开始才成为 Debian 的正式发布架构。 rsync、sshfs 和 NFS 客户端已预装，五种同步后端在每个架构上都可用。

The arch is spelled ppc64le here. Debian itself calls it ppc64el; AnyVM uses the common spelling, same as Ubuntu. 架构名在这里写作 ppc64le。 Debian 自己叫它 ppc64el；AnyVM 用通用拼法，和 Ubuntu 一致。

OpenEuler

x86_64 · aarch64 · riscv64 · loongarch64 openeuler-builder

The only guest with a loongarch64 image. That architecture needs the EDK2 LoongArch firmware (edk2-loongarch64-code.fd), which QEMU only started bundling in 9.2 -- so on a Linux x86_64 host with an older system QEMU, AnyVM fetches a pinned QEMU 10.2.3 for it. Always TCG, so expect it to be slow.

唯一有 loongarch64 镜像的系统。这个架构需要 EDK2 的 LoongArch 固件（edk2-loongarch64-code.fd），而 QEMU 从 9.2 才开始自带 —— 所以在系统 QEMU 较旧的 Linux x86_64 宿主上，AnyVM 会为它取一个固定的 QEMU 10.2.3。它始终走 TCG，所以慢是正常的。

Release names carry their own capitalisation (24.03-LTS-SP4), but --release matches case-insensitively, so 24.03-lts-sp4 finds it.

它的版本名自带大小写（24.03-LTS-SP4），不过 --release 匹配时不区分大小写，写 24.03-lts-sp4 也能找到。

Rocky

x86_64 · aarch64 · ppc64le · s390x rocky-builder

The RHEL-compatible enterprise distribution, built from Rocky's official GenericCloud images. Releases 9 and 10; 10 covers all four architectures, 9 ships x86_64, aarch64 and s390x (upstream publishes no 9 ppc64le cloud image).

与 RHEL 兼容的企业发行版，用 Rocky 官方 GenericCloud 镜像构建。提供 9 和 10 两个版本；10 四种架构齐全， 9 提供 x86_64、aarch64 和 s390x（上游没有 9 的 ppc64le 云镜像）。

No sshfs. fuse-sshfs is not in Rocky's BaseOS or AppStream -- it lives in EPEL, and a base image should not carry a third-party repository. Folder sync is rsync, scp, nfs or tar; all three of those packages are in BaseOS. 没有 sshfs。fuse-sshfs 不在 Rocky 的 BaseOS 或 AppStream 里 —— 它在 EPEL，而基础镜像不该自带第三方仓库。目录共享用 rsync、scp、nfs 或 tar，这些包都在 BaseOS 里。
SELinux runs enforcing. The image is relabelled at build time so the injected SSH key carries the right context. If you add files to /root/.ssh yourself from outside the guest, relabel them or sshd will silently ignore them. SELinux 是 enforcing 模式。镜像在构建时做过 relabel，注入的 SSH key 带着正确的上下文。如果你从客户机外面自己往 /root/.ssh 加文件，记得重新打标签，否则 sshd 会默默忽略它们。

AlmaLinux

x86_64 · aarch64 · ppc64le · s390x almalinux-builder

The other RHEL-compatible enterprise distribution, built from AlmaLinux's official GenericCloud images. Same shape as Rocky: releases 9 and 10, with 10 covering all four architectures and 9 covering x86_64, aarch64 and s390x.

另一个与 RHEL 兼容的企业发行版，用 AlmaLinux 官方 GenericCloud 镜像构建。形状和 Rocky 一样：提供 9 和 10，10 四种架构齐全，9 提供 x86_64、aarch64 和 s390x。

No sshfs, for the same reason as Rocky: fuse-sshfs is EPEL-only. Folder sync is rsync, scp, nfs or tar. SELinux runs enforcing, and the image is relabelled at build time. 没有 sshfs，原因和 Rocky 一样： fuse-sshfs 只在 EPEL 里。目录共享用 rsync、 scp、nfs 或 tar。SELinux 是 enforcing 模式，镜像在构建时做过 relabel。
No 9 ppc64le, even though upstream publishes one. Under emulation that guest boots and then loses cloud-init to a repeatable crash inside Python 3.9, so it never gets a network. 9 on aarch64 and s390x runs the same Python and is fine, and 10 on ppc64le is fine -- it is that one combination. 没有 9 的 ppc64le，尽管上游有这个镜像。在模拟环境下它能启动，但 cloud-init 会在 Python 3.9 里稳定崩溃，导致网络起不来。9 的 aarch64 和 s390x 用同一个 Python 却没问题，10 的 ppc64le 也没问题 —— 只有这一个组合不行。

Alpine

x86_64 · aarch64 · riscv64 alpine-builder

The small musl/BusyBox Linux. x86_64 and aarch64 are built from Alpine's official cloud images; Alpine publishes none for riscv64, so that one is installed from the standard Alpine installer ISO and exists for 3.24 only. Two release lines ship (3.23, 3.24). rsync, sshfs and the NFS client are pre-installed, so all five sync backends work out of the box on every architecture.

小巧的 musl/BusyBox Linux。x86_64 和 aarch64 用 Alpine 官方云镜像构建； riscv64 上游没有云镜像，改用标准安装 ISO 安装，仅 3.24 提供。提供两个版本线（3.23、3.24）。rsync、sshfs 和 NFS 客户端已预装，每种架构上五种同步后端都开箱即用。

Releases name the line, not the patch. --release 3.24 maps to whichever 3.24.x cloud image the builder release pinned -- patch bumps update the image within the same release name, the way Ubuntu's 24.04 behaves. 版本号是版本线，不带补丁位。 --release 3.24 对应 builder release 当时固定的那个 3.24.x 云镜像 —— 补丁更新在同一个版本名内滚动，和 Ubuntu 的 24.04 是一样的方式。

BlissOS

x86_64 · Android x86 blissos-builder

Android on x86, with root SSH and the Android desktop on the VNC console -- so this is one to open in the browser rather than drive from a shell. Releases map to Android versions: 16 (Android 13), 15 (12L), 14 (11).

跑在 x86 上的 Android，带 root 权限的 SSH，Android 桌面在 VNC 控制台上 —— 所以这个更适合用浏览器打开看，而不是从 shell 里操作。版本号对应 Android 版本： 16 是 Android 13，15 是 12L，14 是 11。

Directory sync uses scp. It is the only backend the Android userspace supports. 目录共享走 scp。这是 Android 用户态唯一支持的后端。

HaikuOS

x86_64 haiku-builder

The BeOS successor -- a complete graphical desktop operating system that is neither Unix nor Linux. Worth opening on the VNC console rather than treating as a headless build target.

BeOS 的继承者 —— 一个完整的图形桌面操作系统，既不是 Unix 也不是 Linux。值得用 VNC 控制台打开看看，而不是只把它当成一个无头的构建目标。

GNU Hurd

x86_64 · i386 hurd-builder

Debian GNU/Hurd, the only guest that ships a 32-bit image as well: --arch i386.

Debian GNU/Hurd，唯一一个同时提供 32 位镜像的系统：--arch i386。

Hurd has no virtio drivers, so it runs on emulated legacy hardware. The amd64 image needs a q35 machine with AHCI, which AnyVM selects for you.

Hurd 没有 virtio 驱动，只能跑在模拟的老式硬件上。amd64 镜像需要带 AHCI 的 q35 机型，AnyVM 会替你选好。

Plan 9

x86_64 · 9front plan9-builder

9front, the maintained Plan 9 fork. Not a Unix: there is no SSH daemon in the usual sense, and AnyVM talks to it over its own transport.

Directory sync is 9P, and Linux-host only. --sync 9p is the default here: the host mounts the guest's exportfs share through the Linux kernel v9fs client (mount -t 9p, needs root or sudo). On Windows and macOS hosts a Plan 9 guest still boots and still runs commands -- only -v folder sync is skipped.

Both directions are one-shot copies through that mount, not a live share: the push happens at boot, and the way back is --attach --sync 9p --p9-port <n> --pull-files, which is why the boot needs --p9-port to pin the forward. It uses 9P rather than the telnet tar stream every other agent guest uses because 9front's tar output does not survive the telnet pty.

两个方向都是经这个挂载做的一次性拷贝，不是活共享：开机时推进去，回来则靠 --attach --sync 9p --p9-port <n> --pull-files —— 所以开机时要用 --p9-port 把转发端口固定下来。这里走 9P 而不是其他 agent 客户机用的 telnet tar 流，是因为 9front 的 tar 输出过不了 telnet 的 pty。

Commands report status. A -- <cmd> run (and --attach) chains a marker through rc, waits until the command actually finishes, and AnyVM exits 0/1 with its result; --exec-timeout-sec (default 7200) only bounds a wedged guest.

命令带退出码。-- <cmd>（以及 --attach）会经 rc 链上一个标记，等命令真正跑完，AnyVM 按 0/1 退出；--exec-timeout-sec（默认 7200 秒）只是给卡死的客户机兜底。

ReactOS

i386 · 0.4.15 / 0.4.16 reactos-builder

An open-source reimplementation of Windows NT, and a tech preview here: it boots, runs commands and syncs a folder, but it is not as finished as the other guests. Upstream ships 32-bit x86 only, so this is the one guest AnyVM does not default to your host architecture: --os reactos resolves to i386 on its own.

ReactOS 是 Windows NT 的开源重新实现，在这里属于技术预览：能开机、能跑命令、能同步目录，但成熟度不及其他客户机。上游只发布 32 位 x86，所以它是唯一一个 AnyVM 不按宿主架构去猜的客户机：--os reactos 自己就会解析成 i386。

Commands report status. A -- <cmd> run (and --attach) chains a marker through cmd.exe's &&/||, waits until the command actually finishes, and AnyVM exits 0/1 with its result; --exec-timeout-sec (default 7200) only bounds a wedged guest. One ReactOS quirk, probed against a live 0.4.15 guest: its cmd does not set errorlevel for a failed dir or del (both read as success), while type, copy, unknown commands and cmd /c exit N all report failure correctly.

命令带退出码。-- <cmd>（以及 --attach）会经 cmd.exe 的 &&/|| 链上一个标记，等命令真正跑完，AnyVM 按 0/1 退出；--exec-timeout-sec（默认 7200 秒）只是给卡死的客户机兜底。一个 ReactOS 特有的坑（对真实 0.4.15 客户机实测）：它的 cmd 对失败的 dir 和 del 不置 errorlevel（都当成功），而 type、copy、未知命令和 cmd /c exit N 都能正确报错。

The image carries its own telnet server. ReactOS ships no remote-access server of any kind -- there is no sshd, and the networking tools it bundles are all clients -- so reactos-builder cross-compiles a small Win32 telnet daemon, copies it onto the volume while the guest is offline, and registers it as a boot-time service. AnyVM drives the guest over that channel, the same transport it uses for 9front. It authenticates nobody and is reachable only through the loopback-bound QEMU forward.

镜像自带一个 telnet 服务端。ReactOS 完全没有远程访问服务 —— 没有 sshd，自带的网络工具也全是客户端 —— 所以 reactos-builder 交叉编译了一个很小的 Win32 telnet 守护进程，在客户机关机状态下拷进磁盘，并注册成开机启动的服务。AnyVM 通过这个通道驱动客户机，用的是和 9front 相同的传输方式。它不做任何认证，只能经由绑定在回环地址上的 QEMU 端口转发访问。

Directory sync is tar, and it is the default here. --sync tar streams each shared folder as a ustar archive over that same telnet channel: host to guest at boot, then guest back to host once your command finishes. It is a one-shot copy in each direction rather than a live mount, so nothing is pulled back in --detach mode. Every other backend is unavailable: no sshd means no rsync, sshfs or scp, there is no 9P client and no SMB redirector, and while the NFS client stack does ship and load, its daemon hangs on start -- a ReactOS bug, not a builder gap. Guest paths are Windows-style: -v "$PWD:C:\work".

目录同步走 tar，也是这里的默认值。--sync tar 把每个共享目录打成 ustar 包，从同一条 telnet 通道里流过去：开机时从宿主推给客户机，命令跑完后再从客户机拉回宿主。两个方向都是一次性拷贝，不是实时挂载，所以 --detach 模式下不会回拉。其他后端都用不了：没有 sshd 就没有 rsync、 sshfs、scp，也没有 9P 客户端和 SMB 重定向器；NFS 客户端虽然装了也能加载，但它的守护进程启动即卡死 —— 那是 ReactOS 自己的 bug，不是构建器缺东西。客户机侧的路径是 Windows 风格的：-v "$PWD:C:\work"。

It boots on every host, but only because AnyVM withholds one QEMU option from it. Measured on the same image: about 18 seconds with KVM, 35 under Windows' WHPX, 68 under pure software emulation. The option is -rtc driftfix=slew, which replays timer interrupts a slow guest missed. ReactOS sizes every busy-wait by counting a loop between two such interrupts, so replayed ones make it measure zero, and from then on each delay -- even a one-microsecond one -- runs 2³² times, about nine seconds. AnyVM leaves that option off for ReactOS, which is why it boots here and not under a hand-written QEMU command line that copies the usual flags.

它在任何宿主上都能启动,但前提是 AnyVM 对它少传一个 QEMU 选项。同一个镜像实测:KVM 下约 18 秒,Windows 的 WHPX 下 35 秒,纯软件模拟下 68 秒。那个选项是 -rtc driftfix=slew —— 它会把慢客户机错过的时钟中断补发回去。而 ReactOS 正是靠"两次这种中断之间跑了多少圈"来标定所有忙等,补发会让它量出 0,于是之后每一次延时(哪怕只要 1 微秒)都要空转 2³² 次,约九秒。 AnyVM 对 ReactOS 不传这个选项,所以它能起来 —— 而照抄常规参数手写的 QEMU 命令行往往起不来。

No virtio at all. The guest has no virtio block, network, GPU, balloon or RNG driver, so AnyVM gives it an IDE disk, an e1000 NIC and QEMU's std VGA, and leaves the balloon and RNG devices off. A virtio disk would not even reach the desktop -- the boot drivers find no disk and the guest bugchecks 0x7B.

完全没有 virtio。这个客户机没有 virtio 的块设备、网卡、显卡、 balloon 和 RNG 驱动，所以 AnyVM 给它 IDE 磁盘、e1000 网卡和 QEMU 的 std VGA，并且不挂 balloon 和 RNG 设备。用 virtio 磁盘的话根本进不了桌面 —— 启动驱动找不到磁盘，客户机直接 0x7B 蓝屏。

RISC OS

armv7 · 5.30 riscos-builder

The Acorn operating system, still developed, and a tech preview here: it boots, runs commands and syncs a folder. RISC OS is a 32-bit ARM system with no 64-bit port, so like ReactOS it is a guest AnyVM does not default to your host architecture -- --os riscos resolves to armv7 on its own, and the machine is a Raspberry Pi 2 rather than QEMU's generic virt board.

Acorn 的操作系统，至今仍在开发，在这里属于技术预览：能开机、能跑命令、能同步目录。RISC OS 是纯 32 位 ARM 系统，没有 64 位移植，所以和 ReactOS 一样，它也是 AnyVM 不按宿主架构去猜的客户机 —— --os riscos 自己就会解析成 armv7，而且模拟的是树莓派 2 这块真实板子，不是 QEMU 通用的 virt。

Commands report completion, not status. The RISC OS agent is not a shell: it has no &&/|| and no status variable, so a -- <cmd> run (and --attach) waits until the command has finished -- no fixed read window -- but always exits 0 once it did, whatever the command's own outcome. --exec-timeout-sec (default 7200) bounds a wedged guest.

命令只报"跑完了"，不报成败。RISC OS 的 agent 不是 shell：没有 &&/|| 也没有状态变量，所以 -- <cmd>（以及 --attach）会等命令真正结束 —— 没有固定读窗口 —— 但一旦结束一律以 0 退出，与命令本身的成败无关。 --exec-timeout-sec（默认 7200 秒）给卡死的客户机兜底。

AnyVM downloads a patched QEMU for it. No released QEMU can boot RISC OS on a Raspberry Pi machine at all, so riscos-builder publishes its own build and AnyVM fetches it automatically on Linux x86_64. Four of the fixes in it are ordinary QEMU bugs with nothing to do with RISC OS; the rest are BCM2835 peripherals the guest drives directly, plus a model of the SMSC LAN9512 that is the Pi 2's real network chip and the only one this guest has a driver for.

AnyVM 会为它下载一个打过补丁的 QEMU。没有任何已发布的 QEMU 能在树莓派机型上把 RISC OS 启动起来，所以 riscos-builder 自己构建并发布一份，AnyVM 在 Linux x86_64 上会自动取用。其中四个修复是与 RISC OS 无关的通用 QEMU 缺陷；其余是客户机直接驱动的 BCM2835 外设，以及 SMSC LAN9512 的设备模型 —— 那是树莓派 2 上真实的网卡芯片，也是这个客户机唯一有驱动的一款。

The image carries its own agent. RISC OS ships no remote-access server of any kind: its module list has the TCP/IP stack and clients, but no sshd, no telnetd and no ftpd. So riscos-builder supplies one -- a small telnet agent written in Python, running on the Python 2.7 the RISC OS Open image already carries. AnyVM drives the guest over that channel, the same transport it uses for 9front and ReactOS. --sync tar streams each shared folder as a ustar archive down it: host to guest at boot, guest back to host once your command finishes. Every other backend is unavailable -- no sshd means no rsync, sshfs or scp, and there is no 9P client.

镜像自带一个 agent。RISC OS 完全没有远程访问服务：模块列表里有 TCP/IP 协议栈和各种客户端，但没有 sshd、没有 telnetd、也没有 ftpd。所以 riscos-builder 自己补了一个 —— 用 Python 写的小型 telnet agent，跑在 RISC OS Open 镜像本来就自带的 Python 2.7 上。AnyVM 通过这条通道驱动客户机，用的是和 9front、 ReactOS 相同的传输方式。--sync tar 把每个共享目录打成 ustar 包从这条通道流过去：开机时从宿主推给客户机，命令跑完后再从客户机拉回宿主。其他后端都用不了 —— 没有 sshd 就没有 rsync、sshfs、scp，也没有 9P 客户端。

There is no keyboard, and that is RISC OS, not QEMU. The Raspberry Pi ROM ships no USB keyboard driver at all -- it announces No keyboard present - autobooting and treats every attached HID device as one it has no driver for. The desktop starts and the VNC console shows it, but you cannot type into it; drive the guest over -- commands instead. It is also why the builder prepares the disc offline rather than running an installer: there is no console to type one into.

没有键盘，这是 RISC OS 的限制，不是 QEMU 的。树莓派版 ROM 里根本没有 USB 键盘驱动 —— 它开机时会打印 No keyboard present - autobooting，并且把接上的每个 HID 设备都当成没有驱动的设备。桌面会正常启动，VNC 控制台也能看到，但你没法往里打字；请改用 -- 传命令的方式驱动它。这也是构建器为什么要离线改盘、而不是跑安装程序的原因：根本没有可以输入的控制台。

Redox OS

x86_64 · 0.9.0 redox-builder

A Unix-like microkernel operating system written in Rust, with its own filesystem (RedoxFS), its own shell (Ion) and its own desktop (Orbital). It boots, runs commands and syncs folders here. Everything in userspace is a scheme rather than a syscall, which is why several things below work differently from every other guest.

用 Rust 写的类 Unix 微内核操作系统，自带文件系统（RedoxFS）、自带 shell（Ion）、自带桌面（Orbital）。在这里能开机、能跑命令、能同步目录。它的用户态一切皆 scheme 而非系统调用，下面几处与其他客户机不同的行为都源于此。

Commands report status. A -- <cmd> run (and --attach) chains a marker through Ion's &&/||, waits until the command actually finishes, and AnyVM exits 0/1 with its result; --exec-timeout-sec (default 7200) only bounds a wedged guest.

命令带退出码。-- <cmd>（以及 --attach）会经 Ion 的 &&/|| 链上一个标记，等命令真正跑完，AnyVM 按 0/1 退出；--exec-timeout-sec（默认 7200 秒）只是给卡死的客户机兜底。

The image carries its own agent. Redox ships no remote-access server -- no sshd, no telnetd -- so redox-builder bakes one in: a small telnet agent. It cannot be an ordinary program, because the 0.9.0 kernel has no process-creation syscall at all; spawning lives in userspace, so the agent is a no_std binary linked against Redox's own runtime rather than its C library. AnyVM drives the guest over that channel, the same transport it uses for 9front, ReactOS and RISC OS. --sync tar streams each shared folder through it as a ustar archive: host to guest at boot, guest back to host once your command finishes. Guest paths are ordinary Unix paths. No other backend exists here -- without an sshd there is no rsync, sshfs or scp, and no 9P client.

镜像自带一个 agent。Redox 没有任何远程访问服务 —— 没有 sshd，也没有 telnetd —— 所以 redox-builder 自己烤了一个进去：一个小型 telnet agent。它没法写成普通程序，因为 0.9.0 内核根本没有创建进程的系统调用；创建进程这件事在用户态完成，于是这个 agent 是链接 Redox 自家运行时（而非 C 库）的 no_std 二进制。AnyVM 通过这条通道驱动客户机，用的是和 9front、ReactOS、RISC OS 相同的传输方式。--sync tar 把每个共享目录打成 ustar 包从这条通道流过去：开机时从宿主推给客户机，命令跑完后再从客户机拉回宿主。客户机路径就是普通的 Unix 路径。这里没有别的后端 —— 没有 sshd 就没有 rsync、sshfs、scp，也没有 9P 客户端。

The bootloader always shows a video-mode menu. It has no timeout and reads no configuration, so it waits for a keypress on every boot. AnyVM presses Return for you over the QEMU monitor until the guest comes up, which is why a Redox boot needs no interaction even though the VNC console briefly shows the menu.

引导器每次开机都会弹出显示模式菜单。它没有超时、也不读任何配置，所以每次都停在那里等按键。AnyVM 会通过 QEMU monitor 替你按下回车，直到客户机起来为止 —— 这就是为什么 VNC 控制台会一闪而过地出现那个菜单，但整个过程不需要你动手。