# PGS - Intenție, Probleme și Compromis

## Intenție

Scopul inițial a fost simplu:
- să se poată salva starea guest-urilor active înainte de lucrări de mentenanță;
- să se poată restaura după revenirea nodurilor;
- să se evite pornirea guest-urilor care erau deja suspendate sau oprite înainte de operație.

Pentru VM-uri QEMU, asta a însemnat `qm suspend --todisk 1`.
Pentru containere LXC, asta a însemnat `pct shutdown`, urmat de `pct start` la restaurare.

## Abordarea inițială

Prima variantă a fost automată:
- `systemd` apela `suspend` la oprirea nodului;
- `systemd` apela `resume` la revenirea nodului;
- un fișier JSON local păstra lista guest-urilor care trebuiau restaurate.

Motivația a fost să existe un flux "hands-off" pentru reboot și shutdown.

## Probleme întâmpinate

În practică, abordarea automată a fost fragilă pe un cluster Proxmox real.

Problemele observate:
- imagini stale de suspend:
  - `disk image '...state-suspend-....raw' already exists`
- scrieri eșuate în `pmxcfs` / `/etc/pve`:
  - `Permission denied`
  - `Device or resource busy`
- ferestre fără quorum în timpul opririi sau revenirii nodurilor;
- VM-uri care porneau, dar rămâneau cu `lock: suspended`;
- restaurări parțiale, cu numai o parte din guest-uri repornite;
- comportament dependent de ordinea exactă în care reveneau rețeaua, corosync, storage-ul și `pve-cluster`.

Problema structurală a fost aceasta:
- `qm suspend` și `qm resume` nu sunt operații pur locale;
- ele au nevoie de scrieri coerente în `/etc/pve`;
- `/etc/pve` depinde de `pmxcfs` și de starea clusterului;
- în scenarii în care mai multe noduri se opresc sau pornesc în același timp, această dependență devine sursă de curse și inconsistențe.

Am adăugat mai multe remedieri tactice:
- cleanup pentru imagini stale;
- retry după eșec;
- relaxare temporară de quorum cu `pvecm expected 1`;
- curățare automată pentru `lock: suspended`.

Aceste remedieri au redus unele erori, dar nu au schimbat faptul că modelul automat rămânea nedeterminist în scenarii de mentenanță pe întregul cluster.

## Concluzie

Automatizarea la shutdown/boot nu a fost suficient de robustă pentru mediul real.

Mai exact:
- pentru reboot de un singur nod, putea funcționa uneori acceptabil;
- pentru lucrări în care mai multe noduri sau întregul cluster sunt oprite, rezultatele nu au fost suficient de predictibile.

Problema nu mai era un bug punctual, ci o nepotrivire între design și condițiile reale de operare.

## Compromisul ales

A fost aleasă o variantă mai simplă și mai controlabilă:
- fără automatizare `systemd`;
- fără hook-uri la shutdown sau boot;
- suspendarea se rulează manual înainte de mentenanță;
- restaurarea se rulează manual după revenirea clusterului.

Comenzile sunt:

```bash
/usr/local/sbin/pgs suspend -v
/usr/local/sbin/pgs resume -v
```

## De ce acest compromis este acceptabil

Se pierde comoditatea automatizării, dar se câștigă:
- control explicit asupra momentului execuției;
- posibilitatea de a aștepta revenirea clusterului înainte de `resume`;
- debug mai simplu;
- mai puține efecte surprinzătoare în timpul shutdown-ului;
- separare clară între pregătirea mentenanței și restaurarea ulterioară.

Practic, operatorul decide când clusterul este suficient de stabil pentru restaurare, în loc să lase asta pe seama ordinii de pornire a serviciilor.

## Ce rămâne intenționat în cod

Deși automatizarea a fost eliminată, scriptul păstrează unele protecții utile:
- detecție și cleanup pentru imagini stale de suspend;
- tratament pentru guest-uri deja pornite sau deja suspendate;
- cleanup pentru `lock: suspended` când este posibil;
- jurnalizare clară în `journalctl -t pgs`.

Acestea rămân utile și în fluxul manual.

## Ce nu mai face proiectul

Proiectul nu mai încearcă:
- să orchestreze reboot-ul nodurilor;
- să decidă automat momentul corect pentru restore;
- să garanteze restaurare automată după revenirea clusterului.

Acesta este acum un utilitar manual de guest state, nu un manager de reboot.