QCOW2 LVM Migration auf Raw schlägt fehl

Feb 3, 2023
90
30
23
Hallo Proxmox Forum,

ein Kunde von uns verwendete das snapshot-as-volume-chain feature, welches aktuell noch in der technology preview ist.
Leider sind doch einige Probleme aufgetreten, weswegen wir die Festplatten zurück auf Raw formatieren möchten und das Feature anschließend deaktivieren.

Die Migration klappt bei den meisten VMs bzw. Laufwerken auch ohne Probleme. Bis auf bei einer VM, bei welcher das Laufwerk mal von 2TB auf 2,3TB erweitert worden ist.
Hier schlägt es direkt zu Beginn wie folgt fehl:

Code:
create full clone of drive scsi1 (Proxmox01:vm-133-disk-2.qcow2)
Rounding up size to full physical extent 2.30 TiB
Logical volume "vm-133-disk-8" created.
drive mirror is starting for drive-scsi1
mirror-scsi1: Cancelling block job
mirror-scsi1: Done.
Renamed "vm-133-disk-8" to "del-vm-133-disk-8" in volume group "99_Proxmox01"
TASK ERROR: storage migration failed: block job (mirror) error: mirror-scsi1: Source and target image have different sizes (io-status: ok)

Die Konvertierung findet Online statt, die VM muss laufen.

Die unterschiedlichen Größen kann ich mir ggf. erklären. Im Anhang mal ein qemu-img info der qcow2 Disk.

Mir fällt auf, dass die virtual size
virtual size: 2.3 TiB (2528876744192 bytes) => Ohne Metadaten
dem der VM entspricht.

1786973841739.png

Allerdings das Volume / die Datei größer ist:
file length: 2.3 TiB (2529265975296 bytes) => Mit Metadaten

Das sind vermutlich die Metadaten von qcow2, welche bei raw allerdings nicht notwendig sind.
Stimmt hier ggf. etwas beim vergleichen der Größe (Bytes) nicht?

Versionsauszug ebenfalls im Anhang. Die Versionen sind nicht die aktuellsten, aber gibt es hier ggf. bereits ein Bugzilla Report zu diesem Verhalten?

Vielen Dank schonmal!

Mit besten Grüßen,
Kevin
 

Attachments

Leider sind doch einige Probleme aufgetreten, weswegen wir die Festplatten zurück auf Raw formatieren möchten und das Feature anschließend deaktivieren.
Welche waren das?

Die unterschiedlichen Größen kann ich mir ggf. erklären. Im Anhang mal ein qemu-img info der qcow2 Disk.
Die Größe ist wirklich komisch, das ist eine ungerade Anzahl an 512 Byte Blöcken.
Hast du schon versucht das Image von Hand zu konvertieren? Zur Not würde das vielleicht auch gehen, sieht aber nach einem Bug aus.

Ich würde vorschlagen hier auch direkt ein Ticket im Support zu öffnen.
 
Welche waren das?
Unterschiedlich. Das aber wohl auffälligste waren korrupte VMs (Haben nach einem Neustart einfach nicht mehr gestartet).
Performanceprobleme etc.
Es gibt einfach noch zu viel zu beachten, weswegen wir generell von der Nutzung dieses Features noch abraten.
=> Deswegen ja auch Technology Preview

Blockbridge hat das alles sehr gut zusammengefasst:
https://kb.blockbridge.com/technote/proxmox-qcow-snapshots-on-lvm/index.html
https://kb.blockbridge.com/technote/proxmox-qemu-cache-none-qcow2/index.html

Wir versuchen das ganze einfach grad rückgängig zu machen. Was bei vielen VMs auch bereits problemlos geklappt hat.

Ein Supportticket ist leider nicht möglich, da der Kunde bisher nur eine Community Lizenz erworben hat.
Wir haben bereits ein Upgrade empfohlen. In der Zwischenzeit hoffen wir auf den Support der Community :)

=> Gerne erstelle ich hierfür einen Bugzilla Report, sobald die Ursache eindeutig geklärt ist. Sonst würde ich den Bugreport ja heimlich als Supportticket nutzen :)

Mit besten Grüßen,
Kevin
 
Hallo Proxmox Forum,

