[Sammelthread] Proxmox Stammtisch

@Weltherrscher 10 Minuten kommt mir lang vor. Und Docker-Container, die sich nicht von alleine starten, hab ich auch noch nicht gesehen. Nutzt Du Compose? Hier keine Probleme.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
runter fahren locker 3 min (ca. 10 VMs), dann neustart mit dem ganzen supermicro dual-sockel-gedöns locker 2..3 min und natürlich die VMs wieder anfahren (TrueNAS braucht alleine 2,5 min).
Jap docker compose, sie starten, fliegen dann aber - warum auch immer - raus.
Ka, wieso das nur bei den beiden Containern ist, die restlichen laufen ohne Stress...
 
@Weltherrscher Ah so, fahre fast nur Container (und mein PVE ist selbst nur 'ne VM), daher kam mir das lang vor. Zeig doch mal so eine Compose. Nicht, dass dort was falsches steht. 😉
Ich hab zumeist restart: unless-stopped drin stehen. Docker läuft bei mir in diversen LXCs.
Screenshot 2026-08-10 at 14-54-30 Dashboard - Dockhand.png
 
Zuletzt bearbeitet:
Von ESXi her bin ich zwei Sachen gewohnt/sind mir wichtig:

1. Wenn ich einen ZFS Snap eines VM Storage mache, sollen darin nicht nur die virtuellen Platten liegen sondern auch die VM Konfiguration damit ich eine VM aus einem ZFS Snap wiederherstellen kann (snap erstellen geht im Gegensatz zu PBS sofort ohne was zu kopieren, auch zfs send über lan ist viel schneller). Bei ESXi war das eine .vmx Datei im VM Ordner. Bei Proxmox liegen die Konfigurationen der VMs in /etc/pve.

Lösung: ich habe im snapjob eine Snapoption "include regular folder".
Damit kann ich den Stand von /etc/pve zum Snapzeitpunkt mit in den Snap aufnehmen..

Anderer Einsatz wäre Windows um c:/Users/"ich" mit persönlichen Dokumenten auf ntfs mit im ZFS Snap zu haben

2. Konsistente VM Snaps
Ein ZFS snap ist für den host der ZFS verwaltet immer konsistent wegen Copy on Write und der ZFS internen Snapverwaltung. Ganz anders sieht es für VMs und deren Gastdateisysteme auf ZFS aus. Ein ZFS Snapshot im host kümmert sich nicht darum ob deren Dateisysteme konsistent bleiben. Die sind in einem Snap Stand wie bei einem unerwarteten Stromausfall. Deren Risiko für korrupte Daten läßt sich verringern, indem man dafür sorgt, dass keine Schreibaktionen während des Snap stattfinden (VM freeze). Proxmox kennt dafür verschiedene Methoden. Ich habe jetzt zfs snapshot in ein Go basiertes Tool eingebunden, das automatisch verschiedene Optionen für freeze bereitstellt um die Wahrscheinlichkeit einer korrupten VM im Snap zu verringern. Ganz vermeiden könnte man es nur durch snap im offline Status oder indem man RAM mit sichert. Das ist aber bei aktuellen RAM Größen sehr langsam.

Go tool (im aktuellen napp-it cs in sutosnap und replication jobs enthalten)
https://github.com/guenther-alka/cs-freeze4snap
 
Hi,

ich habe bei meinem PVE-Server eine hohe IO-WAIT (ca. 4,5 %) und eine IO-Verzögerung durch Auslastung von 30 %.

Proxmox liegt auf einer Intel 520 180GB, die eigentlich schnell genug sein sollte und auch laut S.M.A.R.T. noch voll in Ordnung ist.

Habt ihr eine Idee woran das liegt? Ich habe noch 4* NVME in einem ZFS striped mirror für die LXCs, aber auch wenn die alle aus sind, ist die IO-WAIT so hoch.
 
@MisterY Die SSD ist doch Asbach. Wenn der Rest des Systems ebenfalls so alt ist, wundert es mich weniger. Was sagt die RAM-Auslastung und Swap? Intel-SSD ersetzen gegen NVMe wäre vermutlich zielführend. Aber ich rate nur, bin kein Proxmox-Experte.

So sieht es bei mir aus (komplett ZFS), wobei die Gäste auf einer weiteren NVMe liegen.
Screenshot 2026-08-11 at 08-49-37 pve - Proxmox Virtual Environment.png Screenshot 2026-08-11 at 09-14-05 ZNAS - PVE.png
Edit: In älteren bzw. Nicht-ZFS-Installationen hatte PVE für nachträgliches ZFS den ARC nicht begrenzt, was zu RAM-Problemen und Swaping führen konnte.
 
Zuletzt bearbeitet:
NVME geht nicht, da das Board kein NVME nativ kann.

RAM ist genügend da (256 GB) und ist noch lange nicht ausgelastet.
 
Swappiness prüfen und anpassen
  • Aktuellen Wert auslesen:
    cat /proc/sys/vm/swappiness
  • Wert temporär ändern (z. B. auf 1 für minimales Swappen):
    sysctl vm.swappiness=1
  • Swap kurz leeren und neu laden (empfohlen direkt nach der Änderung):
    swapoff -a && swapon -a [1, 2, 3, 4]

Dauerhaft (persistent) speichern
  • Konfigurationsdatei erstellen:
    Erstellen Sie eine neue Datei unter /etc/sysctl.d/99-swappiness.conf mit einem Editor (z. B. nano /etc/sysctl.d/99-swappiness.conf).
  • Inhalt hinzufügen:
    vm.swappiness=1
  • Änderungen übernehmen:
    sysctl --system [1, 2, 3]

PS: 0 deaktiviert ganz, 1 ist gut, da der Swap nur zur äußersten Not verwendet wird um Crashes zu vermeiden, je höher der Wert, desto aggressiver das Swappen.
 
OT: Ich deaktiviere Swap auf allen meinen Systemen, egal welches OS. Kann es einfach nicht ausstehen.
 
SWAP ist deaktiviert.

Es handelt sich um ein E5-2660 V4. 4*NVME ist verbaut, jedoch nur für LXCs, S3 und Datenbanken reserviert.
 
BobbyD schrieb:
OT: Ich deaktiviere Swap auf allen meinen Systemen, egal welches OS. Kann es einfach nicht ausstehen.
Zum Vergrößern anklicken....
Ich meine, dass swapiness=1 eine sinnvolle Sache ist... das ist quasi off, mit der Ausnahme, dass der Swap kurz greifen würde, wenn ein OOM-Crash droht durch irgend einen kuriosen Fall der Fälle...
 
BobbyD schrieb:
@Weltherrscher Ah so, fahre fast nur Container (und mein PVE ist selbst nur 'ne VM), daher kam mir das lang vor. Zeig doch mal so eine Compose. Nicht, dass dort was falsches steht. 😉
---snip---
Zum Vergrößern anklicken....
bittesehr:
Watchtower compose:
YAML: 
services:
  watchtower:
#    image: containrrr/watchtower
    image: nickfedor/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      WATCHTOWER_SCHEDULE: "0 0 5 * * *"
      WATCHTOWER_TIMEOUT: 50s
#      WATCHTOWER_RUN_ONCE: true
#      WATCHTOWER_NOTIFICATIONS: email
#      WATCHTOWER_NOTIFICATION_EMAIL_FROM: watchtower@domain.tld
#      WATCHTOWER_NOTIFICATION_EMAIL_TO: it@domain.tld
#      WATCHTOWER_NOTIFICATION_EMAIL_SERVER: smtp.domain.tld
#      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT: 587
#      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER: it@domain.tld
#      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD: "hättstewojernewa?"
#      WATCHTOWER_NOTIFICATION_EMAIL_DELAY: 2
#      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_TLS_SKIP_VERIFY: "true"

openwebui compose:
YAML: 
services:
  openwebui:
    image: ghcr.io/open-webui/open-webui:cuda126
#    image: ghcr.io/open-webui/open-webui:cuda
#    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
#    network_mode: host
    volumes:
      - ./data:/app/backend/data
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  open-webui:
 
nope:
1786649450515.png

1786649493742.png

Oder dauert es länger, bis die aus der restart-schleife hoch kommen?

//Edith:
Manuell starten in Portainer geht dann einwandfrei (wie immer)...
YAML: 
services:
  openwebui:
    image: ghcr.io/open-webui/open-webui:cuda126
#    image: ghcr.io/open-webui/open-webui:cuda
#    image: ghcr.io/open-webui/open-webui:main
    restart: unless-stopped
    ports:
      - "3000:8080"
#    network_mode: host
    volumes:
      - ./data:/app/backend/data
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  open-webui:
 
Zuletzt bearbeitet:
Was sagen denn die docker logs dazu. Irgendwelche Einträge?
 
Die aus den Containeren?
Nichts, die enden mit dem letzten Eintrag vor dem Neustart der VM...
Docker selbsd (journalctl):
Code: 
-- Boot a8a82e09d1414db9a7d6c0137d297a0a --
Aug 13 21:27:44 VM-KI systemd[1]: Starting docker.service - Docker Application Container Engine...
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.730278477+02:00" level=info msg="Starting up"
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.734986598+02:00" level=info msg="OTEL tracing is not configured, using no-op tracer provider"
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.736057168+02:00" level=info msg="CDI directory does not exist, skipping" dir=/var/run/cdi
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.736088810+02:00" level=info msg="CDI directory does not exist, skipping" dir=/etc/cdi
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.892105255+02:00" level=info msg="Creating a containerd client" address=/run/containerd/containerd.sock timeout=1m0s
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.895891884+02:00" level=warning msg="failed check for fsverity support" error="enable fsverity failed: operation not supported" path=/var/lib/docker/plugins/storage
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.912670284+02:00" level=info msg="Loading containers: start."
Aug 13 21:27:44 VM-KI dockerd[1210]: time="2026-08-13T21:27:44.917336934+02:00" level=info msg="NRI is disabled"
Aug 13 21:27:45 VM-KI dockerd[1210]: time="2026-08-13T21:27:45.461524316+02:00" level=info msg="[graphdriver] using prior storage driver: overlay2"
Aug 13 21:27:45 VM-KI dockerd[1210]: time="2026-08-13T21:27:45.828170173+02:00" level=info msg="Restoring containers: start."
Aug 13 21:27:46 VM-KI dockerd[1210]: time="2026-08-13T21:27:46.066534416+02:00" level=info msg="Deleting nftables IPv4 rules" error="running nft: /dev/stdin:1:17-30: Error: Could not process rule: No such file or directory\ndelete table ip docker-bridges\n                ^^^^^^^^^^^^^^\n exit status 1"
Aug 13 21:27:46 VM-KI dockerd[1210]: time="2026-08-13T21:27:46.110969319+02:00" level=info msg="Deleting nftables IPv6 rules" error="running nft: /dev/stdin:1:18-31: Error: Could not process rule: No such file or directory\ndelete table ip6 docker-bridges\n                 ^^^^^^^^^^^^^^\n exit status 1"
Aug 13 21:27:47 VM-KI dockerd[1210]: time="2026-08-13T21:27:47.313163832+02:00" level=warning msg="Refreshing the CDI registry generated errors" error="failed to monitor for changes: no such file or directory\nfailed to monitor for changes: no such file or directory"
Aug 13 21:27:47 VM-KI dockerd[1210]: time="2026-08-13T21:27:47.313285098+02:00" level=warning msg="Ignoring previous errors updating spec" error="CDI device injection failed: unresolvable CDI devices nvidia.com/gpu=all"
Aug 13 21:27:47 VM-KI dockerd[1210]: time="2026-08-13T21:27:47.330104115+02:00" level=warning msg="Refreshing the CDI registry generated errors" error="failed to monitor for changes: no such file or directory\nfailed to monitor for changes: no such file or directory"
Aug 13 21:27:47 VM-KI dockerd[1210]: time="2026-08-13T21:27:47.330213691+02:00" level=warning msg="Ignoring previous errors updating spec" error="CDI device injection failed: unresolvable CDI devices nvidia.com/gpu=0"
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.175539873+02:00" level=info msg="sbJoin: gwep4 ''->'0555972ddc0a', gwep6 ''->''" eid=0555972ddc0a ep=immich_machine_learning net=immich_remote_ml_default nid=405e44d7d6d6
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.355903158+02:00" level=info msg="sbJoin: gwep4 ''->'b856b2286b82', gwep6 ''->''" eid=b856b2286b82 ep=openedai-speech-server-1 net=openedai-speech_default nid=69830c81f1e2
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.436097475+02:00" level=info msg="Loading containers: done."
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.583263842+02:00" level=info msg="Docker daemon" commit=6a43e3d containerd-snapshotter=false storage-driver=overlay2 version=29.7.2
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.583862397+02:00" level=info msg="Initializing buildkit"
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.584920464+02:00" level=warning msg="failed check for fsverity support" error="enable fsverity failed: operation not supported" path=/var/lib/docker/buildkit/content
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.696502290+02:00" level=info msg="Completed buildkit initialization"
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.707530207+02:00" level=info msg="Daemon has completed initialization"
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.707676201+02:00" level=info msg="API listen on [::]:2376"
Aug 13 21:27:48 VM-KI dockerd[1210]: time="2026-08-13T21:27:48.707681854+02:00" level=info msg="API listen on /run/docker.sock"
Aug 13 21:27:48 VM-KI systemd[1]: Started docker.service - Docker Application Container Engine.
Aug 13 21:33:43 VM-KI dockerd[1210]: time="2026-08-13T21:33:43.461779343+02:00" level=info msg="sbJoin: gwep4 ''->'e4b2e238f257', gwep6 ''->''" eid=e4b2e238f257 ep=open-webui-openwebui-1 net=open-webui_default nid=c030c6487dac
Die beiden anderen Container werden ohne murren gestartet.
Openwebui fluppt erst manuell.
...waaaait.
muss ich nach dem ändern der yml nochn down / up -d machen? :wall:

//Edith:
Das wars tatsächlich.
Gerade auch nochmal verifiziert: ALLE anderen Container haben den restart-Eintrag irgendwo drin...
Danke euch!
 
Zuletzt bearbeitet:
Ich mache gerade meine ersten Schritte mit PVE.
PVE liegt auf einem zfs-mirror. Dort soll auch nichts weiteres drauf kommen, außer natürlich /etc/pve/nodes/...
Die virtuelle Maschinen und LXC sollen auf eine NVME-zfs-mirror gespeichert werden.

PVE bietet mir jetzt die Möglichkeit den Storage als Typ ZFS oder als Typ Verzeichnis anzulegen.
Welches ist die bessere Variante, um später aus PVE heraus Snapshots anzulegen, aber auch Snapshots über ZFS @gea napp-it cs. Später dann auch sichern über entweder einen zweiten ZFS-Server oder PBS.
Und mich natürlich so flexibel wie möglich zu halten.
Beitrag automatisch zusammengeführt:

gea schrieb:
1. Wenn ich einen ZFS Snap eines VM Storage mache, sollen darin nicht nur die virtuellen Platten liegen sondern auch die VM Konfiguration damit ich eine VM aus einem ZFS Snap wiederherstellen kann (snap erstellen geht im Gegensatz zu PBS sofort ohne was zu kopieren, auch zfs send über lan ist viel schneller). Bei ESXi war das eine .vmx Datei im VM Ordner. Bei Proxmox liegen die Konfigurationen der VMs in /etc/pve.

Lösung: ich habe im snapjob eine Snapoption "include regular folder".
Damit kann ich den Stand von /etc/pve zum Snapzeitpunkt mit in den Snap aufnehmen..
Zum Vergrößern anklicken....
@gea dieses Feature hast aber in der napp-it cs 26.08.13.14 noch nicht drinne? Oder bin ich nur blind. :unsure:
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh