Development Notes about existing Virtualizers Support by Whonix as well as ports to new Virtualizers. VirtualBox, QEMU, KVM, VMware, etc.

Introduction[edit]

Whonix is officially supported on the following platforms:

VirtualBox[edit]

Why use VirtualBox over KVM?[edit]

See Why use VirtualBox over KVM?

Why use VirtualBox over Qubes?[edit]

See Why use VirtualBox over Qubes?

KVM[edit]

Why use KVM over VirtualBox?[edit]

See Why use KVM over VirtualBox?

Why use KVM over Qubes?[edit]

TODO: document

Qubes[edit]

See Why use Qubes over other Virtualizers?

libvirt[edit]

In an ideal world Whonix would support all virtualization platforms. Theoretically this could be achieved by utilizing libvirt, since it is a toolkit that supports KVM, QEMU, Xen, Virtuozzo, VMWare ESX, LXC, Bhyve and other virtualization platforms on the Linux, FreeBSD, Windows and macOS operating systems. In practical terms libvert is out of the question because it does not yet abstract some commands that Whonix requires, see: libvirt-users: Does libvirt abstract each and any vm specific command?. That means without patches from interested parties, libvert APIs will not expose necessary functionalities.

Other Virtualization Platforms[edit]

Theoretically, Whonix could run inside any virtualizer because its build scripts are very modular and extensible. In reality, Whonix does not have sufficient developer resources to test other virtualizers. If additional contributors join the project and become maintainers for other virtualizers, then support for those might be officially added.

Simplicity of Ports to Other Virtualizers[edit]

In short: Very doable.

Quote Whonix homepage:

There are no artificial restrictions imposed on possible system configurations in Whonix.

And there really are none. There is no special code in Whonix which prevents software forks of Whonix being made compatible with VMware or any other virtualizers. Whonix is even Software Fork Friendly. Even the possibility to use distro-morphing is made for developers to simplify the process of porting Whonix to other virtualizers and/or architectures.

As an analogy, the Whonix port to other virtualizers is "95%" done. All of Whonix is in theory already perfectly compatible with any virtualizer. Only a Support Plan and a "plugin" (build step) for the specific virtualizer is required. This is being elaborated below. Derivative-Maker is the build script which is used to build Whonix from source code. It very feature rich (can create images for VirtualBox, KVM, various architectures such as Intel/AMD64, arm64, ppc64el and so much more), very customizeable and easily extensible by other developers.

The lack of Whonix's derivative-maker for other virtualizer support is because nobody who accomplished to research, document and/or Whonix with a different virtualizers decided to go the extra mile and contribute a build steps for that virtualizer to the build script and/or fork Whonix, keep maintaining a fork of Whonix for that virtualizer.

Whonix's build script is "plugin" based. There are build-steps. It is easy for developers to add additional build steps such as to perform steps required to support other virtualizers.

All that's missing for other virtualizer support are some bits and pieces. By comparison example, to accomplish VirtualBox support, there's two build major steps:

convert the raw image to vdi for VirtualBox
create the VirtualBox settings files
optionally for example for redistributable builds it makes sense to have a export VirtualBox VMs as ova and upload script

For example, some users already managed to write documentation how to use Whonix in VMware or QEMU and there are various ports of Whonix to other architectures in various development stages.

Whonix-Host ISO versus Virtualizer Support[edit]

Note, that the upcoming Whonix-Host ISO will cannot simplify ports of Whonix to other virtualizers. This is because the Whonix-Host ISO is "designed" to be run on host operating systems and not inside VMs. "Designed" is written in quotes because that is not an intentional user freedom restriction. It is because Whonix-Host is a host operating system which comes with a virtualizer installed by default that runs the Whonix-Gateway and Whonix-Workstation VMs.

Running Whonix-Host in a VM would result in Nested Virtualization . There are performance and reliability issues with that. Specifically when mixing virtualizers such as when attempting to run a Whonix-Host ISO that comes with VirtualBox inside VMware. These are general limitations by all all virtualizers and unspecific to Whonix.

Support Plan[edit]

As outlined above, Whonix needs dedicated contributors to support other virtualization platforms. Essential contributor responsibilities include:

Essential Tests
running new security feature tests
performing Leak Tests and relevant Protocol Leak and Fingerprinting Protection tests
conducting other miscellaneous security and performance tests to confirm the platform has full functionality and is fit for purpose

Ideally, a dedicated contributor would also create, sign and upload native images for the alternative virtualization platform (such as VMware, QEMU, etc.).

Virtualizers Support Feature Requests[edit]

On one hand, there is already a number of officially supported Whonix platforms maintained by the current contributors. On the other hand, there is a plethora of unsupported virtualizers, architectures and related applications. In the history of Whonix, there have been feature requests to add support for OpenVZ, docker, QEMU, Bochs, VMware, Xen, Proxmox, Kubernetes and more.

While in theory, adding support for other platforms would be feasible for new contributors (see above chapter Other Virtualization Platforms), the existing contributors most likely will not be able to take this on because of time restraints due to the maintenance workload required for existing platform support.

Partially Finished Attempts[edit]

QEMU
VMware
Mac M1 / M2
See also: Ports of Whonix to other architectures

Whonix Virtualization Platforms

Contents