The aim of machine virtualisation is to run a guest operating system within or alongside the host’s normal operating system. Traditionally, this has been achieved by writing a great deal of code to work with a hypervisor, to handle all input and output (I/O) devices, so that the guest operating system runs just the same as it would normally. While recent versions of macOS running on Intel and Apple silicon platforms still support that approach with their Hypervisor framework, there’s a limited number of products that can offer such full virtualisation.

The newer approach offered by the Virtualisation framework is often termed para-virtualisation, or para-virtual I/O devices, as it greatly reduces the work required in the virtualisation app. It does so with the involvement of both the guest operating system, which has to support this approach, and the host, in this case macOS 12 and later running on Apple silicon hardware (although Apple also supports this for Linux on Intel Macs).

To do this, Apple has adopted the standard originally developed by Rusty Russell, which has become virtio (also VIRTIO, Virtio or VirtIO), a contraction for virtual I/O, which describes succinctly what it provides. This is an abstraction layer provided over I/O devices. When the guest operating system calls to open a file, for example, that’s passed to a front-end virtio storage device para-driver, and from there into a virtio back-end driver which interacts with the storage device.

Although this might seem less efficient than traditional virtualisation, in practice it can prove much more efficient. Its most obvious advantage is that creating a virtualiser app becomes a matter of configuring and opening the required virtio devices, and letting the guest, virtio and the host get on with it. And that’s essentially what an app using the Virtualisation framework does.

macOS supports eight virtio devices for macOS guests:

• memory balloon, handling requests for additional memory,
• block (storage), providing dedicated storage for the guest,
• file system, for storage shared between the guest and host,
• network, to access network interfaces, available as either bridged or NAT attachments,
• entropy, for random number generation,
• console, for serial communications,
• socket, for shared sockets with the host,
• sound, for audio.

These are documented in Apple’s developer documentation, and formally defined in the virtio standard.

In addition to those, custom devices are provided outside the virtio standard for:

• input, as keyboard and pointing devices,
• Spice agent, to support a shared clipboard,
• Mac graphics and display, including Metal and GPU support.

These are laid out systematically in the following diagram.

and available in this tear-out PDF: virtualisation1

Apple has incorporated support for virtio as a guest operating system into macOS Monterey and later, and Linux is one of the few other operating systems which supports virtio. Although there’s common ground between macOS and Linux in many virtio devices, there are also important differences. For example, macOS guests are given special access to Metal and accelerated graphics, but Linux works through a virtio device instead.

Virtio and the approach adopted by the Virtualisation framework is already well-proven, as it is used in Linux with KVM/QEMU and other virtualisation. Insu Jang has written a clear and detailed account of how virtio works in Linux, but I have been unable to find comparable information for macOS.

The end result is that apps using the Virtualisation framework can be very small and simple; they needn’t be more than a few hundred KB yet still support a full range of I/O devices. They also shouldn’t require helper apps or extensions. That contrasts with traditional apps working with the Hypervisor framework, which are commonly hundreds of megabytes in size, and require kernel or system extensions, helper apps and more. However, they can also run guest operating systems which don’t have native support for virtio, such as Windows.

Despite the simplicity of using Virtualisation code, apps running in guest operating systems using it should perform very well, with native performance on CPU cores and in accelerated graphics. As I’ve already reported, performance of individual virtio devices depends on their implementation and any restrictions imposed on them by the host macOS.

Thus, currently supported guest operating systems are:

• macOS 12 Monterey, 13 Ventura
• Linux for the host architecture.

and supported hosts are:

• all Apple silicon Macs running macOS 12 Monterey or 13 Ventura (unable to run Intel Linux)
• Intel Macs running macOS 12 Monterey and 13 Ventura (Intel Linux only, not macOS).

Some features are only available when the host is running macOS 13 Ventura.

Previous articles:
Virtualisation on Apple silicon Macs: 1 How well does it work?
also see Why are Disk Images so slow at writing?