Dirty bitmap becomes invalid, after storage migration.

[Dark26]

Bonjour,

Can you confirm that the dirty bitmap is always clear after a storage move for a VM hard drive, even if the VM is still running with no reboot?

So if we change the storage, we have to re-read oall the data for the backup with PBS ?

Thanks.

 

[Jackobli]

That would be another case as already mentioned here:

Thread 'Backup to PBS very long due to missing dirty bitmap'

Feb 20, 2025

Hi guys
I know there are many threads about, but I haven't found the right one who explains my question perhaps.
How is the behavior or where do I find the documentation of PVE for handling the "dirty blocks bitmap" for doing incremental backups?
We know:

• If a VM has been stopped, the Bitmap is deleted
• But there must be other cases…

Yesterday one of my VM suddenly had it lost and says:
scsi0: dirty-bitmap status: created new
Sometimes we also see "scsi0: dirty-bitmap status: invalid created new"
These VM hadn't been stopped. Also a migration usually keeps the bitmap.

Usually...

• Jackobli
• Replies: 4
• Forum: Proxmox VE: Installation and configuration

I will open a case because we are loosing bitmaps randomly on large vms what makes backups very unpredictable.
Keep you updated if there are more situations.

Regards, Urs

 

[Jackobli]

Bonjour,

Can you confirm that the dirty bitmap is always clear after a storage move for a VM hard drive, even if the VM is still running with no reboot?

So if we change the storage, we have to re-read oall the data for the backup with PBS ?

Thanks.

Hi again / Bonsoir

Maximilio from the Support Team writes

So this means, that a «storage move» (like from one ceph pool to another or from ceph to local or nfs) would kill the bitmap?

My current understanding is that, yes, the bitmap could be potentially dropped if the live-migration involves a storage migration from one kind of storage to another, or if the the storages are configured differently. For example if it is a local zfs storage on each node but they have different zfs/zpool properties on both sides (See the manual pages `man zfsprops` and `man zpoolprops`). Different storages could lead to the target disk image being allocated an ever-so-slightly bigger size than the source disk image's (e.g. if the target storage has a bigger granularity and the disk image size is not aligned to it). The bitmap keeps track of whether each block in the guest has seen changes, if a migration results in the disk image having a different number of blocks, then I can imagine it being invalid and discarded.

We also found, that changing the disk size (Disk Action --> Resize) will lead to a loss of the dirty bitmap table (or the later manipulation of the partition table perhaps).

Regards, Urs