Hypervisor storage (RAID-Z2) voll gelaufen - Löschen von VMs / Snapshots nicht mehr möglich

[r4dh4l]

Hallo,

beim Sichern von Daten einer Seafile-VM ist mir wahrscheinlich durch das Anlegen von Temp-Files durch den Seafile-Kommandozeilen-Client auf dieser VM unbemerkt das RAID-Z2 des Hypervisors vollgelaufen: Load des Hypervisors schoss plötzlich auf 30er Werte und dann war keine VM mehr zu erreichen.

Unter den Versuchen, Platz zu gewinnen, gelang nur das Entfernen von OS images über Datacenter -> <Hypervisor> -> local.

Versuche, Snapshots zu löschen, scheitern aktuell mit der Fehlermeldung "Input/output error":

root@proxmox:~# qm listsnapshot 102
`-> d20180814_postcloning_ante  2018-08-14 17:10:51     Before starting with post cloning procedure
    `-> d20180818_postcloning_post 2018-08-18 19:20:11     Post cloning procedure complete
        `-> current                                     You are here!
root@proxmox:~# qm delsnapshot 102 d20180818_postcloning_post
unable to open file '/etc/pve/nodes/proxmox/qemu-server/102.conf.tmp.28052' - Input/output error
root@proxmox:~#

Versuche, den VM-Schreibschutz zu entfernen, um VMs zu löschen, scheitern mit der selben Fehlermeldung:

root@proxmox:~# qm set 102 --protection 0
update VM 102: -protection 0
unable to open file '/etc/pve/nodes/proxmox/qemu-server/102.conf.tmp.28787' - Input/output error
root@proxmox:~#

Da ich keine der noch laufenden, aber nichtmal mehr per SSH erreichbaren VMs via "qm shutdown" herunterfahren konnte, habe ich mit "qm stop" den virtuellen Netzstecker gezogen. Von einem Neustart des Hypervisors habe ich abgesehen, da ich nicht riskieren wollte, den noch vorhandenen SSH-Zugang zu verlieren.

Meine Proxmox-Version ist:

root@proxmox:~# pveversion
pve-manager/5.4-13/aee6f0ec (running kernel: 4.15.18-20-pve)
root@proxmox:~#

Zpool status:

root@proxmox:~# zpool status
  pool: rpool
state: ONLINE
  scan: scrub repaired 0B in 49h24m with 0 errors on Tue Sep 10 01:48:48 2019
config:

        NAME                              STATE     READ WRITE CKSUM
        rpool                             ONLINE       0     0     0
          raidz2-0                        ONLINE       0     0     0
            wwn-0x50014ee0aeffd2a3-part2  ONLINE       0     0     0
            wwn-0x50014ee20a994052-part2  ONLINE       0     0     0
            wwn-0x50014ee2b8e68c1d-part2  ONLINE       0     0     0
            wwn-0x50014ee2ba1acc4e-part2  ONLINE       0     0     0

errors: No known data errors
root@proxmox:~#

Aktueller "Füllstand":

root@proxmox:~# df -h
Filesystem        Size  Used Avail Use% Mounted on
udev              7.6G     0  7.6G   0% /dev
tmpfs             1.6G   56M  1.5G   4% /run
rpool/ROOT/pve-1  6.2G  5.7G  474M  93% /
tmpfs             7.6G   40M  7.6G   1% /dev/shm
tmpfs             5.0M     0  5.0M   0% /run/lock
tmpfs             7.6G     0  7.6G   0% /sys/fs/cgroup
rpool             474M  128K  474M   1% /rpool
rpool/ROOT        474M  128K  474M   1% /rpool/ROOT
rpool/data        474M  128K  474M   1% /rpool/data
tmpfs             1.6G     0  1.6G   0% /run/user/1001
/dev/fuse          30M   68K   30M   1% /etc/pve
root@proxmox:~#

Mein Plan wäre jetzt gewesen, eine alte VM zu löschen, damit Platz für Temp-Files ist, die Dateien unter "/etc/pve/nodes/proxmox/qemu-server/" ändern zu können, um schließlich die Seafile-VM starten zu können und dort die besagten Temp-Files zu entfernen. Das geht jedoch nicht, da dort noch das ursprüngliche Installations-Medium als ISO eingebunden ist, was ich im oben zuerst genannten Schritt gelöscht habe, weswegen der VM-Start nicht möglich ist:

root@proxmox:~# qm start 101
volume 'local:iso/debian-9.3.0-amd64-netinst.iso' does not exist
root@proxmox:~#

Was kann ich tun, um (sofern das sinnvoll ist) die erwähnte VM mit der ID 102 zu löschen?

Danke im Voraus!

 

[LnxBil]

root@proxmox:~# qm set 102 --protection 0 update VM 102: -protection 0 unable to open file '/etc/pve/nodes/proxmox/qemu-server/102.conf.tmp.28787' - Input/output error root@proxmox:~#

Das sieht so aus als gäb es ein Problem mit dem PVE ClusterDateisystem in /etc/pve und das verursacht all deine Probleme. Das liegt wohl daran, dass Änderungen an der zugrundenden SQLite Datenbank wegen des Dateischreibproblems nicht korrekte geschrieben wurde und jetzt irgendwie kaputt ist. Daher kannst du auch keine VM löschen. Ich habe mit genau dem Problem zu wenig Erfahrung (bisher noch nie gehabt) und kann daher nur mutmaßen, wie man es beheben könnte. Reboot wäre natürlich die harte Methode, ggf. reicht auch schon ein Neustart des Dienstes pve-cluster.service mittels

systemctl restart pve-cluster.service

 

[r4dh4l]

Das sieht so aus als gäb es ein Problem mit dem PVE ClusterDateisystem in /etc/pve und das verursacht all deine Probleme. Das liegt wohl daran, dass Änderungen an der zugrundenden SQLite Datenbank wegen des Dateischreibproblems nicht korrekte geschrieben wurde und jetzt irgendwie kaputt ist. Daher kannst du auch keine VM löschen. Ich habe mit genau dem Problem zu wenig Erfahrung (bisher noch nie gehabt) und kann daher nur mutmaßen, wie man es beheben könnte. Reboot wäre natürlich die harte Methode, ggf. reicht auch schon ein Neustart des Dienstes pve-cluster.service mittels

systemctl restart pve-cluster.service

Ehrlich gesagt traue ich mich nicht, einen Dienst neu zu starten, wenn der Speicher des Hypervisors randvoll ist. Ich kann es nicht begründen, würde aber meinen, dass das keine gute Idee ist.

Zunächst kam mir die Idee, die problemverursachende VM dadurch zu starten, dass ich das OS-Installations-Image, was in ihrer Config eingetragen und damit Startvoraussetzung ist und das ich als eine der ersten Aktionen gelöscht hatte, neu auf den Hypervisor zu laden. Das gelang jedoch nicht (Image wurde zwar hochgeladen, verschwand dann allerdings in der Ansicht des Webinterfaces).

Im eher verzweifelten Versuch, Speicher freizugeben, damit ich die VM-Config der problemverursachenden VM so korrigieren kann, dass ich sie starten kann, habe ich mit Hilfe eines erfahrenen Admins, der jedoch Proxmox und ZFS bisher nicht verwendet, unschön, aber wie gesagt verzweifelt, unter Zuhilfenahme der Ausgaben von "zfs list" und "zfs list -H -o name -t snapshot" den Befehl "zfs destroy" verwendet, um verzichtbare VMs zu löschen:

root@proxmox:/# zfs list
NAME                                                    USED  AVAIL  REFER  MOUNTPOINT
rpool                                                  5.10T   474M   140K  /rpool
rpool/ROOT                                             5.66G   474M   140K  /rpool/ROOT
rpool/ROOT/pve-1                                       5.66G   474M  5.66G  /
rpool/data                                             5.09T   474M   140K  /rpool/data
...
rpool/data/vm-102-disk-1                               9.54G   474M  6.09G  -
rpool/data/vm-102-state-d20180818_postcloning_post      353M   474M   353M  -
...
rpool/data/vm-111-disk-0                               6.43G   474M  6.22G  -
...
rpool/swap                                             9.08G   474M  9.08G  -
root@proxmox:~# zfs list -H -o name -t snapshot
...
rpool/data/vm-111-disk-0@d20190707_postcloning_ante
rpool/data/vm-111-disk-0@postcloning_post
...
root@proxmox:~# history | grep destroy
  650  zfs destroy rpool/data/vm-102-disk-1@d20180814_postcloning_ante 
  653  zfs destroy rpool/data/vm-102-disk-1@d20180818_postcloning_post 
  655  zfs destroy rpool/data/vm-102-disk-1 
  658  zfs destroy rpool/data/vm-111-disk-0@postcloning_post
  659  zfs destroy rpool/data/vm-111-disk-0@d20190707_postcloning_ante
  660  zfs destroy rpool/data/vm-111-disk-0
  663  history | grep destroy
root@proxmox:~#

Das brachte mir laut Proxmox-Webinterface für local-zfs eine Änderung der "Usage"-Angabe von 99% auf "99.68% (5.07 TiB of 5.09 TiB)".

Im Vergleich zur im Start-Post angegebenen df-Ausgabe, also

root@proxmox:~# df -h
Filesystem        Size  Used Avail Use% Mounted on
udev              7.6G     0  7.6G   0% /dev
tmpfs             1.6G   56M  1.5G   4% /run
rpool/ROOT/pve-1  6.2G  5.7G  474M  93% /
tmpfs             7.6G   40M  7.6G   1% /dev/shm
tmpfs             5.0M     0  5.0M   0% /run/lock
tmpfs             7.6G     0  7.6G   0% /sys/fs/cgroup
rpool             474M  128K  474M   1% /rpool
rpool/ROOT        474M  128K  474M   1% /rpool/ROOT
rpool/data        474M  128K  474M   1% /rpool/data
tmpfs             1.6G     0  1.6G   0% /run/user/1001
/dev/fuse          30M   68K   30M   1% /etc/pve
root@proxmox:~#

hat sich diese wie folgt geändert:

root@proxmox:~# df -h

Filesystem        Size  Used Avail Use% Mounted on
udev              7.6G     0  7.6G   0% /dev
tmpfs             1.6G   76M  1.5G   5% /run
rpool/ROOT/pve-1   23G  5.7G   17G  26% /
tmpfs             7.6G   43M  7.6G   1% /dev/shm
tmpfs             5.0M     0  5.0M   0% /run/lock
tmpfs             7.6G     0  7.6G   0% /sys/fs/cgroup
rpool              17G  256K   17G   1% /rpool
rpool/ROOT         17G  256K   17G   1% /rpool/ROOT
rpool/data         17G  256K   17G   1% /rpool/data
tmpfs             1.6G     0  1.6G   0% /run/user/1001
/dev/fuse          30M   68K   30M   1% /etc/pve
root@proxmox:~# date
Sun Oct  6 14:45:24 CEST 2019
root@proxmox:~#

Das Problem, nicht in mehr in VM-Configs schreiben zu können, löste sich dadurch allerdings trotzdem nicht.

Obwohl "local" und "local-zfs" ja eigentlich nichts miteinander zu tun haben, konnte ich nun jedoch das zum Start der problemverursachenden VM nötige OS-Installationsimage über das Proxmox-Webinterface neu hochladen, die besagte VM endlich starten und dort die Temp-Files löschen, die das RAID "geflutet" hatten.

Obwohl durch die "zfs destroy"-Aktionen ein etwas mulmiges Gefühl hatte, habe ich den Hypervisor neu gestartet und (aus meiner Sich) Glück gehabt: Der Neustart verlief problemlos und qm-Befehle funktionierten wieder.

Offen bleibt die Frag: Warum kann sich eine VM mehr Speicher nehmen als unter local-zfs noch verfügbar ist?

 

[udo]

Offen bleibt die Frag: Warum kann sich eine VM mehr Speicher nehmen als unter local-zfs noch verfügbar ist?

Hi,
vielleicht weil Du ihr mehr zugewiesen hast?
mit zfs kannst Du over provisioning machen - also mehr zuweisen, als Du überhaupt hast, weil nur das belegt wird, was auch in Benutzung ist (zusätzlich kompression).

Udo

 

[r4dh4l]

vielleicht weil Du ihr mehr zugewiesen hast?
mit zfs kannst Du over provisioning machen - also mehr zuweisen, als Du überhaupt hast, weil nur das belegt wird, was auch in Benutzung ist (zusätzlich kompression).

Danke. Gibt es einen Weg, das Gegenteil zu konfigurieren?

 

[LnxBil]

Ehrlich gesagt traue ich mich nicht, einen Dienst neu zu starten, wenn der Speicher des Hypervisors randvoll ist. Ich kann es nicht begründen, würde aber meinen, dass das keine gute Idee ist.

Dann wirst du dein Problem auch nicht beseitigen können. Dein PVE-Pseudodateisystem ist halt kaputt und dein System läuft auf "geborgter Zeit" (borrowed time), sodass es nur eine Frage der Zeit ist, bis alles abschmiert. Plane ein Wartungsfenster und starte den Dienst neu, falls das nicht geht musst du eh neustarten.

Danach solltest du dir auf jeden Fall überlegen Speicher für / bzw. rpool/ROOT/pve-1 zu reservieren, sodass es nicht wieder volllaufen kann. Auch kannst du einen ZFS-Pool nicht voller als 93% bekommen ohne direkt I/O Fehler wegen vollem Dateisystem zu erlangen - zumindest nicht in meinen Tests. ZFS wird auch spürbar langsamer ab ca. 80% Füllgrad.

Danke. Gibt es einen Weg, das Gegenteil zu konfigurieren?

Ja, am Einfachsten das "Häckchen" für Thin-Provisioning in der GUI bei Storage für ZFS wegmachen. Das trifft dann aber nur für alle neuen Maschinen zu, die du anlegst. Auch hättest du dein aktuelles Problem damit nicht lösen können, denn Root-Dateisystem ist vollgelaufen, was dir auch mit Thick-Provisioning passiert wäre.

 

[r4dh4l]

Danach solltest du dir auf jeden Fall überlegen Speicher für / bzw. rpool/ROOT/pve-1 zu reservieren, sodass es nicht wieder volllaufen kann.

...was mich direkt zu einer Frage führt, die ich schon immer mal stellen wollte: Ich verstehe die Speicheraufteilung von proxmox nicht. Ich habe einen "local"-Speicher und einen namens "local-zfs".

1. Warum diese Unterscheidung und nicht "ein Speicher für alles"?
2. für "local" wird mir in Proxmox aktuell "17.13% (6.18 GiB of 36.07 GiB)" angezeigt. Wann habe (wahrscheinlich) ich festgelegt, dass "local" 36GB groß ist (kann mich an eine entsprechende Option beim Installieren nicht erinnern)?
3. Entspricht "local" -> "rpool/ROOT/pve-1" (aktuell bei mir laut df-h: "37G 6.2G 30G 18%")?

Ja, am Einfachsten das "Häckchen" für Thin-Provisioning in der GUI bei Storage für ZFS wegmachen. Das trifft dann aber nur für alle neuen Maschinen zu, die du anlegst. Auch hättest du dein aktuelles Problem damit nicht lösen können, denn Root-Dateisystem ist vollgelaufen, was dir auch mit Thick-Provisioning passiert wäre.

Wäre es das wirklich? Ich könnte doch bei Thick-Provisioning gar nicht mehr Speicher zuteilen als vorhanden ist, oder?

4. Davon abgesehen habe ich noch folgendes Problem, das wahrscheinlich mit dem Speichervolllaufen zusammenhängt:

# qm listsnapshot 104
`-> upd_synapse161_ante         2019-11-30 03:08:45     Before updating to Synapse 1.6.1
`-> current                                             You are here!
# qm delsnapshot 104 upd_synapse161_ante
zfs error: could not find any snapshots to destroy; check snapshot names.
#

Hat jemand eine, wie ich den Snapshot entfernt bekomme? Durch diesen "irgendwie doch vorhandenen" Snapshot scheint die VM bei einem Neustart auch nicht mehr automatisch hochzufahren.

Edit: Frage 4 ausgelagert nach https://forum.proxmox.com/threads/zfs-snapshot-einträge-lassen-sich-nicht-löschen.63673/.

5. Zuguterletzt: Für "local-zfs" sagt mir proxmox "Usage 99.43% (5.06 TiB of 5.09 TiB)". Ich habe kürzlich auf einer VM für Seafile durch ein Seafile-internes Tool namens "garbace collector" 1TB an Daten frei bekommen, zumindest sagt mir das df -h auf der Seafile-VM. Warum zeigt mir proxmox dann immernoch "Usage 99.43%" an?

Edit: Frage 5 ausgelagert nach https://forum.proxmox.com/threads/speicherplatz-unklar-zfs.41120/.