Snapshot Rollback not possible

K

katamadone

New Member
Jun 19, 2024
5
0
1
unfortunately veeam related, but:
VMs get locked after rollbacking a snapshot .
Code:
Code: 
qemu-img: Could not apply snapshot 'tt': Device has active dirty bitmaps

Looks like the source of the problem is veeam. This happens on all our proxmox vms which are backuped with veeam.
Doesn't matter if startet or not snapshot time, and if the snapshot was before or after the backup

The machine gets locked. qm unlock "vmid" and it starts at the last state.

so to problems here:
- how to prohibit that the error is produced (think this has to be done by veeam)
- how to clean the mess up
 
looks like veeam sets a bitmap but doesn't cleanup:
Code: 
/mnt/pve/v_pve_toolsitops_01/images/998# qemu-img info vm-998-disk-1.qcow2image: vm-998-disk-1.qcow2
file format: qcow2
virtual size: 32 GiB (34359738368 bytes)
disk size: 32.5 GiB
cluster_size: 65536
Snapshot list:
ID      TAG               VM_SIZE                DATE        VM_CLOCK     ICOUNT
1       tt                    0 B 2025-04-04 11:29:06  0000:04:11.247         --
2       ttt                   0 B 2025-04-04 11:29:28  0000:04:33.023         --
3       v_1                   0 B 2025-04-04 12:25:08  0000:48:47.248         --
4       v_tt                  0 B 2025-04-04 12:26:03  0000:49:41.750         --
5       v_tttt                0 B 2025-04-04 12:59:41  0000:18:42.659         --
6       explizit_shutdown      0 B 2025-04-04 13:01:11  0000:00:00.000          0
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
bitmaps:
[0]:
flags:
[0]: auto
name: VeeamTmp_1d8a15f8-5955-4a21-b79a-c26b33437c50_7ead2b90-9bb8-4f1e-be1a-9cc923ec2789
granularity: 65536
refcount bits: 16
corrupt: false
extended l2: false
Child node '/file':
filename: vm-998-disk-1.qcow2
protocol type: file
file length: 32.4 GiB (34758525440 bytes)
disk size: 32.5 GiB
solution
Code: 
qemu-img bitmap --remove vm-998-disk-1.qcow2  VeeamTmp_1d8a15f8-5955-4a21-b79a-c26b33437c50_7ead2b90-9bb8-4f1e-be1a-9cc923ec2789

maybe some from proxmox say something about how safe that is :)
 
to delete a veeam bitmap without being precise (wildcard isn't allowed):
use
Code: 
qemu-img info vm-100001-disk-0.qcow2 | grep -oP 'VeeamTmp_.+'

Variante 1
Code: 
f=vm-998-disk-1.qcow2 && qemu-img bitmap --remove "$f" "$(qemu-img info "$f" | grep -oP 'VeeamTmp_.+')"

Variante 2
Code: 
qemu-img bitmap --remove f=vm-998-disk-1.qcow2 && qemu-img bitmap --remove "$f" "$(qemu-img info "$f" | grep -oP 'VeeamTmp_.+')"

Variante 3
Code: 
#!/bin/bash

# Usage: ./remove-veeam-bitmap.sh vm-101-disk-0.qcow2 vm-102-disk-1.qcow2 ...

for disk in "$@"; do
  echo "Checking $disk ..."
 
  # Veeam-Bitmap suchen
  bitmap=$(qemu-img info "$disk" | grep -oP 'VeeamTmp_.+' | head -n1)
 
  if [[ -n "$bitmap" ]]; then
    echo "Removing bitmap '$bitmap' from $disk"
    qemu-img bitmap --remove "$disk" "$bitmap"
  else
    echo "No Veeam bitmap found in $disk"
  fi
done
 
Last edited:
Hello All,

Powering off the virtual machine (VM) will only be effective for non-qcow2 disk formats, as their dirty bitmaps are not persistent and will be cleared upon restart. This behavior is by design to utilize dirty bitmaps for incremental backups and snapshots.

Short Term Action:
  • Workaround:
    • For a single VM, Veeam can provide instructions to remove the bitmap per disk.
    • For multiple VMs, a script can be supplied.
Long Term Action: Veeam will investigate the source of this limitation (QEMU or PVE) and provide feedback, as bitmaps should not block rollback operations and need to be deleted during the rollback process.

Any additional suggestions or feedback you have on this topic would be welcomed. Please let us know your thoughts.

Thanks!
 
You must log in or register to reply here.
Top Bottom