Ja, These 1 ist für mich klar der heißeste von den dreien. VM3 ist eigentlich dein bester Beweis: läuft mit cpu=host und schmiert NICHT ab, einziger echter Unterschied ist der ältere Maschinentyp. Das verschiebt die Vermutung weg vom CPU-Typ hin...
Schön dass es jetzt läuft. Zur DB-Latenz würd ich aber nicht zu schnell den Softwarelieferanten verantwortlich machen, das könnte noch am selben Thema hängen. Check mal mit dmesg -w ob unter DB-Last weiterhin split_lock traps reinkommen. Durchaus...
Interessant, das kippt meinen host-Tipp von oben. Ich hatte ja geschrieben, geh wieder zurück auf host, aber wenn jetzt genau die host-VM abschmiert und die auf x86-64-v3 stabil läuft, dann nehm ich das zurück, dann ist der CPU-Typ doch der Hebel...
Das nic0 is a slave device, aborting ist der Knackpunkt: netpoll läuft nicht auf einem Bridge-Slave, und nic0 hängt ja in vmbr0. Mit nur der einen NIC kommst du da nicht weiter, solange sie in der Bridge steckt. Zum Test kannst du nic0 kurz aus...
Ah, ich verstehe nun besser, danke! Bin dabei, Dashboards entsprechend zu adaptieren und sehe bereits Fortschritte.
Ja, wirklich seltsam, dass da nur wenige Dashboards "am Ball" bleiben.
Das Problem ist nicht der fehlende Collector an sich, sondern dass deine Dashboard-Variable (die Instance-/Host-Auswahl) auf einer cs_-Metrik aufsetzt, die es nicht mehr gibt. Wenn die Template-Query wie label_values(windows_cs_hostname...
Danke für die Einschätzung @Bu66as
Die Phänomene treten eher unvorhersehbar auf, ich bin noch am Ausknobeln, wie ich das monitore. Ich nutze Grafana nur punktuell, und stelle fest, dass manche der Windows-Exporter-related dashboards nicht mehr...
Das ist nur der Gerätemanager-Screenshot aus #7 (Treiberauswahl SCSI controller), nix Neues. Die neuen Posts #16/#17 beantworten meine Fragen aus #15, dazu mein Entwurf:
---
Gut, die Werte passen alle (io_uring, virtio-scsi-single...
Das Bild ist nur der Screenshot aus Post #7 (Treiber-Auswahl im Gerätemanager), keine neue Info. Der letzte Post (#13) von sgw stellt eine konkrete offene Frage zum Cache-Mode, also passt ein voller Entwurf, der die neuen Posts (#12/#13)...
Die zwei 256er als ZFS-Mirror fürs PVE-OS und die 4TB als eigenen Pool für die VMs ist die richtige Lösung. OS und VM-Daten getrennt, und beim Mirror überlebt der Node auch wenn eine OS-Platte abraucht. Die Samsung sind nur OEM-Consumer (PM981a...
Kommt drauf an ob du wirklich VMs hast die die NVMe-Performance brauchen. Datenbank-Server z.B., wo @Falk R. ja die 1-Minuten-Replikation gefahren hat, sowas profitiert. Dann spricht nichts gegen nen zweiten ZFS-Pool auf der NVMe für genau die...
Schön dass es jetzt läuft, sowas ist doppelt nervig wenns ohne erkennbaren Grund plötzlich geht.
Für alles was über die Basis-Installation rausgeht ist die answer.toml der falsche Ort. Die deckt eigentlich nur das ab was der Installer selbst...
Das --answer-auth-token ist kein curl-Parameter, das ist eine Option vom proxmox-auto-install-assistant. curl kennt das nicht, daher der Fehler.
Für einen reinen Erreichbarkeits-Test reicht erstmal:
curl -k -X POST...
Genau die Kombi würde ich so nicht machen. ZFS-Replikation zieht die 2,5G-Leitung phasenweise komplett voll, und Corosync auf der selben NIC kriegt dann genau die Latenz-Spikes ab, die zu Quorum-Flaps führen. Corosync braucht ja praktisch keine...
Passt so, dein MGMT untagged übers Native-VLAN am Switchport zu fahren ist völlig in Ordnung, das läuft dann einfach auf vmbr0 ohne Tag und der Switch packt's ins richtige VLAN. Die getaggten VMs hängen ja über die selbe vmbr0 mit ihrem...
Hallo @rprengel, ich glaub da ist ein Denkfehler drin: bei --fetch-from http liegt die answer.toml nicht als Datei in irgendeinem Ordner rum. Der Installer macht einen POST an die URL und erwartet die fertige TOML als Antwort zurück. Auf der...
Klar, da gibt's eine eindeutige Empfehlung: nimm die VLAN-aware Bridge mit Tags (deine Variante 2). Im Cluster ist das einfach angenehmer, weil du nur EINE Bridge (vmbr0) auf allen Nodes identisch konfigurierst und das VLAN dann pro VM am NIC...