[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.
 
MisterY schrieb:
und ist noch lange nicht ausgelastet.
Zum Vergrößern anklicken....
Und wie ist die Swap-Nutzung? 4* NVMe nachgerüstet, auf so einer Bifurcation-Karte? CPU ist welches Baujahr? 8-)
Vermutlich sinnvoll, mal im offiziellen Forum nachzufragen.
 
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:
Changelog napp-it cs (rc)
####################
Update: Menu About > Frontend Update

26.08.15
-create snap/replication job with freeze and include /etc/pve
-Restore: select a snap with included /etc/pve and clone/rollback/undo
-new menu Snap > Restore Proxmox VM from snap

Restrictions:
A ZFS snap alone is versioning not a VM backup, you must add replication or PBS backups
If you delete a VM in Proxmox, you delete all related snaps too (no undo from snaps).
ZFS snaps are per dataset not per VM, it works only if all VM disks are on this dataset
A VM restore from snaps via clone requires a reboot

Restore from nvme480 dataset,
to restore LXC, you must select a rpool snap

1786795644317.png
 
Moin Moin,

ich habe mit meinem 5700G Transcoding probleme mit manchen 4K UHD Aufnahmen. Die wollen partou einfach nicht flüssig am TV laufen.
Aufgrund der extrem hohen Hardwarepreise kommt derzeit ein Upgrade auf Intel 13-14. Gen nicht in frage (allein der Ram kostet so viel wie mein derzeitiger Server komplett und das sehe ich nicht ein :fresse: )
Daher kam mir die Idee mit ner Intel Arc A380 als Hardware Codec. Ist das ohne weiteres per Passtrough für einen laien möglich einzubinden? Oder gibt es Hürden die man kaum überwunden kriegt, bevor ich jetzt die 100euro sinnlos aus dem Fenster werfe.

Zusätzlich kam mir die Idee, ich könnte ja einen USB Ethernet 5G Adapter einbinden um von 1G auf 2,5G zu kommen....geht das ohne Probleme?
 
@DonChulio Und das betrifft jetzt welche Anwendung, Jellyfin? An der Netzwerkspeed liegt es quasi nie. So 'ne zusätzliche GraKa kostet einiges an Strom.
 
Für nen 4K UHD Stream bzw mehrere reicht die 1G Anbindung locker.
Wie genau sieht den Setup fürs Trancoding aus, der 5700G hat eigentlich genug Power.
 
manche Aufnahmen schafft er einfach nicht....95% schafft er und 5% halt nicht =)

Anwendung ist Jellyfin, richtig.

Mir wurde gesagt, dass die iGPU jetzt kein Codingwunder ist, daher auch die ursprüngliche Idee mit Upgrade auf Intel CPU...aus Kostengründen wollte ich über GPU gehen. Alternativ die Arc Pro A40, die braucht deutlich weniger Strom

Upgrade auf 5G eigentlich nur aus "haben will" über den Server läuft ja auch ein NAS neben Jellyfin. Und ich hab gerade mein Netzwerk geupgradet, da würde die 1G nicht mehr dazu passen^^
 
DonChulio schrieb:
Moin Moin,

ich habe mit meinem 5700G Transcoding probleme mit manchen 4K UHD Aufnahmen. Die wollen partou einfach nicht flüssig am TV laufen.
Aufgrund der extrem hohen Hardwarepreise kommt derzeit ein Upgrade auf Intel 13-14. Gen nicht in frage (allein der Ram kostet so viel wie mein derzeitiger Server komplett und das sehe ich nicht ein :fresse: )
Daher kam mir die Idee mit ner Intel Arc A380 als Hardware Codec. Ist das ohne weiteres per Passtrough für einen laien möglich einzubinden? Oder gibt es Hürden die man kaum überwunden kriegt, bevor ich jetzt die 100euro sinnlos aus dem Fenster werfe.

....
Zum Vergrößern anklicken....
hast du eine ram disk zum transcoden? das war bei mir unter plex das problem; die nvme war einfach zu langsam. mit einer 8gb großen ram disk funktioniert jetzt das transcoden ruckelfrei und ohne probleme, egal wie groß der 4k film ist.
 
@DonChulio Bist du denn sicher, dass er überhaupt transcoidert, zeigt Jellyfin das in der Adminkonsole an? Das optimale Ziel ist ja eigentlich, dass er alles mit Directplay abspielt wo dann nur der Bitstream 1zu1 durchgereicht wird, was auf deinem Jellyfin Server dann quasi gar keine Auslastung erzeugt. Das fetteste was ich bis jetzt gesehen habe beim Streaming (und da reden wir von Fullsize UHD Bluerays) sind irgendwas um die 80MB/s, selbst dafür reicht ein 1GBit Netzwerk aus. In meinem Setup läuft das auf jeden Fall absolut problemlos via Directyplay ins Wohnzimmer, nutze dort nen Shield TV Pro mit Jellyfin bzw. Moonfin app (oder auch die Apps auf dem LG Web OS). Ich hab auch leider keine LAN Verbindung und regle die Verbindung über zwei WiFI APs (Zyxel BE11000) ins Wohnzimer an dem ich dann nen 1Gbit Switch hängen habe zur Shield bzw. zum TV.

Meine CPU auf dem Docker Host ist btw. auch "nur" ein AMD Ryzen 5 PRO 5650G der langweilt sich komplett, selbst beim Transcodieren und das obwohl der auch die ganzen neuen Features nicht kann. Ich würde empfehlen eher mal zu checken warum Directy Play nicht läuft und ggf. in ne extra Hardware wie Shield TV Pro investieren um das mal zu testen.

*edit*
Btw bin ich gerade im Urlaub und Streame da auch häufiger mal via VPN (auch mit Direct Play) und das läuft wunderbar, obwohl mein Upload zuhause "nur" 120Mbit ist und meine schwedische Waldhütte hier nur 50Mbit Down kann. Also wie @BobbyD schon sagte, deine 1GBit Verbindung ist da ziemlich sicher nicht dran schuld.
 
Jetzt bin ich überfordert, was ist "Ram Disk" :d

Ich starte die Aufnahme und dann dauert es schon ewig bis die aufnahme überhaupt los geht, dann läuft sie 4-5min normal und hängt wieder 1 minute bis die nächsten 5 min wieder normal laufen. Was ich zusätzlich noch habe ist, dass in allen Aufnahmen "Springen" nicht wirklich sauber läuft, manchmal dauert es einfach nur bis es dann weiter geht, manchmal hängt sich alles auf und es geht gar nix mehr
 
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