From 2ad6a8dbc41d2267f6cd90a5feee39152cb6ea6f Mon Sep 17 00:00:00 2001
From: duffyduck <info@hacker-net.de>
Date: Wed, 4 Mar 2026 22:00:01 +0100
Subject: [PATCH] update readme

---
 README.md | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 262601d..6e13b99 100644
--- a/README.md
+++ b/README.md
@@ -10,6 +10,7 @@ Migriert ein komplettes Proxmox-Cluster (inkl. Ceph) von einem Netzwerk in ein a
 - Koordinierte Migration aller Nodes in einem Durchgang
 - Ceph-Support (Public Network, Cluster Network, MON-Adressen)
 - Funktioniert auch bei **gebrochenem Quorum** (z.B. wenn ein Node bereits manuell geändert wurde)
+- **Rescue-Netzwerk** — temporäres Emergency-Netz wenn sich Nodes nicht mehr erreichen können
 - Automatische Backups aller Konfigurationen vor der Migration
 - Dry-Run-Modus zum gefahrlosen Testen
 - Verifikation nach der Migration
@@ -18,7 +19,7 @@ Migriert ein komplettes Proxmox-Cluster (inkl. Ceph) von einem Netzwerk in ein a
 
 - Python 3.9+ (auf Proxmox standardmäßig vorhanden)
 - Root-Zugriff auf dem Node, auf dem das Tool läuft
-- SSH-Zugriff (Key-basiert) zu allen anderen Cluster-Nodes
+- SSH-Zugriff (Key-basiert) zu allen anderen Cluster-Nodes (oder Konsolenzugriff für Rescue-Modus)
 - Keine externen Python-Pakete nötig (nur stdlib)
 
 ## Installation
@@ -242,4 +243,66 @@ systemctl restart corosync
 - SSH-Keys müssen **vorher** zwischen den Nodes eingerichtet sein (bei Proxmox-Clustern standardmäßig der Fall)
 - VMs/CTs werden **nicht** automatisch migriert oder gestoppt — das Netzwerk wird im laufenden Betrieb geändert
 - Nach der Migration sollten VM-Netzwerke (Bridges in VM-Configs) geprüft werden, falls diese sich auf spezifische IPs beziehen
+- Die Emergency-IPs (`ip addr add`) sind temporär und überleben keinen Reboot — sie werden nur zur SSH-Kommunikation während der Migration genutzt
 - Getestet mit Proxmox VE 7.x und 8.x
+
+## Projektstruktur
+
+```
+proxmox-cluster-network-changer/
+├── main.py              # Entry-Point, CLI mit allen Optionen
+├── discovery.py         # Phase 1: Cluster-Config lesen & parsen
+├── planner.py           # Phase 2: IP-Mapping, neue Configs generieren
+├── backup.py            # Phase 3: Backup aller Configs
+├── migrator.py          # Phase 4: Migration durchführen (7 Schritte)
+├── verifier.py          # Phase 5: Post-Migration Checks
+├── rescue.py            # Rescue-Netzwerk (Emergency Mode)
+├── ssh_manager.py       # SSH-Verbindungen (lokal + remote)
+├── config_parser.py     # Parser für Corosync/Ceph/Network Configs
+├── models.py            # Dataclasses (NodeInfo, CorosyncConfig, etc.)
+└── requirements.txt     # Keine externen Dependencies
+```
+
+## Typische Szenarien
+
+### Szenario 1: Normaler Umzug (alles funktioniert noch)
+
+```bash
+python3 main.py --dry-run     # Erst testen
+python3 main.py               # Dann ausführen
+```
+
+### Szenario 2: Ein Node wurde bereits manuell geändert
+
+PVE01 hat schon die neue IP, PVE02-04 noch die alte. Kein SSH möglich.
+
+```bash
+# Option A: Rescue-Befehle anzeigen und manuell ausführen
+python3 main.py --rescue-commands 10.99.99.0/24
+# -> Befehle auf allen Nodes per IPMI/KVM eingeben
+# -> Dann normal starten:
+python3 main.py --rescue
+
+# Option B: Einfach starten, das Tool fragt automatisch
+python3 main.py
+# -> "3 Node(s) nicht erreichbar. Rescue-Netzwerk einrichten? [J/n]"
+```
+
+### Szenario 3: Nur Discovery (schauen was los ist)
+
+```bash
+python3 main.py --discover
+```
+
+### Szenario 4: Cluster komplett kaputt, kein Quorum
+
+```bash
+python3 main.py --rescue
+# Das Tool:
+# 1. Richtet Emergency-Netzwerk ein
+# 2. Liest Configs über Emergency-IPs
+# 3. Migriert alles
+# 4. Erzwingt Quorum mit 'pvecm expected 1'
+# 5. Schreibt Ceph-Config direkt (nicht über /etc/pve)
+# 6. Räumt Emergency-IPs auf
+```