docs(cluster): pveelite are LAN pe USB - a doua ipoteza pentru caderea de ieri

Intrebarea "nu-l putem trezi cu un magic packet?" a scos la iveala ceva ce
schimba diagnosticul, nu doar raspunsul la ea.

Pe WoL, pe scurt: nu se poate nici macar incerca. MAC-ul lui pveelite nu mai
exista nicaieri - intrarea ARP a expirat pe pvemini (INCOMPLETE), pe pve1
(FAILED), in tabela statiei de admin si pe LXC-urile de pe LAN; nodurile au IP
static, deci nu exista lease DHCP; in documentatie nu e consemnat. Raman tabela
routerului sau citirea fizica de pe nod. Si chiar cu MAC-ul, placa de retea e pe
USB, iar un dongle USB e nealimentat in soft-off, deci nu asculta dupa magic
packet.

Partea care conteaza insa e alta: pveelite ARE placa de retea pe USB, si
deconectarea ei e modul de defectare deja documentat al acestui nod - incidentul
2026-04-20 a pornit exact de la un USB LAN disconnect, motiv pentru care tokenul
corosync a fost marit la 10 s. Un nod care si-a pierdut adaptorul de retea arata
din exterior identic cu unul oprit: fara ping, fara ARP, fara corosync, fara SSH.
Toate observatiile din incident sunt compatibile cu ambele scenarii, iar eu
scrisesem doar unul.

Pentru 16:01 dovezile inclina in continuare spre repornire - curba de memorie din
RRD se reseteaza (2,43 GB la 16:00 -> 2,10 GB la 16:30, sub valoarea de dupa boot)
si NFS-ul se reataseaza. Pentru 17:26 nu exista niciun indiciu echivalent: nodul
pur si simplu a incetat sa fie vizibil, ceea ce o deconectare USB explica la fel
de bine ca o pierdere de alimentare. Am slabit corespunzator formularile din TL;DR
si din cronologie, unde afirmasem repornirea ca fapt.

Consecinta practica, pusa in document ca avertisment inainte de orice altceva:
prima observatie la fata locului e daca masina merge - ventilatoare, LED-uri,
imagine. Daca e pornita, nu a fost o cadere de alimentare, jurnalul e intact si
reparatia e la dongle, cablu sau portul de switch. Nu apasa butonul de power
inainte sa te uiti.

In script, pasul 1 nu mai citeste boot-urile dupa index - indexurile difera intre
cele doua scenarii si ar fi dus la concluzii gresite. Acum taie jurnalul dupa ora
si pune intai testul decisiv: exista intrari dupa 17:26:44? Daca da, masina a mers
mai departe si a cazut doar reteaua, iar verdictul si remediile se schimba complet.
Adaugat si un bloc de diagnostic pentru adaptorul USB (interfete, drivere, lsusb,
deconectari si evenimente de link in jurnalul kernel).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8

proxmox/cluster/incidents/2026-08-27-pveelite-down.md

@@ -19,9 +19,10 @@ pveelite e oprită)
 2. **13:20:26–13:20:41** — toate trei nodurile pornesc la loc și reformează clusterul complet
    (membership `1.1c7`, Members: 1 2 3). **pveelite a revenit normal** și a funcționat 2h40m.
 3. **16:01:48 → 16:03:17** — pveelite dispare din corosync și revine după ~89 de secunde.
-   Nu a fost un flap de rețea: la 16:03:10 se reatașează ca **client NFS** (`rpc.mountd: v4.2
-   client attached from 10.0.20.202:986`), iar mount-ul NFS se reface doar la boot. **Nodul
-   s-a resetat singur.** Nimeni nu i-a comandat asta.
+   La 16:03:10 se reatașează ca **client NFS** (`rpc.mountd: v4.2 client attached from
+   10.0.20.202:986`), iar curba de memorie din RRD se resetează — **probabil s-a repornit
+   singur**, deși o întrerupere de rețea de 89 s explică și ea reatașarea NFS (vezi
+   *Ipoteza alternativă* mai jos). Cert e că nimeni nu i-a comandat nimic.
 4. **17:15:01** — ultimul semn de viață: cronul de pe pveelite se conectează prin SSH la
    pvemini, ca la fiecare 15 minute.
 5. **17:26:44** — pveelite pică definitiv. **Nu a mai revenit.**
@@ -32,15 +33,17 @@ pveelite e oprită)
 8. **17:31** — alerta a plecat pe email, după cele 5 minute de prag din script. Lanțul de
    alertare a funcționat end-to-end.
 