ein Kunde von uns verwendete das snapshot-as-volume-chain feature, welches aktuell noch in der technology preview ist.
Leider sind doch einige Probleme aufgetreten, weswegen wir die Festplatten zurück auf Raw formatieren möchten und das Feature anschließend deaktivieren.

Die Migration klappt bei den meisten VMs bzw. Laufwerken auch ohne Probleme. Bis auf bei einer VM, bei welcher das Laufwerk mal von 2TB auf 2,3TB erweitert worden ist.
Hier schlägt es direkt zu Beginn wie folgt fehl:

Code:
create full clone of drive scsi1 (Proxmox01:vm-133-disk-2.qcow2)
Rounding up size to full physical extent 2.30 TiB
Logical volume "vm-133-disk-8" created.
drive mirror is starting for drive-scsi1
mirror-scsi1: Cancelling block job
mirror-scsi1: Done.
Renamed "vm-133-disk-8" to "del-vm-133-disk-8" in volume group "99_Proxmox01"
TASK ERROR: storage migration failed: block job (mirror) error: mirror-scsi1: Source and target image have different sizes (io-status: ok)

Die Konvertierung findet Online statt, die VM muss laufen.

Die unterschiedlichen Größen kann ich mir ggf. erklären. Im Anhang mal ein qemu-img info der qcow2 Disk.

Mir fällt auf, dass die virtual size
virtual size: 2.3 TiB (2528876744192 bytes) => Ohne Metadaten
dem der VM entspricht.

View attachment 99474

Allerdings das Volume / die Datei größer ist:
file length: 2.3 TiB (2529265975296 bytes) => Mit Metadaten

Das sind vermutlich die Metadaten von qcow2, welche bei raw allerdings nicht notwendig sind.
Stimmt hier ggf. etwas beim vergleichen der Größe (Bytes) nicht?

Versionsauszug ebenfalls im Anhang. Die Versionen sind nicht die aktuellsten, aber gibt es hier ggf. bereits ein Bugzilla Report zu diesem Verhalten?

Vielen Dank schonmal!

Mit besten Grüßen,
Kevin
Hi das ist ein bekanntes Problem. Erweitere die Disk auf 2,5TB oder auf 3 TB, dann klappt das wieder mit LVM RAW.
 
  • Like
Reactions: fiona
@Falk R. @fiona Vielen Dank! Das hat es gelöst :)
Keine Ahnung wie es zustande gekommen ist... Laut Kunde wurde immer nur über die GUI erweitert, da sollte das ja nicht auftreten?

Falls andere darauf stoßen, so haben wir es gemacht:

Aktuelle Größe: 2 411 724,8 MiB (Bytes: 2528876744192 / 1048576)
Ziel, auf den nächsten 4MiB Block: 2 411 728 MiB (Bytes 2528880099328)

Danach: qm resize 133 scsi1 2411728M

Gruß,
Kevin
 
Last edited:
@Falk R. @fiona Vielen Dank! Das hat es gelöst :)
Keine Ahnung wie es zustande gekommen ist... Laut Kunde wurde immer nur über die GUI erweitert, da sollte das ja nicht auftreten?

Falls andere darauf stoßen, so haben wir es gemacht:

Aktuelle Größe: 2 411 724,8 MiB (Bytes: 2528876744192 / 1048576)
Ziel, auf den nächsten 4MiB Block: 2 411 728 MiB (Bytes 2528880099328)

Danach: qm resize 133 scsi1 2411728M

Gruß,
Kevin
Je nachdem auf welchem Storagetypen du die VM Disk hast, gibt es verschiedene Block Sizes. Manche Storagetypen nutzen z.B. 1MB andere 4MB. Wenn du auf einem mit 1MB erweiterst, wird das Alignment auf 1MB genau gemacht, kann aber wenn du z.B. von 2 TB auf 2,1 TB erweiterst ein krummer Wert entstehen. Frag mich nicht warum, da eigentlich 100GB immer ein vielfaches von beiden Größen sein sollte. Meine Erfahrung aus ganz vielen Migrationen, wenn du nur glatte TB und ,5 benutzt sind die Werte immer sauber glatt.
Am häufigsten habe ich das Problem wenn ich von VMware migriere, da dort viele VMDK krumme Werte haben und ich diese oft erst einmal vergrößern muss, damit die Migration sauber läuft.