qemu-img decommit Probleme

Hallo in die Runde,

ich habe versucht einen Snapshot zu löschen, aber dieser Prozess zeigt im Webinterface dauerhaft 0% an (auch nach 12 Stunden). Laufen tut aktuell leider Version 4.0.0.219 (20230726).

Ich bin jetzt schon soweit, das ich den qemu-img decommit per ssh gestartet habe, aber auch hier passiert auf Dateiebene irgendwie nichts.

/usr/bin/qemu-img decommit -b /share/doArchive-Data/doArchive-Data-HDD.img -c /share/doArchive-Data/doArchive-Data-HDD.1699918204 --backup /share/doArchive-Data/.doArchive-Data-HDD.img.bk

Habe mittlerweile sogar den -p Parameter mit dran, dort kommt zumindest eine Prozentangabe (8.00/100%). Diese verändert sich aber nur sehr sehr sehr träge. Hab dem Prozess schon per renice die höchste Prio verliehen und auch per taskset alle CPUs erlaubt.

Die --backup /share/doArchive-Data/.doArchive-Data-HDD.img.bk - Datei wurde beim Start geschrieben und hat stolze 267 KB. Seitdem Funkstille.

/share/doArchive-Data/doArchive-Data-HDD.img ist 1.055 GB groß und die doArchive-Data-HDD.1699918204 nur 267 KB.

Hat jemand irgendeine Idee? Und was genau macht er dort und vor allem was da so lange dauert?

Redest du von dem Volumen wo die Image-Dateien liegen oder der .img-Datei selbst?

image: /share/doArchive-Data/doArchive-Data-HDD.img
file format: qcow2
virtual size: 4.72 TiB (5188320493568 bytes)
disk size: 507 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: false

der /share/doArchive-Data/ - 1.02 TB von 5.00 TB belegt

1.02 TB von 5.00 TB belegt

daran kann es "leider" auch nicht liegen.

Hab jetzt für heute Abend/Nacht geplant, alles herunterzufahren und rein dieses Prozess zu starten. Vorher noch aktuelles QuTS Hero und dann mal schauen.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Du nutzt QuTS Hero ?

Ja, auf der TS-h1277XU-RP.

Zitat von Becker2020

Freigabe ist nur 0,5 TB groß ?

Nein, 5 TB.

Es ist überall noch massig Platz.

Das ist die Info zur .img-Datei

SSH-Befehl: qemu-img info /share/doArchive-Data/doArchive-Data-HDD.img

image: /share/doArchive-Data/doArchive-Data-HDD.img
file format: qcow2
virtual size: 4.72 TiB (5188320493568 bytes)
disk size: 507 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

pasted-from-clipboard.png

Das Bild könnte dir weiterhelfen.

Es bringt jedoch nichts, in hatte die NAS die ganze Nacht wirklich auf Minimalbetrieb und habe nur den Prozess laufen lassen, es funktioniert nicht. Ich bekomme die Snapshots nicht gelöscht. Heute morgen war dann sogar die ganze VS aus bzw. hat nur bei Aufruf ERROR geschriehen.

Da die VM noch funktioniert, werde ich jetzt eine neue Identische VM aufsetzen lassen und die Inhalte "kopieren".

Danach gibt es absolutes Verbot bei uns diese Snapshot-Funktion zu nutzen; es gab damit nur Ärger. Zukünftig VM herunterfahren, IMG-Datei kopieren/backupen, verschlüsseln. Ende.

Beispielsweise bei Hetzner, welche für Ihre VPS ebenfalls auf qemu setzen, hatte ich solche Probleme noch nie.

Im QuLog-Center findest du absolut nichts.

Hier das Bild was ich heute morgen gesehen habe:

pasted-from-clipboard.png

Zitat

Was ist mit der HDD1 ?

108 GB belegt aber die HDD ist nur 80 GB groß

Ich denke das kommt dadurch, dass hier HDD1 + dessen Snapshot 1 und Snapshot 2 addiert werden.

Solange die Snapshots vorhanden sind, lässt er keine Vergrößerung zu. Henne-Ei-Problem.

Mod: Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Ich würde mal einen Neustart des NAS durchführen.

Seit gestern Abend, drei Stück. Keine positive Auswirkung auf den eigentlichen Prozess.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Xydoc

Das Problem besteht mit VS4 Beta?

Kann ich dir nicht sagen, ich bin zwangsgeupdated worden.

Also der Freigabeordner /vms hat 1.88 TB belegt von 3 TB ingesamt. Aber die anzeigte Größe der HDD hat mit der img-Datei und dessen Auslegung zu tun. HDD2 und HDD3 sind zusätzliche Festplatten.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Wenn Du HDD1 nicht vergrößern kannst, kannst Du denn den Freigabeordner /vms vergrößern ?

sehe /vms anhand der freien 1.12 TB kein Problem.

Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

Zitat von Becker2020

Wenn auch dies nicht zum Erfolg führt, würde ich mich an den QNAP-Support wenden.

Ich kann dir aus Erfahrung sagen, dass ist wirklich das letzte, was du tun möchtest. Ein QNAP-Servicemitarbeiter versucht dann über den lokalen QNAP Helpdesk eine SSH/-Webinterface-Freigabe zu erwirken. Diese Freigabe soll dann aber auch 24/7 geöffnet sein (Firewall), damit die taiwanischen Techniker in einer Nacht (Zeitzonenverschiebung) dann im Prinzip alles auf deinem System machen können.

Der letzte Fall ging so über 3 Monate, der beste Service ist der, den du nicht benötigst

/doArchive/ ist ein Ordner auf der /vms-Freigabe wo die HDD1 enthalten ist.