-**Root cause:** nedeterminabilă de la distanță — nodul e mort la nivel L2. Dovezile
-disponibile exclud însă cauzele software și indică **defect hardware / de alimentare pe
-cutia pveelite**, cel mai probabil declanșat de ciclul de oprire-pornire de la prânz:
+**Root cause:** nedeterminabilă de la distanță — nodul nu răspunde nici la ARP. Dovezile
+disponibile **exclud cauzele software** și lasă în picioare două ipoteze hardware: defect de
+alimentare pe cutia pveelite (declanșat probabil de ciclul de oprire-pornire de la prânz)
+sau cedarea adaptorului USB de rețea. Ce se poate afirma acum:
 
 - **Nu e resurse:** RRD-ul de pe pvemini arată nodul complet inactiv în ora dinaintea
   căderii — CPU 0,4 %, load 0,10, RAM 2,15 din 15,3 GB, rootfs 18,5 GB constant. Nu e
   repetarea scenariului OOM din aprilie.
-- **Nu e rețea:** în ultimele 7 zile nu există niciun flap knet în afara zilei de azi.
-  pve1 ↔ pvemini sunt stabile continuu de la 13:20.
+- **Nu e rețeaua clusterului ca întreg:** în ultimele 7 zile nu există niciun flap knet în
+  afara zilei de azi, iar pve1 ↔ pvemini sunt stabile continuu de la 13:20. Asta **nu**
+  exclude însă o problemă strict pe portul / adaptorul lui pveelite.
 - **Nu e UPS:** `ups.status: OL`, baterie 100 %, input 239,6 V, load 8 %. Ultimul test de
   autonomie de azi a fost pe UPS-ul serverului 36, nu pe cel al clusterului.
 - **Nu e comandă de la noi:** singura rulare `ups-shutdown` de azi (14:12) a fost în
@@ -48,6 +51,37 @@ cutia pveelite**, cel mai probabil declanșat de ciclul de oprire-pornire de la
 - **Tiparul e de hardware:** reset spontan la 16:01, apoi moarte definitivă 85 de minute
   mai târziu, pe o mașină idle. Semnătură clasică de PSU / RAM / termic.
 
+### Ipoteza alternativă, care trebuie exclusă prima: adaptorul USB de rețea
+
+**pveelite are placă de rețea pe USB**, iar deconectarea ei e modul de defectare deja
+documentat al acestui nod: incidentul [2026-04-20](2026-04-20-cluster-outage.md) a pornit
+de la un *USB LAN disconnect*, iar tokenul corosync a fost mărit la 10 s tocmai ca să
+tolereze „glitch-uri USB pveelite" (`cluster/README.md`, secțiunea Corosync Tuning).
+
+**Din exterior, cele două scenarii sunt indistinctibile.** Un nod care s-a oprit și un nod
+care și-a pierdut adaptorul de rețea arată identic: fără ping, fără ARP, fără corosync,
+fără SSH. Toate observațiile din acest document sunt compatibile cu ambele.
+
+Ce înclină totuși spre repornire la 16:01 — dar **nu** dovedește nimic despre 17:26:
+
+- Curba de memorie din RRD urcă constant după boot-ul de la 13:20 (2,19 → 2,43 GB la 16:00),
+  apoi **coboară la 2,10 GB la 16:30** — sub valoarea de imediat după boot — și reîncepe să
+  urce (2,15 GB la 17:00). Tiparul unei reporniri, nu al unei întreruperi de rețea.
+- La 16:03:10, `rpc.mountd` înregistrează `v4.2 client attached` de la 10.0.20.202. Un mount
+  NFS se reface la boot — deși o reatașare NFSv4 după expirarea lease-ului într-o partiție
+  de 89 de secunde rămâne posibilă.
+
+Pentru **17:26 nu există niciun indiciu echivalent** — nodul pur și simplu a încetat să fie
+vizibil. O deconectare USB explică asta la fel de bine ca o pierdere de alimentare.
+
+> **Consecință practică, înainte de orice altceva:** când ajungi la nod, **prima observație
+> e dacă mașina merge** — ventilatoare, LED-uri, imagine pe monitor. Dacă e pornită, nu a
+> fost o cădere de alimentare, jurnalul e intact și complet, iar reparația e la dongle /
+> cablu / port de switch. Nu apăsa butonul de power înainte să te uiți.
+
+Testul decisiv, automatizat în scriptul de verificare: **jurnalul continuă după 17:26:44?**
+Dacă da, mașina a mers mai departe și a căzut doar rețeaua.
+
 ---
 
 ## Cronologie (EEST)
@@ -66,7 +100,7 @@ cutia pveelite**, cel mai probabil declanșat de ciclul de oprire-pornire de la
 | 16:00:02 | pvemini | cron de pe pveelite, SSH normal | `sshd` |
 | **16:01:48** | pvemini | `link: host: 3 link: 0 is down` — pveelite dispare | `corosync` |
 | 16:02:07 | pvemini | `Members left: 3`, `Failed to receive the leave message` | `corosync` |
