Wish I could tell you that the problem was a simple deviation from the one true path shown in the documentation. But the truth is I have no idea what happened.
On any given AMD/Intel Debian-based system I expect to be able to install the QEMU/KVM hypervisor (from the qemu-system-x86
package) and its libvirt client (from libvirt-daemon-system
) and have all the prerequisites needed to run Whonix without any problem, with or without employing LUKS encryption on the host.
When you install the libvirt
hypervisor client, you also get the virsh
TUI that provides everything you need to manage VMs and their networks, from creation, to editing, to attaching to the serial text console and issuing commands in the guest VM.
If you prefer a GUI (needed to properly work with the Whonix-Workstation’s GUI apps), you can also install the Virtual Machine Manager (from virt-manager
) and the SPICE GTK widget (from gir1.2-spiceclientgtk-3.0
) to be able to show the VMs GUI console. Virtual Machine Manager
isn’t the only GUI to libvirt
- there are others like Cockpit
which is web-based.
So, to have a fully functional setup, apt install qemu-system-x86 libvirt-daemon-system gir1.2-spiceclientgtk-3.0 virt-manager --no-install-recommends
should be sufficient. Of course, each of these packages depends on (and will install) other packages which may in turn depend on yet more packages (it’s turtles all the way down). It’s the job of dpkg to sort out the dependency of each package, and that of higher clients like apt to determine how to orchestrate and acquire them. At an even higher level you have Synaptic
which is the old Debian GUI package manager. Newer still, you have package managers like the MX Package Installer
, which offers more pragmatic software bundles like those you see in the Virtualization category, and has support for installing even more software than a basic Debian system by means of Flatpaks. If you right-click on an entry in MX Package Installer
, you can get more info into which apt
packages are going to be installed.
If you’re wondering why you can’t just install virt-manager
with apt
and be done with it (which is to say, why doesn’t virt-manager
declare libvirt
as a dependency), the answer may be nuanced: some Linux distros do (as most users would want to use both), while others don’t, as you can run virt-manager
without any hypervisor, and it won’t… crash. As for libvirt
, it doesn’t actually depend on QEMU/KVM
, as it could work just as well over LXC
, Xen
and others.
You probably expected a simple answer, not a sermon, but I can tell you that all this is actually oversimplified already and just scratching the surface. Dependency is associated with hell for a reason, and package managers are at the heart of it. A Linux distro isn’t actually much more than the Linux kernel, with a bunch of apps on top, glued together by one or more package managers. And finally, it’s worth mentioning that package managers like npm
or pip
also play a central role in modern software development.
Anyway, yes - using the MX Package Installer
to install Virt-manager (libvirt)
shouldn’t give you any problem, and no - I don’t know why it did.