# 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.