-| 16:03:10 | pvemini | `rpc.mountd: v4.2 client attached from 10.0.20.202` — **remount NFS ⇒ pveelite a bootat** | `rpc.mountd` |
+| 16:03:10 | pvemini | `rpc.mountd: v4.2 client attached from 10.0.20.202` — remount NFS ⇒ probabil a bootat | `rpc.mountd` |
 | 16:03:17 | pvemini | `Members joined: 3` — pveelite revine în cluster | `corosync` |
 | 16:15 / 16:30 / 16:45 / 17:00 | pvemini | cronurile de pe pveelite rulează normal | `sshd` |
 | **17:15:01** | pvemini | **ultimul semn de viață** al lui pveelite | `sshd` |
@@ -163,9 +197,10 @@ Nodul se pornește fizic. Imediat după ce revine, se rulează
 
 Scriptul acoperă, în ordine:
 
-1. **De ce s-a resetat la 16:01 și de ce a murit la 17:26** — `journalctl -b -1` și `-b -2`
-   pentru erori, `mcelog`/MCE în `dmesg`, evenimente termice, `Hardware Error`.
-   **Dacă log-urile sunt tăcute (ca la pvemini în aprilie), concluzia e alimentare/hardware,
+1. **S-a oprit mașina, sau doar a dispărut din rețea?** Testul decisiv: există intrări în
+   jurnal după 17:26:44? Dacă da → a mers mai departe, a căzut rețeaua (adaptorul USB), iar
+   reparația e la dongle/cablu/switch. Dacă nu → mașina chiar s-a oprit, și atunci contează
+   dacă jurnalul e tăcut înainte (MCE, termic, panic, EDAC). **Tăcere = alimentare/hardware,
    nu software** — și atunci nodul nu mai e de încredere ca țintă de failover.
 2. **Integritatea ZFS** — `zpool status -v` după două opriri necurate; se așteaptă
    eventual un resilver automat, ca în aprilie.
@@ -194,18 +229,35 @@ Dacă `journalctl -b -1` nu conține nimic înainte de 17:26 (tăcere completă,
 2026-04-20), atunci **cauza e hardware și nodul trebuie tratat ca nesigur** până la
 înlocuirea sursei / testare RAM. Nu se lasă concluzia „a mers, deci e bine".
 
-**3. Textul alertei — scos exportul NFS inexistent.**
+**3. Notează adresa MAC a lui pveelite — acum nu o mai are nimeni.**
+În timpul incidentului s-a pus întrebarea dacă nodul poate fi trezit cu un magic packet
+(Wake-on-LAN). **Nu s-a putut nici măcar încerca:** intrarea ARP expirase peste tot —
+`ip neigh` pe pvemini (`INCOMPLETE`) și pe pve1 (`FAILED`), tabela ARP a stației de admin,
+LXC-urile de pe LAN. Nodurile au IP static, deci nu există lease DHCP, iar MAC-ul nu e
+consemnat în documentație. Singurele surse rămase: tabela ARP/DHCP a routerului 10.0.20.1
+sau citirea fizică de pe nod.
+
+Separat de asta, **WoL are șanse mici pe acest nod**: placa de rețea e pe USB, iar un
+adaptor USB rămâne nealimentat în stare soft-off, deci nu poate asculta după magic packet.
+De verificat la repornire, împreună cu MAC-ul:
+```bash
+ssh root@10.0.20.202 "ip -br link; ethtool <iface> | grep -iE 'Wake-on|Supports Wake'"
+```
+Dacă apare `Supports Wake-on: g` și se activează și în BIOS, WoL devine posibil. Dacă nu,
+concluzia se scrie explicit aici, ca să nu se reia discuția la următorul incident.
+
+**4. Textul alertei — scos exportul NFS inexistent.**
 `/opt/scripts/pveelite-down-alert.sh` menționează `10.0.20.202:/mnt/pve/oracle-backups`, care
 nu mai e în `storage.cfg`. Cine citește alerta la 3 noaptea o ia pe o pistă falsă.
 
 ### 🟡 Tier 2 — de decis după verdictul hardware
 
-**4. Ce se întâmplă cu marja de quorum.**
+**5. Ce se întâmplă cu marja de quorum.**
 Cât timp pveelite e nesigur, clusterul funcționează pe 2 din 3 voturi. Nu se umblă la
 `expected votes` cât timp e quorate — dar dacă nodul urmează să stea oprit zile întregi,
 merită decis conștient dacă rămâne în cluster sau se scoate temporar.
 
-**5. `local-zfs` pe pvemini la 92 %.**
+**6. `local-zfs` pe pvemini la 92 %.**
 Separat de incident, dar pe același nod pe care stă acum toată producția.
 
 ---