KubeSilicon brings KubeVirt-style virtual machines to Apple Silicon Macs

The problem: no KVM on macOS

KubeVirt, the CNCF-incubating project that adds virtual machine support to Kubernetes, cannot run on Apple Silicon Macs. According to a dev.to post by Matheus Thurler, the reason is straightforward: KubeVirt's launcher depends on KVM, the Linux kernel's hypervisor, and macOS has no equivalent. Thurler maintains VirtFoundry, a private cloud operator built on KubeVirt, which meant every change involving virtual machines forced him onto a Linux server even though his M5 Pro machine could host the cluster itself.

His answer is KubeSilicon, an Apache-2.0 licensed project hosted on GitHub that boots Linux ARM64 virtual machines directly on the Mac and makes them reachable from pods in a local Kubernetes cluster.

How it works

Users declare a SiliconVM custom resource under the kubesilicon.io/v1 API group. The manifest looks familiar to anyone who has used KubeVirt: fields for CPU count, memory, a disk image source and size, and cloud-init user data such as users and SSH keys.

A daemon called kubesilicond runs on the macOS host, outside the cluster. It watches SiliconVM objects through the Kubernetes API, downloads and converts the disk image, builds a cloud-init ISO, and starts the guest using Apple's Virtualization.framework. Each VM runs as its own detached process, and the daemon writes status.phase and status.ip back to the object. It also creates a headless Kubernetes Service, so a name like demo.default.svc.cluster.local resolves from any pod. Because the VM processes are detached, the daemon can stop or crash without taking running guests down with it.

Getting started takes three commands, Thurler writes: create a kind cluster, run make install, and apply an example manifest. In his tests a VM reached Running in about six seconds once its image was cached, and a busybox pod pinged it with one to two milliseconds of latency.

Where it runs, and where it does not

The daemon needs only two things: access to the cluster's Kubernetes API and a network path from pods to the VMs, which receive NAT addresses in the 192.168.64.x range on the Mac. The only validated setup is kind on Docker Desktop. Minikube, Colima, OrbStack and k3d should work in principle because they run inside a VM or container on the same machine, but Thurler has not tested them and asks users to report results. Cloud-hosted clusters are out of scope entirely, since the VMs live on your Mac.

How it compares with KubeVirt

KubeSilicon is explicitly not KubeVirt and does not reuse its CRDs, though its API is deliberately shaped like KubeVirt's. The differences are substantial. KubeVirt uses KVM and QEMU and runs VMs inside pods on Linux nodes; KubeSilicon uses Apple's Virtualization.framework and runs them as host processes outside the cluster. KubeVirt supports Linux, Windows and other guests, plus live migration, hotplug and snapshots; KubeSilicon is limited to Linux ARM64 guests and offers none of those features. Thurler's own framing is that KubeVirt remains the right choice on Linux servers, while KubeSilicon targets the laptop: development, demos and CI.

He also sketches a possible bridge to VirtFoundry, which sits above the hypervisor layer and adds tenants, VPCs, IAM and a UI. Mapping VirtFoundry's KubeVirt resource usage onto SiliconVM is an idea he wants to explore next, but nothing is built yet.

Stability and current limits

The post includes a candid stability note. Early testing produced random guest crashes, with kernel oops reports and SIGILL faults in three out of four boots under Apple's default disk mode. Switching the disk attachment to a cached mode with fsync yielded zero crashes across nine boots. Thurler cautions that the sample is small and the cause below the framework is unknown, describing the result as suggestive rather than conclusive, with the numbers recorded in the project's validation document.

Other limits are considerable: one Mac and one worker only, with multi-Mac support as a design goal rather than a feature; the headless Service exposes no ports, so users must reach VMs by IP; a VM whose launcher process dies is not restarted automatically; macOS guests are out of scope; and the v1 API will change.

Why it matters

KubeVirt-style development has effectively required Linux hardware, leaving Apple Silicon users to rent servers, keep a spare Linux box around, or skip local VM testing entirely. For anyone building operators or applications that create virtual machines, KubeSilicon offers a way to exercise the full flow on a single machine. It is early-stage, single-maintainer software and no substitute for KubeVirt in production, but it closes a genuine workflow gap, and its findings on Virtualization.framework disk-mode stability may interest anyone else building on Apple's hypervisor stack.