duffyduckandClaude Opus 5
59e7224297
26 Kapitel in vier Teilen, in der Reihenfolge, in der man sie braucht: erst sichern, dann Dateien holen, dann ganze Maschinen wiederherstellen, dahinter der Nachschlagteil. Gebaut wird mit MkDocs + Material. Bewusst ohne Netzabhaengigkeiten: keine Schriften vom CDN (font: false), Volltextsuche mit deutschem Stemming liegt neben den Seiten. Im Notfall steht vielleicht das halbe Netz - dann nuetzt eine Doku im Internet nichts. handbuch/bauen.sh baut handbuch/site/ handbuch/bauen.sh ansehen Vorschau auf 127.0.0.1:8000 install.sh nimmt das gebaute Handbuch mit nach /usr/share/doc/pvesnap/handbuch/ - falls es vorliegt. Auf dem Host selbst wird nichts gebaut, mkdocs gehoert nicht auf einen Hypervisor. Die 28 Bildschirmfotos sind nicht abfotografiert, sondern erzeugt: Der echte Programmcode laeuft in einem Pseudo-Terminal gegen einen erfundenen Proxmox-Host (Attrappen fuer pvesh, perl und rbd), pyte baut den Bildschirm nach, heraus faellt ein SVG. Damit stimmen sie garantiert mit dem Programm ueberein, sind reproduzierbar und enthalten keine echten Daten. Die Werkstatt dafuer liegt unter handbuch/werkstatt/ samt LIESMICH.md. Nebenbei: die Schlussmeldung von install.sh warb noch mit --exchange, das mit dem eingebauten Austauschlaufwerk weggefallen ist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
177 lines
5.4 KiB
Markdown
177 lines
5.4 KiB
Markdown
# Damit arbeiten
|
|
|
|
++enter++ auf einer Maschine in der Übersicht öffnet die Detailansicht. Das ist
|
|
der Bildschirm, auf dem man im Ernstfall die meiste Zeit verbringt:
|
|
|
|
|
|
|
|
| Taste | |
|
|
|---|---|
|
|
| ++s++ | starten |
|
|
| ++h++ | [herunterfahren](#herunterfahren) |
|
|
| ++e++ | [Austauschlaufwerk auswerfen / einklinken](transfer.md#im-laufenden-betrieb-wechseln) |
|
|
| ++v++ | [Austauschlaufwerke verwalten](transfer.md) |
|
|
| ++p++ | [SPICE und USB](dongle.md#nachtraglich-umstellen) |
|
|
| ++f++ | [vom Quell-Snapshot lösen](loesen.md) |
|
|
| ++x++ | [verwerfen](verwerfen.md) |
|
|
| ++q++ | zurück |
|
|
|
|
---
|
|
|
|
## An die Konsole kommen
|
|
|
|
In der Detailansicht steht die fertige Adresse:
|
|
|
|
```
|
|
https://10.20.0.11:8006/?console=kvm&novnc=1&vmid=9101&node=pve1&resize=off&cmd=
|
|
```
|
|
|
|
Dasselbe liefert `pvesnap-recovery console 9101`. Es ist die ganz normale
|
|
noVNC-Konsole von Proxmox — die Maschine taucht auch in der Weboberfläche auf,
|
|
markiert mit dem Tag `pvesnap-recovery`.
|
|
|
|
Bei Containern geht zusätzlich `pct enter 9101` auf dem Host.
|
|
|
|
!!! info "Warum eine IP-Adresse und kein Name?"
|
|
|
|
Vorne steht bewusst die **IP** des Nodes, nicht sein Name: Auf dem
|
|
Proxmox-Host löst der Name auf, am Arbeitsplatz meist nicht. Sie kommt aus
|
|
`/etc/pve/.members`.
|
|
|
|
Der Node hinter `node=` bleibt der Name — so erwartet Proxmox ihn.
|
|
|
|
Für SPICE und USB-Weiterleitung siehe [Dongle und USB](dongle.md).
|
|
|
|
---
|
|
|
|
## Was man drinnen tut
|
|
|
|
Die Maschine ist voll beschreibbar. Alles, was man an einer echten Maschine
|
|
täte, geht auch hier — nur eben ohne Netz.
|
|
|
|
Der typische Ablauf für eine Datenbank:
|
|
|
|
<div class="ablauf" markdown>
|
|
|
|
**1.** Im Gast prüfen, ob der Dienst läuft — mit geladenem Arbeitsspeicher ist
|
|
er bereits offen
|
|
|
|
**2.** Dump schreiben, auf das [Austauschlaufwerk](transfer.md):
|
|
`pg_dump -Fc kunden > /media/DUMPS/kunden.dump`
|
|
|
|
**3.** Im Gast aushängen (`umount`, unter Windows „Auswerfen")
|
|
|
|
**4.** In pvesnap ++e++ — Laufwerk auswerfen
|
|
|
|
**5.** ++v++ ++enter++ — Commander auf das Laufwerk, Dump abholen
|
|
|
|
**6.** ++x++ — Maschine verwerfen
|
|
|
|
</div>
|
|
|
|
Schritt 3 ist der, den man vergisst. Mehr dazu unter
|
|
[Austauschlaufwerke](transfer.md#im-laufenden-betrieb-wechseln).
|
|
|
|
---
|
|
|
|
## Herunterfahren
|
|
|
|
Taste ++h++ fährt **sauber** herunter — und schaltet nicht von selbst hart ab.
|
|
|
|
Weigert sich der Gast, kommt eine Wahl:
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Im Gast selbst herunterfahren** | pvesnap wartet und meldet, wenn sie aus ist |
|
|
| **Hart ausschalten** | wie Stecker ziehen, mit ausdrücklicher Bestätigung |
|
|
| **Abbrechen** | läuft weiter |
|
|
|
|
!!! quote "Warum nicht einfach nach 60 Sekunden abschalten?"
|
|
|
|
Weil ein stilles Abschalten nach Zeitablauf ein Stromausfall mit Ansage
|
|
wäre — und genau der Grund, warum ein Dateisystem hinterher unsauber ist.
|
|
|
|
Wenn man gerade dabei ist, aus einer Maschine konsistente Daten zu holen,
|
|
ist das die falsche Voreinstellung.
|
|
|
|
Beim Warten zeigt pvesnap, was zu tun ist, und verfolgt den Zustand:
|
|
|
|
```
|
|
Bitte jetzt IM GAST herunterfahren.
|
|
|
|
Windows Start -> Ein/Aus -> Herunterfahren
|
|
Linux poweroff bzw. shutdown -h now
|
|
|
|
Zustand: running seit 1:23
|
|
```
|
|
|
|
++q++ bricht das Warten ab — die Maschine läuft dann weiter.
|
|
|
|
---
|
|
|
|
## Neu starten
|
|
|
|
Ein Neustart wird nötig, wenn sich die [Grafikkarte ändert](dongle.md) — also
|
|
beim Ein- oder Ausschalten von SPICE. Dann kommt dieselbe Wahl:
|
|
|
|
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Ich fahre im Gast herunter** | pvesnap wartet, startet danach selbst wieder — **der verlässliche Weg** |
|
|
| **Proxmox herunterfahren lassen (ACPI)** | klappt bei Linux, bei Windows oft nicht |
|
|
| **Gar nicht** | später selbst; die Änderung greift beim nächsten Start |
|
|
|
|
!!! warning "ACPI und Windows"
|
|
|
|
Bei Linux funktioniert der ACPI-Aus-Knopf zuverlässig. Windows blockt ihn
|
|
gern: Dort hält eine Anwendung den Vorgang auf, oder der Shutdown Event
|
|
Tracker fragt nach einem Grund und wartet auf eine Eingabe, die nie kommt.
|
|
|
|
Wer im Gast selbst herunterfährt, umgeht das. Deshalb steht dieser Weg an
|
|
erster Stelle.
|
|
|
|
!!! danger "Ein Neustart *im* Gast hilft nicht"
|
|
|
|
Dabei setzt sich nur die Maschine zurück — der QEMU-Prozess läuft weiter,
|
|
mit der alten Grafikkarte. Es braucht wirklich den Umweg über „aus und
|
|
wieder an".
|
|
|
|
### Der geladene Arbeitsspeicher ist danach weg
|
|
|
|
!!! danger "Endgültig"
|
|
|
|
Proxmox gibt den kopierten Arbeitsspeicher schon beim **ersten** Start
|
|
wieder frei. Ein zweiter Start bootet also kalt — offene Programme und
|
|
ungespeicherte Daten sind dann verloren.
|
|
|
|
pvesnap warnt vorher ausdrücklich, wenn eine Maschine mit geladenem
|
|
Arbeitsspeicher neu starten soll:
|
|
|
|
|
|
|
|
Wer den warmen Zustand braucht, erledigt seine Arbeit also **vor** dem ersten
|
|
Neustart — oder verzichtet gleich mit `--no-resume` darauf und bootet kalt.
|
|
|
|
---
|
|
|
|
## Starten und Stoppen von außen
|
|
|
|
```bash
|
|
pvesnap-recovery start 9101
|
|
pvesnap-recovery stop 9101
|
|
pvesnap-recovery list
|
|
pvesnap-recovery console 9101
|
|
```
|
|
|
|
`list` zeigt dieselbe Tabelle wie die Übersicht:
|
|
|
|
```
|
|
Maschine Zustand Node Herkunft Modus
|
|
VM 9101 running pve1 VM 101 @ auto-stuendlich-20260809-… live
|
|
VM 9102 stopped pve2 VM 105 @ auto-taeglich-20260809-02… recover
|
|
```
|
|
|
|
Steht in der Spalte **Zustand** ein `weg`, wurde die Maschine außerhalb von
|
|
pvesnap entfernt — dann hilft [`cleanup`](verwerfen.md#cleanup).
|