mrkeyoor.com_
Mon 09 Nov 08:33 UTC
Open Source3 min read

Redox boots on Cloud Hypervisor, with deployment work still ahead

Redox has merged Cloud Hypervisor boot changes and a Virtio-FS driver. Shutdown and first-boot setup remain unfinished.

Redox has merged Cloud Hypervisor boot changes and a Virtio-FS driver. In a November 8, 2026 development report, developer MJ Pooladkhay says Redox OS now boots to a working shell on Cloud Hypervisor. The changes reduce its dependence on legacy PC hardware, but deployment work remains unfinished.

Redox still boots through UEFI firmware. Pooladkhay reports that Redox cannot shut down Cloud Hypervisor by itself, and first-boot configuration remains planned. Developers evaluating an unattended service should treat this as documented progress toward that goal. No image boot or isolation testing was performed for this article.

The missing timer behind a stalled ping

Cloud Hypervisor omits older devices that Redox had relied on under QEMU, including the 8259 interrupt controller and programmable interval timer. Getting a shell required fixes to disk detection and interrupt routing, alongside a bootloader correction, according to Pooladkhay's account.

One failure explains why reaching a shell does not establish deployment readiness. A four-packet ping sent its first packet and received a reply, then stopped. Reading the clock worked, but the interrupt handler responsible for waking timed waits never ran. The same missing tick also meant a process kept the CPU until it blocked or yielded.

Pooladkhay's development report describes the replacement: when HPET is absent, each CPU uses its local APIC timer in TSC-deadline mode. The tick period uses the scale supplied by kvmclock. Pooladkhay reports that the fix restored timed wakeups and preemptive scheduling, allowing the ping to send all four packets one second apart.

The report also identifies a remaining timer limitation: the scale is computed at boot, so migration to a host with a different TSC frequency changes the tick rate. Pooladkhay lists that issue as unfinished work.

Shared folders make the host setup part of the decision

The merged Virtio-FS driver lets Redox access selected directories on a Linux host. Each share appears as a separate Redox scheme, which can be included in or excluded from a process's namespace. The development report says the driver works on QEMU and Cloud Hypervisor, and that guest changes appear on the host immediately.

That supports a design in which the operating-system image is disposable while persistent files live in host directories. Virtio-FS requires the virtiofsd daemon on the host beside the hypervisor. Developers considering this design need control over that host setup.

A shell comes before an unattended server

NLnet's project description identifies the goal as Redox running web services inside a virtual machine. The current report separates that goal from completed work: cloud-init-compatible hostname and SSH-key setup remains planned, as do snapshot-and-restore support and firmware-free PVH boot.

For anyone evaluating an unattended instance, the next evidence to watch is the planned regression test and deployment guide. Pooladkhay wants CI to check a shell, DHCP, a four-packet ping and an HTTPS download on both QEMU and Cloud Hypervisor. Those checks would make the reported progress repeatable; the November 8 report lists them as work still to do.

Sources

  1. Virtualized Redox: from Virtio-FS to Cloud Hypervisor, and beyond
  2. NLnet: Virtualized Redox