Problem with backup (kvm: warning: host doesn't support requested feature)

Mors

Member
Mar 15, 2022
4
2
23
Poland
A few days ago I restored a VM from a backup stored on a local disk — there were no problems.

When I tried to back up this restored VM to a PBS server, an error occurred related to missing CPU instructions. As a test, I also tried to make a backup to a local disk, and the result was identical.

I know that my CPU is too old to run this VM, but not being able to back it up without changing the settings seems a bit excessive. :)

My question is:
Why can I restore the VM from backup, but I cannot back it up?

When I changed the VM CPU setting from x86-64-v3 to x86-64-v2, the backup completed successfully.
It looks like PVE is a bit overzealous in checking VM CPU compatibility.

When the CPU is set to: x86-64-v3:
INFO: starting new backup job: vzdump 100 --mode stop --remove 0 --notification-mode notification-system --notes-template '{{guestname}}' --node pve01 --storage hdd-raid --compress zstd
INFO: Starting Backup of VM 100 (qemu)
INFO: Backup started at 2026-05-19 16:50:09
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: OpenVPN-client-alm10
INFO: include disk 'scsi0' 'local-zfs:vm-100-disk-0' 12G
INFO: creating vzdump archive '/mnt/hdd-raid/pve/dump/vzdump-qemu-100-2026_05_19-16_50_09.vma.zst'
INFO: starting kvm to execute backup task
kvm: warning: host doesn't support requested feature: CPUID[eax=01h].ECX.fma [bit 12]
kvm: warning: host doesn't support requested feature: CPUID[eax=01h].ECX.movbe [bit 22]
kvm: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.bmi1 [bit 3]
kvm: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.avx2 [bit 5]
kvm: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.bmi2 [bit 8]
kvm: warning: host doesn't support requested feature: CPUID[eax=80000001h].ECX.abm [bit 5]
kvm: Host doesn't support requested features
ERROR: start failed: QEMU exited with code 1
INFO: aborting backup job
ERROR: VM 100 not running
VM 100 not running
ERROR: Backup of VM 100 failed - start failed: QEMU exited with code 1
INFO: Failed at 2026-05-19 16:50:12
INFO: Backup job finished with errors
INFO: notified via target `mail-to-root`
TASK ERROR: job errors

When the CPU is set to: x86-64-v2:
INFO: starting new backup job: vzdump 100 --mode snapshot --notification-mode notification-system --remove 0 --node pve01 --notes-template '{{guestname}}' --compress zstd --storage hdd-raid
INFO: Starting Backup of VM 100 (qemu)
INFO: Backup started at 2026-05-19 16:55:24
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: OpenVPN-client-alm10
INFO: include disk 'scsi0' 'local-zfs:vm-100-disk-0' 12G
INFO: creating vzdump archive '/mnt/hdd-raid/pve/dump/vzdump-qemu-100-2026_05_19-16_55_24.vma.zst'
INFO: starting kvm to execute backup task
INFO: starting backup via QMP command
INFO: started backup task 'bb6fbe75-02e4-4f64-877c-f8ddaffb30e5'
INFO: 19% (2.3 GiB of 12.0 GiB) in 3s, read: 795.1 MiB/s, write: 165.8 MiB/s
INFO: 34% (4.2 GiB of 12.0 GiB) in 6s, read: 623.9 MiB/s, write: 121.8 MiB/s
INFO: 58% (7.0 GiB of 12.0 GiB) in 9s, read: 984.0 MiB/s, write: 103.9 MiB/s
INFO: 62% (7.5 GiB of 12.0 GiB) in 12s, read: 171.9 MiB/s, write: 150.7 MiB/s
INFO: 76% (9.2 GiB of 12.0 GiB) in 15s, read: 574.6 MiB/s, write: 359.0 MiB/s
INFO: 84% (10.2 GiB of 12.0 GiB) in 18s, read: 319.5 MiB/s, write: 206.4 MiB/s
INFO: 91% (11.0 GiB of 12.0 GiB) in 21s, read: 280.3 MiB/s, write: 280.3 MiB/s
INFO: 100% (12.0 GiB of 12.0 GiB) in 22s, read: 1.0 GiB/s, write: 38.9 MiB/s
INFO: backup is sparse: 7.90 GiB (65%) total zero data
INFO: transferred 12.00 GiB in 22 seconds (558.5 MiB/s)
INFO: stopping kvm after backup task
INFO: archive file size: 3.11GB
INFO: adding notes to backup
INFO: Finished Backup of VM 100 (00:00:25)
INFO: Backup finished at 2026-05-19 16:55:49
INFO: Backup job finished successfully
INFO: notified via target `mail-to-root`
TASK OK
 
PVE has to start the VM to do the backups. If the start fails, the backup fails too.
In your case it is the missing CPU capabilities.
 
>It looks like PVE is a bit overzealous in checking VM CPU compatibility.

no, you simply have set your virtual cpu to x86-64-v3 and your host cpu won't support the requested features (AVX2 instruction set for example)
 
PVE has to start the VM to do the backups. If the start fails, the backup fails too.
In your case it is the missing CPU capabilities.
Yes, I am aware of the CPU limitations in this machine (i7-3770) and of the way the backup is performed - via QEMU, if I remember correctly.

What I am wondering about is whether, in such a situation, it would not be desirable for PVE to switching the CPU model to host or to some other value for the duration of the offline backup.
Are there any negative implications of such an approach?

In my case, changing the CPU setting in the VM was enough to resolve the issue, so technically, this is definitely possible.
 
>Are there any negative implications of such an approach?

complexity in backup code and chances that this accidentaly remains changed from the initial value on backup errors or other problems !?

it's seems a little bit uncommon to me, that you backup or restore VMs from / to hosts where you can't run them. may i ask why you are doing so for better undestanding ?
 
What I am wondering about is whether, in such a situation, it would not be desirable for PVE to switching the CPU model to host or to some other value for the duration of the offline backup.
Are there any negative implications of such an approach?
Proxmox allows you to start the VM while the backup is still running. This is not possible when the CPU type is changed automatically, or the VM would not run in the way you would expect from it's configuration.
Why would you set a VM to a CPU type that makes it impossible to run it? I fail to see practical use case. Maybe Proxmox should not allow you to select a CPU type that is not possible to run, instead? EDIT: You can add HA rules to prevent VMs to move to host that cannot run/backup it.
 
Last edited: