backup failed

mir

Famous Member
Apr 14, 2012
3,580
137
133
Copenhagen, Denmark
I am seeing this in the backup log after I have enabled iothread:
111: Jul 29 05:15:03 ERROR: Backup of VM 111 failed - disk 'scsi0' (iothread=on) can't use backup feature currently. Please set backup=no for this drive at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 74.

Is this a feature or a bug?

And if this is a feature then why?

qemu-server: 4.0-85
 
Well, I think the proxmox backup code never had implemented Aiocontext.
The upsteam qemu backup code have implemented it last year
http://git.qemu.org/?p=qemu.git;a=commit;h=761731b1805f6ef64eb615e5b82a0801db3cde78

I known the proxmox code is not too much different, maybe it's working too now.
Nope, I have just tested with commented out line 74 in /usr/share/perl5/PVE/VZDump/QemuServer.pm. Doing this resolves in this error message: ERROR: Node 'drive-scsi0' is busy: block device is in use by data plane

So I think this feature is missing in proxmox which makes line 74 still needed in QemuServer.pm.
 
Seems to still be an issue.

Code:
ERROR: Backup of VM 102 failed - disk 'virtio0' 'local-lvm:vm-102-disk-1' (iothread=on) can't use backup feature currently. Please set backup=no for this drive at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 77.
 
Backup of VM 444 failed - disk 'virtio0' 'ZFS:vm-444-disk-2' (iothread=on) can't use backup feature currently
 
Same problem here trying to backup a Win10pro guest, with VirtIO drive:
ERROR: Backup of VM 101 failed - disk 'virtio0' 'local-zfs:vm-101-disk-1' (iothread=on) can't use backup feature currently. Please set backup=no for this drive at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 76
 
In Version 5.0-32 the same error
Code:
disk 'virtio0' 'data:vm-102-disk-1' (iothread=on) can't use backup feature currently. Please set backup=no for this drive at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 77
 
Same error here on 5.0-32 - so what is the recommended way to resolve this?

turn of iothread or exclude iothread disks from backup? it is simply not yet implemented, as the error message says.
 
Ran into this issue today as well.
Is an implementation actively being worked on or would it be wiser to abandon iothread altogether if one needs the built-in backup functionality sometime in the foreseeable future?

And while I do understand that online backups of iothread drives would need some alterations as to how they are implemented in vzdump, shouldn't simple file level based offline backups be possible without a lot of rewrites?


Regards,
Heiner
 
Last edited:
  • Like
Reactions: Bent
Yes, if the machine is stopped the IOThread settings means nothing.
I disable IOThread in settings, execute backup, then enable IOThread.
The error should not be generated if the machine is stopped.
 
  • Like
Reactions: Bent
Any update on this topic?

Will backups with iothread=on be available soon?

iothread gives VMs a great IO performance benefit. I just cant justify to disable IO thread just for a backup. Is there anything holding you back from implementing this feature?
 
Sorry for being annoying -> Push?

Any update on this topic so far? I think this is a really important topic as there is no other built-in backup solution.
 
  • Like
Reactions: John Morrison
Still appears to be an issue 5.2-7. Will be trying the 5.3.x line on 12/24.

No need to test, same issue (Proxmox VE 5.3-6):
Code:
INFO: starting new backup job: vzdump XXX --storage local --mode snapshot --compress lzo --remove 0 --node YYYY
INFO: Starting Backup of VM XXX (qemu)
INFO: status = running
INFO: update VM XXX: -lock backup
INFO: VM Name: XXX
ERROR: Backup of VM XXX failed - disk 'virtio0' 'XXX:XXX/vm-XXX-disk-1.qcow2' (iothread=on) can't use backup feature currently. Please set backup=no for this drive at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 77.
INFO: Backup job finished with errors
TASK ERROR: job errors

I don't think this will ever be fixed after years. Sadly. Maybe it's a limitation of QEMU which I am not aware of but live snapshots with iothread would be really useful in any modern usecase.

Is there anything we (community) can do to assist development?
 
Last edited:
Hey Guys,
Any updates from this issue still having on
Code:
pve-manager/5.4-3/0a6eaa62 (running kernel: 4.15.18-12-pve)