Bug Report: Proxmox Allows Creation of RAW Disks Larger Than Available Storage Space

[liasuaren]

Environment

• Proxmox Version: proxmox-ve: 8.4.0 (running kernel: 6.8.12-11-pve) (more in bottom)
• Storage Type: Directory (ext4)
• Storage Path: /mnt/pve/Storage
• Filesystem: ext4 on /dev/sda1

Problem Description
Proxmox allowed me to create a 1910 GB virtual RAW disk on a Directory storage that only has ~1.97 TB total capacity, resulting in filesystem corruption and io-errors.

Steps to Reproduce

1. Created a Directory storage backed by a 1.97 TB ext4 filesystem (/dev/sda1)
2. Storage configuration in /etc/pve/storage.cfg:

   dir: Storagepath /mnt/pve/Storage content snippets,vztmpl,iso,rootdir,images,backupis_mountpoint 1nodes proxmox

3. Successfully created a 1910 GB RAW disk via Proxmox web interface
4. VM shows disk as 1910 GB in Hardware settings
5. But actual storage consumption shows 2.05 TB in Disks menu

Current State

root@proxmox:~# lsblk -f
NAME    FSTYPE     FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda1        ext4       1.0                a1b2c3d4-e5f6-7890-abcd-123456789abc       0   100% /mnt/pve/Storage

root@proxmox:~# df -h /mnt/pve/Storage
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       1.9T  1.9T     0 100% /mnt/pve/Storage

root@proxmox:~# tune2fs -l /dev/sda1 | grep "Block count|Free blocks|Reserved block count"
Block count: 488378385
Reserved block count:  0
Free blocks: 4096

Issues Identified

1. Size Reporting Inconsistency

• VM Hardware tab shows: 1910 GB
• Proxmox Disks menu shows: 2.05 TB actual usage
• Host filesystem shows: 100% full (1.9T used of 1.9T)

2. No Storage Space ValidationProxmox allowed creation of a 1910 GB (1.91 TB) RAW disk on a 1.97 TB filesystem without:

• Warning about insufficient space
• Accounting for filesystem overhead
• Preventing creation when space is inadequate

3. VM Becomes Unusable with Filesystem Corruption

• Any write operation in VM causes io-error status
• Running e2fsck and resize2fs (to shrink) inside VM triggers io-errors on host
• VM shows filesystem corruption errors even before login

VM Console Output (without login, after boot):

[    9.375924] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 8655: bad block bitmap checksum
[    9.430851] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 8747: bad block bitmap checksum
[    9.430957] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 8909: bad block bitmap checksum
[    9.512531] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 9216: bad block bitmap checksum
[    9.552399] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 9529: bad block bitmap checksum
[    9.564500] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 10080: bad block bitmap checksum
[    9.568075] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 10115: bad block bitmap checksum
[   10.362075] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 13914: bad block bitmap checksum
[   10.419685] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 14253: bad block bitmap checksum
[   10.446624] EXT4-fs error (device vda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 14427: bad block bitmap checksum

No relevant errors found in dmesg or journalctl on Proxmox host or in VM logs.
No clear indication of the root cause in host logs

Thank you everyone in advance. In case I missed to attach something please tell me, thats my first time posting here.

root@proxmox:~# pveversion -v
proxmox-ve: 8.4.0 (running kernel: 6.8.12-11-pve)
pve-manager: 8.4.5 (running version: 8.4.5/57892e8e686cb35b)
proxmox-kernel-helper: 8.1.1
proxmox-kernel-6.8.12-12-pve-signed: 6.8.12-12
proxmox-kernel-6.8: 6.8.12-12
proxmox-kernel-6.8.12-11-pve-signed: 6.8.12-11
proxmox-kernel-6.8.12-10-pve-signed: 6.8.12-10
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
ceph-fuse: 17.2.7-pve3
corosync: 3.1.9-pve1
criu: 3.17.1-2+deb12u1
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.30-pve2
libproxmox-acme-perl: 1.6.0
libproxmox-backup-qemu0: 1.5.2
libproxmox-rs-perl: 0.3.5
libpve-access-control: 8.2.2
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.1.2
libpve-cluster-perl: 8.1.2
libpve-common-perl: 8.3.2
libpve-guest-common-perl: 5.2.2
libpve-http-server-perl: 5.2.2
libpve-network-perl: 0.11.2
libpve-rs-perl: 0.9.4
libpve-storage-perl: 8.3.6
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.6.0-2
proxmox-backup-client: 3.4.3-1
proxmox-backup-file-restore: 3.4.3-1
proxmox-backup-restore-image: 0.7.0
proxmox-firewall: 0.7.1
proxmox-kernel-helper: 8.1.1
proxmox-mail-forward: 0.3.3
proxmox-mini-journalreader: 1.5
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.3.12
pve-cluster: 8.1.2
pve-container: 5.2.7
pve-docs: 8.4.0
pve-edk2-firmware: 4.2025.02-4~bpo12+1
pve-esxi-import-tools: 0.7.4
pve-firewall: 5.1.2
pve-firmware: 3.16-3
pve-ha-manager: 4.0.7
pve-i18n: 3.4.5
pve-qemu-kvm: 9.2.0-7
pve-xtermjs: 5.5.0-2
qemu-server: 8.4.1
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.8-pve1

 

[Johannes S]

Hi,

thanks forvthe writeup. Did you also file the bug report on on bugzilla.proxmox.com? It mightvget overlooked otherwise

Best regards

 

[liasuaren]

Hi,

thanks forvthe writeup. Did you also file the bug report on on bugzilla.proxmox.com? It mightvget overlooked otherwise

Best regards

Thank you Johannes for taking attention to my issue! Is there any other ways I can gather more data before posting to Bugzilla? Journalctl and dmesg aren't quite mouthful about that issue, wonder if there are other ways to debug and investigate the case?

BR

 

[fba]

1910 GiB × 1.073741824 = 2051.9 GB = 2.05 TB
Seems like there is a difference in used units between disk creation and disk utilization.

 

[liasuaren]

1910 GiB × 1.073741824 = 2051.9 GB = 2.05 TB
Seems like there is a difference in used units between disk creation and disk utilization.

I think so too, i'll add it to bugzilla

 

[Johannes S]

Thank you Johannes for taking attention to my issue! Is there any other ways I can gather more data before posting to Bugzilla? Journalctl and dmesg aren't quite mouthful about that issue, wonder if there are other ways to debug and investigate the case?

No idea, sorry but even an incomplete bug report is better than none. If the developers need more information I'm sure they will let you know then

Regards, Johannes.