Search results

Hallo @Raoul1963, reguläre Paket-Updates (apt update && apt dist-upgrade) könnt ihr bedenkenlos machen — der Kernel-Pin bleibt davon unberührt. Es werden zwar ggf. neuere Kernel-Pakete installiert, aber gebootet wird weiterhin in den gepinnten Kernel. Ihr verliert also keine Sicherheitsupdates...

Hallo @3n0x, so lässt sich das leider nicht eingrenzen — da brauchen wir deutlich mehr Infos: Proxmox VE Version (pveversion -v) Netzwerk-Konfiguration (cat /etc/network/interfaces) Zwischen welchen Endpunkten ist es langsam? (VM↔VM, VM↔Host, VM↔extern?) Welche konkreten Geschwindigkeiten misst...

Hallo @rothkraut, das automatische Zurückmigrieren nach einem Ausfall ist über HA-Gruppen mit Node-Prioritäten möglich. Beispiel-Setup: Gruppe "brandabschnitt-a": Node1 (Priorität 2), Node2 (Priorität 2), Node3 (Priorität 1), Node4 (Priorität 1) Gruppe "brandabschnitt-b": Node3 (Priorität 2)...

Hallo @nimblefox, das ist ein klassisches DNS-Problem im Container — er kann keine Hostnamen auflösen. Bitte poste die Ausgabe folgender Befehle im Container: cat /etc/resolv.conf ping -c 3 8.8.8.8 ip a ip r Der ping auf die IP zeigt, ob grundsätzlich Netzwerk vorhanden ist oder ob es wirklich...

Dass die MSA-Belegung nach Scrub-Abschluss unverändert bei 94% steht obwohl ~500 GB per UNMAP gemeldet wurden, ist auffällig. Die Datenträgergruppenbereinigung ist primär ein Integritätscheck (Parity-Verify) — die UNMAP-Verarbeitung läuft davon eigentlich unabhängig. Prüf mal direkt per CLI, ob...

Hallo @Raoul1963, @Karl_OS, Das ist ein bekannter Regression-Bug im Kernel 6.8.12-9-pve, der Intel e1000e NICs betrifft — ihr seid also nicht allein damit. Zum Thema Updates: Reguläre Paket-Updates (apt dist-upgrade) könnt ihr weiterhin machen — die sind sogar empfohlen (Sicherheitsfixes...

Das -f ist hier absolut sicher — ZFS meckert nur, weil es erkennt, dass der by-id-Pfad auf dieselbe physische Platte zeigt, die bereits im Pool ist. Genau das wollen wir ja. Allerdings: Du hast -part1 angehängt, das ist falsch. sdf wurde als Whole-Disk ohne Partition dem Pool hinzugefügt...

@nitrosont, dein top-Output zeigt das Problem ziemlich eindeutig — es ist kein CPU-Problem, sondern Speicher: MiB Mem: 256.0 total, 1.2 free, 253.3 used — RAM praktisch voll MiB Swap: 256.0 total, 0.1 free, 255.9 used — Swap ebenfalls voll AdGuardHome allein: 234 MB RES (89.4%) 82.3% sy, 14.8%...

@Joe77, die winsat-Ergebnisse mit v3 vs v4 sind praktisch identisch (Random 16K Read 179 vs 192 MB/s) — CPU-Typ und VBS sind damit als Ursache ausgeschlossen. Dass eine einzelne SATA-SSD bei @boisbleu 831 MB/s Random Read liefert und deine drei PM983 NVMe nur 179 MB/s, bestätigt eindeutig das...

Hallo @Joe77, die CrystalDiskMark-Werte bestätigen das Problem — die sequentiellen Werte sind hervorragend, aber 4K Q1T1 mit ~35/28 MB/s ist für drei PM983 NVMe im Verbund deutlich zu wenig. Die Ursache ist, wie @cwt schon angedeutet hat, das RAIDZ1. Bei RAIDZ1 muss jeder kleine Schreibvorgang...

@Stefan123 wenn ihr ein dediziertes Ceph-Cluster nutzt und die Compute-Nodes nur als Hypervisor laufen, dann brauchen die Nodes lokal keine schnellen Platten für die VM-Workloads — die I/O läuft ja komplett übers Netzwerk zum Ceph-Cluster. Lokale Disks in den Compute-Nodes dienen dann nur für...

Stimmt, danke @Falk R. da habe ich mich vertan.

@Stefan123, wenn ihr ein dediziertes Ceph-Storage-Cluster mit NVMe betreibt, laufen auf den Compute-Nodes keine Ceph-OSDs. Die lokalen Platten dort brauchen nur das PVE-OS, ISOs und ggf. temporäre Daten — dafür reichen SAS-SSDs völlig aus, die werden kein Flaschenhals. Der eigentliche...

@Stefan123, bei einem dedizierten Ceph-Storage-Cluster laufen auf den Compute-Nodes keine Ceph-OSDs — die VM-Disks werden über das Netzwerk via RBD angebunden. Die lokalen Platten in den Nodes brauchen nur Proxmox selbst (OS) und ggf. ISO-Images oder Container-Templates. Dafür reichen SATA-...

@Ahtse , der Hinweis von @Johannes S ist wichtig: Die von Blockbridge dokumentierten Datenintegritätsprobleme bei qcow2/LVM-Snapshots mit cache=none relativieren meine Aussage von vorhin deutlich. Ich würde von Volume-Chain-Snapshots auf dem shared LVM für die Worker VM abraten und bei der...

Hallo @alejandro85, This is expected behavior, but it's a Veeam limitation, not a Proxmox issue. The Proxmox API (/api2/json/cluster/resources) always returns the correct current node for every VM in real-time — there is no delay on the Proxmox side after a migration. Veeam's Proxmox...

@vmwombat, gut, Metrics-Server raus ist der richtige Schritt. Sind die GUI-Symptome (fehlende VM-Namen, Statistik-Lücken) jetzt weg? Falls ja, war das die Ursache. Noch offen: 'rz-monitor' Neben 'pve-monitor' wirft auch rz-monitor alle paar Zyklen 400 Bad Request. Den solltest du ebenfalls in...

@aL1aL7, stimmt, da war ich gerade wo anderster. Seit PVE 9 unterstützt thick LVM über Volume-Chain-Snapshots tatsächlich qcow2 mit Snapshot-Funktionalität. @Ahtse, damit ist deine ursprüngliche Idee prinzipiell nicht falsch: Volume Chain Snaps auf dem thick LVM aktivieren und die Worker VM...

@Ahtse, nein, das geht so nicht. Ein LVM-Storage (thick) in Proxmox unterstützt ausschließlich das raw-Format — qcow2 ist dort nicht möglich, unabhängig von irgendwelchen Einstellungen. Das ist eine Limitation des Storage-Typs in Proxmox, nicht der einzelnen VM. Für die Worker VM braucht ihr...

Die Logs sind eindeutig — pmxcfs und Corosync sind nicht das Problem. ls /etc/pve/nodes/ antwortet in 0.003s, pve-cluster loggt nur normale "received log" und "data verification successful" Meldungen. Die Ursache sind zwei Dinge: 1. Externer Metrics-Server 'pve-monitor' ist down Auf allen...