Block I/O tuning is not available on this host

Hello, I set up a copy of Linux MX on my computer. I was able to set up Whonix just fine and used it a bit using libvirt virtual machine manager qemu/kvm.

A day later I decided I wanted to boost my security so I reinstalled the same distro but with disk encryption enabled this time.

I set up Whonix the same way I did last time except this time it won’t work, I keep getting this error

Error starting domain: unsupported configuration: Block I/O tuning is not available on this host

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/", line 65, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/", line 101, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/", line 57, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/", line 1329, in startup
  File "/usr/lib/python3/dist-packages/", line 1353, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: unsupported configuration: Block I/O tuning is not available on this host

Please help, I’ve spent a few hours on this error but I can’t fix it, I’m new to linux but not new to computers, I’m guessing I must’ve missed something obvious to everyone but me.

Have you installed MX Linux with mostly default settings (where have you deviated from them)?
Is your operating system up to date?
Are you using a custom kernel?
Have you followed the instructions from the wiki to install Whonix and its dependencies for a Debian system?


My system is up-to-date, I ran both sudo apt-get update and apt-get upgrade and all of the provided commands for Debian on the Whonix install.

The only differences between my system and a standard MX Linux install is my partitions are encrypted, I’m using picom as my compositor and I have the proprietary NVIDIA drivers + CUDA installed. I never modified the kernel files for MX Linux in any way.

I also ensured my CPU was compatible by running kvm-ok for both my encrypted and unencrypted install.

My .qcow2 files are actually in my home partition and are linked to the images default folder using a symlink, but that worked when I set it up the first time without this error.

As previously stated my set-up worked when it wasn’t encrypted, I’m not sure what’s causing the error now that I’ve re-installed.

Thinking on it further, I DID do one other thing different, I installed Virt-manager through the MX package installer while installing my other apps to save time before going through the set-up on the site, I didn’t do that last time I decided to just uninstall Virt-manager through the package installer and re-install virt manager the way I did previously through the terminal. That fixed the I/O bug, everything is working again like it did before.

If you can explain to me how that fixed it I’d love to understand because I’m very curious how that solved the problem lol, just so I can understand Linux more. Shouldn’t it be the same package whether it’s installed through the terminal with apt-get or the mx package installer since the package installer is just running the same commands in the background?? That’s what I thought but clearly I’m missing something.

1 Like

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.