[SOLVED] Backup vm failed after upgrade to new version

[chineseswish]

Yesterday,I upgrade my pve to new version,Backup job is failed with follow log:

INFO: starting new backup job: vzdump 118 --storage local --notes-template '{{guestname}}' --mode snapshot --remove 0 --node pve8 --compress zstd --notification-mode auto
INFO: Starting Backup of VM 118 (qemu)
INFO: Backup started at 2024-12-12 08:59:54
INFO: status = running
INFO: VM Name: demos-win11
INFO: include disk 'scsi0' 'Raid5:vm-118-disk-0' 64G
INFO: include disk 'efidisk0' 'local:110/base-110-disk-0.qcow2/118/vm-118-disk-0.qcow2' 528K
INFO: include disk 'tpmstate0' 'local:110/base-110-disk-1.raw/118/vm-118-disk-1.qcow2' 16896
ERROR: Backup of VM 118 failed - cannot determine size of volume 'local:110/base-110-disk-1.raw/118/vm-118-disk-1.qcow2' - qemu-img: Could not open '/var/lib/vz/images/118/vm-118-disk-1.qcow2': Image is not in qcow2 format
INFO: Failed at 2024-12-12 08:59:54
INFO: Backup job finished with errors
TASK ERROR: job errors

 

[fabian]

could you post the VM config please? this looks broken, as swtpm doesn't understand qcow2 files..

 

[chineseswish]

could you post the VM config please? this looks broken, as swtpm doesn't understand qcow2 files..

vm 118 config:

agent: 1
bios: ovmf
boot: order=scsi0;ide0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
efidisk0: local:110/base-110-disk-0.qcow2/118/vm-118-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide0: local:iso/virtio-win.iso,media=cdrom,size=708140K
ide2: local:iso/zh-cn_windows_11_consumer_editions_version_23h2_updated_sep_2024_x64_dvd_edcefbe4.iso,media=cdrom,size=7015542K
machine: pc-q35-9.0
memory: 4096
meta: creation-qemu=9.0.2,ctime=1727441939
name: demos-win11
net0: virtio=BC:24:11:73:70:CE,bridge=demos,firewall=1
numa: 0
ostype: win11
scsi0: Raid5:vm-118-disk-0,iothread=1,size=64G
scsihw: virtio-scsi-single
smbios1: uuid=09b26ef4-2fb0-4e1b-939d-7ccf456ffd10
sockets: 2
tpmstate0: local:110/base-110-disk-1.raw/118/vm-118-disk-1.qcow2,size=16896,version=v2.0
vga: virtio
vmgenid: 3f5bc2d3-c8e1-4b3f-98d9-ff588d9b4c5a

template 110 config:

agent: 1
bios: ovmf
boot: order=scsi0;ide0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
efidisk0: local:110/base-110-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide0: local:iso/virtio-win.iso,media=cdrom,size=708140K
ide2: local:iso/zh-cn_windows_11_consumer_editions_version_23h2_updated_sep_2024_x64_dvd_edcefbe4.iso,media=cdrom,size=7015542K
machine: pc-q35-9.0
memory: 4096
meta: creation-qemu=9.0.2,ctime=1727441939
name: template-win-11
net0: virtio=BC:24:11:CF:C4:01,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsi0: Raid5:base-110-disk-0,iothread=1,size=64G
scsihw: virtio-scsi-single
smbios1: uuid=5d44eddd-c523-4c61-92c8-cebe83e12697
sockets: 2
template: 1
tpmstate0: local:110/base-110-disk-1.raw,size=4M,version=v2.0
vga: virtio
vmgenid: 230f4c98-5d97-417d-8de3-4ad4c35dd1fd

 

[fabian]

could you post the output of

"qemu-img info --ouptut-format json $(pvesm path local:110/base-110-disk-1.raw/118/vm-118-disk-1.qcow2)"

?

 

[chineseswish]

could you post the output of

"qemu-img info --ouptut-format json $(pvesm path local:110/base-110-disk-1.raw/118/vm-118-disk-1.qcow2)"

?

root@pve8:~# qemu-img info $(pvesm path local:110/base-110-disk-1.raw/118/vm-118-disk-1.qcow2)
image: /var/lib/vz/images/118/vm-118-disk-1.qcow2
file format: raw
virtual size: 16.5 KiB (16896 bytes)
disk size: 12 KiB
Child node '/file':
    filename: /var/lib/vz/images/118/vm-118-disk-1.qcow2
    protocol type: file
    file length: 16.5 KiB (16896 bytes)
    disk size: 12 KiB

 

[fabian]

you need to rename the file on the storage to .raw instead of .qcow2, and adapt the volume ID in the config in the same fashion.. I'll see if I can reproduce this issue..

 

[chineseswish]

you need to rename the file on the storage to .raw instead of .qcow2, and adapt the volume ID in the config in the same fashion.. I'll see if I can reproduce this issue..

I rename file and tpmstat0 device missed.I manual remove tpmstat0 and add a new tpm 2.0 device to fixup.

 

[fabian]

FWIW: https://lore.proxmox.com/pve-devel/20241212085149.138679-1-f.gruenbichler@proxmox.com/T/#t and https://lore.proxmox.com/pve-devel/20241212095400.218654-1-f.gruenbichler@proxmox.com/T/#u should prevent the issue from happening again once they are applied and released.

 

[chineseswish]

Yes!

FWIW: https://lore.proxmox.com/pve-devel/20241212085149.138679-1-f.gruenbichler@proxmox.com/T/#t and https://lore.proxmox.com/pve-devel/20241212095400.218654-1-f.gruenbichler@proxmox.com/T/#u should prevent the issue from happening again once they are applied and released.