Solution for: Proxmox backup error due to iothread=1

If you see the following error when trying to backup a KVM VM image on Proxmox:

ERROR: Backup of VM 100 failed – disk ‘scsi0’ ‘zfsvols:vm-100-disk-1’ (iothread=on) can’t use backup feature currently. Please set backup=no for this drive at /usr/share/perl5/PVE/VZDump/ line 77. INFO: Backup job finished with errors TASK ERROR: job errors

edit /etc/pve/qemu-server/100.conf, look for a line similar to

scsi0: zfsvols:vm-100-disk-1,iothread=1,size=70G

and change it to

scsi0: zfsvols:vm-100-disk-1,iothread=0,size=70G

Afterwards, it’s possible to backup the VM.

How to check filesystems in a qcow2 image

A useful post how to fsck (check and fix) a filesystem in a qcow2 image (as typically used for KVM VMs, e.g. in Proxmox):

How to recover a qcow2 file using fsck

On Proxmox or Debian, one does the following:


  • Make sure the according VM isn’t running, i.e. the partition not mounted
  • Adjust the commands below to match your system, use the correct qcow2 image, use the correct fsck-variant, fsck the correct filesystem, note that -p tries to automatically fix errors!
# modprobe nbd max_part=8
# qemu-nbd --connect=/dev/nbd0 /var/lib/vz/images/100/vm-100-disk-1.qcow2
# fdisk -l /dev/ndb0
/dev/nbd0p1            2048     7813119     3905536   82  Linux swap / Solaris
/dev/nbd0p2   *     7813120   119537663    55862272   83  Linux
# fsck.ext4 /dev/nbd0p2
# fsck.ext4 -p /dev/nbd0p2
# qemu-nbd --disconnect /dev/nbd0

Like this, one doesn’t need to boot the VM using a boot ISO/CDROM and can fix the filesystem right from the host node.


zpool: Symbol `spa_feature_table’ has different size in shared object, consider re-linking

If you see the following error message when executing ‘zpool status’ after “upgrading” Proxmox to the (currently) latest version with ZoL 0.6.4 instead of 0.6.3:

zpool: Symbol `spa_feature_table' has different size in shared object, consider re-linking


“Re-linking” doesn’t have a special meaning in ZFS/ZoL terminology, it rather just describes the usual linking step after compiling some source code.


The most likely cause is that some new, updated and required packages have not been installed (e.g. with ‘uname -a’, you’ll see that the old kernel is still running, even after rebooting). Usually, this happens if one executes “apt-get update && apt-get upgrade” (as usual) rather than “apt-get update && apt-get dist-upgrade“. So, in order to solve this problem, do:

# apt-get update && apt-get dist-upgrade
# reboot

In this case, ZoL 0.6.4 also includes a couple of new features which can be enabled for all local ZFS pools by executing:

# zpool upgrade -a
This system supports ZFS pool feature flags.

Enabled the following features on 'rpool':