Referenz für Proxmox VE Operationen (Version 9.1.2)
Nodes, Gäste und Dienste können während eines Vorgangs ausfallen, unerreichbar sein oder verschwinden. Gehen Sie niemals davon aus, dass etwas läuft: Fragen Sie den aktuellen Zustand ab, wiederholen Sie den Vorgang mit einem Timeout und führen Sie eine abgestufte Fehlerbehandlung durch. Für Muster der Selbstheilung siehe bitranox:coding-resilience.
1. Cluster Konfiguration (Automatische Erkennung)
| Prüfung | Befehl |
|---|---|
| Umgebung | pveversion --verbose (vollständige Komponentenversionen: Kernel, pve-manager, corosync, qemu-server) |
| Nodes | pvecm nodes (Anzahl, Namen, IDs) / pvecm status (IPs, Quorum, Transport, Link-Zustände) |
| Quorum | pvecm status -- Prüfung des Felds "Quorate". Schwelle: floor(gesamte_nodes/2) + 1 |
| API Zugriff | pvesh (lokales CLI), pveproxy (HTTPS :8006), REST API. Verwenden Sie --output-format json für Skripte |
| Storage | pvesm status (aktive Storages) / cat /etc/pve/storage.cfg (vollständige Konfiguration) |
| Netzwerk | pvesh get /nodes/{node}/network --output-format json / cat /etc/network/interfaces |
| Abonnement | pvesubscription get (Status prüfen) / pvesubscription set <key> (Schlüssel anwenden) |
2. Sicherheitsprotokolle
| Regel | Details |
|---|---|
| Keine zerstörerischen Bulk-Operationen | Befehle, die >1 Node betreffen (Neustart, Herunterfahren, Bulk-VM-Stopp), erfordern eine explizite Benutzerbestätigung. |
| Quorum-Prüfung | Vor Node-Neustart/Wartung: pvecm status. Wenn (aktuell - 1) < floor(gesamt/2) + 1 -- abbrechen. Bei 2-Node-Clustern QDevice prüfen. |
| Zuerst Backup | Vor VM-Konfigurationsänderungen oder Upgrades prüfen, ob ein Backup existiert: pvesm list {storage} --content backup |
| Kein erzwungenes Löschen | Niemals --purge oder --force ohne Überprüfung der Ressourcen-ID: qm config {vmid} oder pct config {vmid} |
| HA-Status | Vor HA-Ressourcenänderungen: ha-manager status -- prüfen, ob Migrationen/Fencing laufen. |
| Netzwerkänderungen | Zuerst immer einen Probelauf durchführen: ifreload -a -n (ifupdown2 hat kein –test). Niemals ifdown auf einer Bridge, die Gastdatenverkehr transportiert. Remote-Anwendung und DHCP/Bond/WLAN-Fallen: references/host-networking.md. |
| Corosync-Konfiguration | Zuerst kopieren, die Kopie bearbeiten, aktuelles Backup erstellen, dann verschieben. config_version immer inkrementieren. |
| Storage-Operationen | Vor dem Entfernen von Storage: pvesm list {storage} um zu überprüfen, ob keine VMs/CTs darauf verweisen. |
| Schutzflag | qm set {vmid} --protection 1 / pct set {vmid} --protection 1 um versehentliches Löschen zu verhindern. |
| ZFS-Eigenschaftsdurchläufe | PVE speichert die konfigurierte Festplattengröße eines Gastes ALS refquota des Datasets. Ein Durchlauf, der refquota/refreservation über alle Datasets löscht, entfernt stillschweigend die Festplattenbegrenzung jedes Gastes, während pct config noch die alte Größe meldet, sodass ein Container den Pool füllen kann. Blattnamen ausschließen, die mit subvol- oder vm- beginnen. |
3. Aktionsprüfprotokoll
Verpflichtend. Führen Sie diese Prüfung vor jeder Aktion durch, die direkt auf einem Proxmox-Node, einer VM oder einem Container ausgeführt wird (Befehle, Konfigurationsänderungen, Dienstoperationen).
Ausnahme: Schreibgeschützte Operationen – Lesen von Logs, Abfragen des Status, Sammeln von Informationen ohne Änderungen – gelten als sicher und können sofort ohne diese Prüfung durchgeführt werden.
Führen Sie dieses Gate auf
opusaus. Diese Steelman / Red-Team-Beurteilung entscheidet über eine Änderung an der LIVE-Infrastruktur – ein schwächeres Modell unterschätzt das Risiko von Ausfällen, Datenverlust und Quorum-Verlust. Führen Sie die Überprüfung aufopusdurch: delegieren Sie sie an einen fixiertenopus-Subagenten mit einem Aufwand vonmedium(Überprüfungsdisposition, siehe bitranox:process-agents-subagent-driven-development "Überprüfungsdispositionen"), oder (wenn Sie sie inline behalten) bieten Sie an, das Modell zu wechseln oder fortzufahren, BEVOR Sie ausführen. Führen Sie dieses Gate niemals auf einer unbekannten, niedrigeren Stufe aus. Siehebitranox:process-agents-subagent-driven-development("Das Sitzungsmodell ist festgelegt" / "Konkrete Stufen").
3.1 Steelman-Aufforderung
Betrachten Sie die geplante Aktion oder Konfiguration, die auf dem Proxmox-Server ausgeführt werden soll, in ihrer idealen, erfolgreichsten Form. Stellen Sie sich vor, diese Aktion repräsentiert die sicherste, effizienteste und optimal integrierte Lösung. Formulieren Sie, wie diese Aktion die Ziele der Systemadministration perfekt erfüllt, die Stabilität erhöht und die Benutzeranforderungen vollständig erfüllt.
3.2 Red-Team-Aufforderung
Überprüfen Sie die geplante Proxmox-Aktion, als wären Sie ein erfahrener Administrator oder Sicherheitsanalyst, der versucht, potenzielle Risiken aufzudecken. Identifizieren Sie mögliche Schwachstellen in der Konfiguration, berücksichtigen Sie Ausfallrisiken, Datenverlust oder unbeabsichtigte Nebenwirkungen. Testen Sie die Robustheit des Plans unter worst-case-Szenarien, um sicherzustellen, dass er auch unter Druck sicher und zuverlässig bleibt.
3.3 Entscheidung
Bewerten Sie am Ende der Red-Team-Überprüfung, ob die identifizierten Risiken oder Schwachstellen schwerwiegend genug sind, um die geplante Aktion zu stoppen. Wenn die Aktion sicher, logisch und robust erscheint, kann sie sofort ausgeführt werden. Wenn erhebliche Unsicherheiten bestehen bleiben, muss der Benutzer explizit um Bestätigung gebeten werden. Schließen Sie mit einer klaren Entscheidung ab: entweder "Aktion ausführen" oder "Benutzer um Bestätigung bitten".
4. Code- & Antwortstil
- Antworten: Kurz, präzise, CLI-fokussiert (
pvesh,pvecm,pvesm,qm,pct,ha-manager,vzdump,pvesr,pvenode,pveceph,pveum,pveam). - Fehlerbehebung: Immer zuerst Logs abfragen:
journalctl -u pvedaemon -n 50,pvenode task list --errors 1,/var/log/pveproxy/access.log. - JSON-Präferenz: Verwenden Sie
--output-format jsonoderjson-pretty. Verwenden Sie--noborder --noheaderfür scriptbasiertes Parsen. - Rollback-Plan: Jede Änderung muss einen Rollback beinhalten. Sichern Sie zuerst Konfigurationsdateien. Stellen Sie sicher, dass Backups existieren, bevor Sie Storage/VM-Änderungen vornehmen.
5. Tabelle zur Cluster-Größe
| Größe | Verhalten |
|---|---|
| Einzelner Node | Keine Cluster-Operationen. Kein HA. Fokus auf lokalem Storage + externen Backups. |
| 2 Nodes | QDevice wird dringend empfohlen. Ohne: Verlust eines Nodes = Quorum-Verlust. pvecm expected 1 für Notfälle. |
| 3+ Nodes | Volles HA. Toleriert floor((N-1)/2) Ausfälle (3 Nodes: 1, 5 Nodes: 2). |
Node-Anzahl ermitteln: pvecm nodes | grep -c '^\s*[0-9]'
6. Kurzreferenz zur Fehlerbehebung
| Problem | Diagnose |
|---|---|
| Cluster nicht quorate | pvecm status > "Quorate: No". Konnektivität prüfen, systemctl status corosync. Notfall: pvecm expected 1. |
| Node tritt nicht bei | UDP 5405-5412, Zeitsynchronisation, SSH (TCP 22) prüfen. Versuchen: pvecm add {IP} --fingerprint {SHA256}. |
| VM startet nicht | Lock prüfen: #qm unlock {vmid}. Logs prüfen: journalctl -u pvedaemon -n 50 oder Task-Liste. VM-Konfiguration validieren: #qm config {vmid}. CPU-Architektur oder Ressourcenkonflikte prüfen. |
| Container startet nicht | Lock prüfen: #pct unlock {vmid}. Template-Validierung: #pveam available. Storage- und Netzwerkkonfiguration prüfen. |
| Storage nicht verfügbar | pvesm status prüfen: #pvesm status. Storage-Konfiguration prüfen: #cat /etc/pve/storage.cfg. Verbindung zum Remote-Storage prüfen (z.B. NFS, Ceph). |
| Ceph-Gesundheit | #ceph -s ausführen, um den Gesamtstatus zu prüfen. #pveceph status für die Integration mit Proxmox. OSD-Status prüfen: #ceph osd tree. |
| Benutzerauthentifizierungsprobleme | Benutzerpräfix prüfen (z.B. test@pve). pveum user list ausführen. Berechtigungen prüfen: pveum user permissions <user>. |
| Firewall-Probleme | pve-firewall status und pve-firewall localnet ausführen. Firewall-Regeln prüfen: /etc/pve/firewall/cluster.fw. Stellen Sie sicher, dass die Firewall für die erforderlichen Ports und IP-Adressen geöffnet ist. |
| Netzwerkfehler | /etc/network/interfaces prüfen. #ifreload -a -n für einen Probelauf. ip a ausführen, um den Interface-Status zu prüfen. |
| Zugriff auf Webinterface nicht möglich | #systemctl status pveproxy prüfen. Port 8006 und 8007 prüfen. Zertifikatsprobleme prüfen: #openssl x509 -in /etc/pve/local/pve-ssl.pem -text. Firewall-Regeln prüfen, die den Zugriff blockieren. |