Problem vergrößern von QCOW Disk

EWS IT

EWS IT

New Member
Proxmox Subscriber
Feb 18, 2025
7
0
1
ews-consulting.com
Hallo,

Leider beginnt mein erster Thread gleich mit einer etwas prekären Situation:

Wir betreiben eine 4 Node Proxmox Cluster mit NFS Storage seit Monaten mit Veeam back ohne Probleme.

Leider hakts nun etwas beim Vergrößern eine Disk am Main Fileserver.

Ich möchte die Disk von 12 auf 14 TB vergrößern ( Via GUI, bekomme jedoch folgende Meldung:

TASK ERROR: VM 201 qmp command 'block_resize' failed - Bitmap 'VeeamTmp_717a90ed-a864-4d89-a137-a0657c012ca0_182684f3-de86-435d-9013-cb4f65975d97' is inconsistent and cannot be used

Der Server hat keinerlei Snapshots, die Storage ausreichend Platz , und auch sonnst habe ich keinerlei Themen.

P.S.

Wie läuft das eigentlich mit dem Premium Support, da wir alles durchlizenziert haben ?

mfg
 
EWS IT said:
TASK ERROR: VM 201 qmp command 'block_resize' failed - Bitmap 'VeeamTmp_717a90ed-a864-4d89-a137-a0657c012ca0_182684f3-de86-435d-9013-cb4f65975d97' is inconsistent and cannot be used
Click to expand...
Hmm... das sieht so aus als hätte Veeam da einen Prozess nicht sauber beendet und ne kaputte dirty bitmap hinterlassen? Nur so als Idee...

Was bekommst denn hier für einen Output:
Code: 
qemu-img info /pfad/zu_deinem/qcow2-image

Wie läuft das eigentlich mit dem Premium Support, da wir alles durchlizenziert haben ?
Click to expand...
Ganz einfach, hier einen Account erstellen und ein Ticket eröffnen: https://my.proxmox.com/en
 
  • Like
Reactions: Johannes S and fiona
Hallo, Danke für die Antwort.

Ich bekomme folgende Ausgabe:

root@smufprox02:/mnt/pve/smufstor01/images/201# qemu-img info vm-201-disk-1.qcow2
image: vm-201-disk-1.qcow2
file format: qcow2
virtual size: 12 TiB (13194139533312 bytes)
disk size: 12 TiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
bitmaps:
[0]:
flags:
[0]: in-use
[1]: auto
name: VeeamTmp_717a90ed-a864-4d89-a137-a0657c012ca0_182684f3-de86-435d-9013-cb4f65975d97
granularity: 65536
refcount bits: 16
corrupt: false
extended l2: false
Child node '/file':
filename: vm-201-disk-1.qcow2
protocol type: file
file length: 12 TiB (13194656023040 bytes)
disk size: 12 TiB
 
Auf was für einem Filesystem liegt denn die Datei?
Je nach Blocksize haben Filesysteme ganz unterschiedliche maximale Dateigrößen.
 
Wir haben im Hintergrund eine Synology RS2821RP+ mit einem raid 6 (SSD) laufen , auf welcher ein btrfs Volume (42 TB) eingerichtet ist.
jenes wird dann via NFS und eigenen Netzwerkadaptern (25 Gbit LACP) an die 4 Proxmox Hosts bereitgestellt.

Das Filesystem des Windows Server ist NTFS.

Auf der Proxmox seite sind die Virtuellen Laufwerke im qcow Format angelegt:
1740065164474.png

1740065011009.png
 
Last edited:
EWS IT said:
Wir haben im Hintergrund eine Synology RS2821RP+ mit einem raid 6 (SSD) laufen , auf welcher ein btrfs Volume (42 TB) eingerichtet ist.
Click to expand...
NFS auf BTRFS hat ein Limit von 16TB. Wie groß sollte denn die datei werden?
 
EWS IT said:
Maximal 14 TB
Click to expand...
Theoretisch sollte das gehen. Aber da du eh schon "kurz" vor dem echten Limit bist, sollte man da nicht für die Zukunft schon mal einen anderen Weg suchen? So große Dateien zu Restoren kann auch unschön werden, manchmal ist es schöner die Daten auf 3x 10TB Disk aufzuteilen statt auf eine 20TB Disk.
 
  • Like
Reactions: Johannes S
Hallo, da wir uns in einem Migrationsprozess befinden, ist diese Größe derzeit notwendig.
Ist auch nicht weiter bedenklich , da die Zuwachsrate eher gering ist.

Ich selbst mache Datacenter in allen Ausprägungen seit ca. 20 Jahren. Leider ist Proxmox mit Veeam sehr neu, weshalb es mir eigentlich nur darum
geht möglichst Gefahrlos diese "dirty Bitmap" wieder zu bereinigen, um diese in die Datenstruktur in Ruhe zu migrieren.
 
Also die Dirty Bitmap wird bei jedem Hypervisor immer verworfen, wenn man eine Disk vergrößert.
Hast du mal versucht in kleineren Schritten zu vergrößern?
Eigentlich sollte 16TB gehen, daher bin ich auch etwas gespannt.
 
  • Like
Reactions: Johannes S
EWS IT said:
Hallo, da wir uns in einem Migrationsprozess befinden, ist diese Größe derzeit notwendig.
Ist auch nicht weiter bedenklich , da die Zuwachsrate eher gering ist
Click to expand...

Falls das "nur" temporär genutzt wird, könnte man auch eine 2. Platte erzeugen und diese dann mittels subst als Verzeichnis in einen bestehendes Laufwerk einbinden. - Nur ein Gedankenansatz.
 
Interessant finde ich, dass netapp erst in aktuellen Versionen eine file size von 128TB unterstützt. (Vorher 16TB)
 
Hi,
es gäbe ein block-dirty-bitmap-remove QMP Kommando. Aber da die Bitmap von Veeam erstellt wurde, bitte wende Dich an Veeam. Ohne die präzisen Details zu kennen, wie die Bitmap benutzt wird, kann ich Dir nicht sagen, ob es okay ist die Bitmap zu löschen bzw. was zu tun ist.
 
  • Like
Reactions: Johannes S, Falk R. and fireon
EWS IT said:
Danke für die Info, Ja ich weiß das die Bitmap von Veeam ist, jedoch wurde diese aufgrund eines Strom / USV Fehlers stehengelassen.
(Passiert so sicher kein 2.Mal).
Wie wurde dieses Kommando in proxmox aussehen ?
Click to expand...
Da Veeam nicht Open Source ist, wissen wir nicht genau was Veeam da im Hintergrund noch tut. Am besten ein Ticket beim Veeam Support aufmachen, die helfen auch schnell.
 
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom