# Incident 2026-08-27 — pveelite dispare din rețea 16 ore, cu mașina pornită (reset adaptor USB LAN)

**Severity:** Medium (zero impact pe producție — nodul nu găzduia niciun serviciu viu —
dar clusterul rămâne pe **2 voturi din 3**, fără marjă de quorum, și replicarea către
pveelite e oprită)
**Detected:** 2026-08-27 17:31 EEST (alertă automată `pveelite-down-alert.sh` → email)
**Resolved:** 2026-08-28 09:49 EEST (`ifreload -a` de la consola fizică)
**Status:** **REZOLVAT** — mecanismul căderii e confirmat din jurnal (reset USB + interfață
nereatașată în punte), iar regula de hotplug îl acoperă, demonstrat în producție. **De ce se
resetează adaptorul rămâne necunoscut**: ipoteza unui mouse USB defect a fost formulată și
**infirmată prin test** pe 28.08 (secțiunea dedicată). Acțiunea principală rămâne mutarea
rețelei pe `eno1`
**Author:** Claude Code (mmarius28@gmail.com)

---

## TL;DR — lanțul cauzal

1. **12:25–12:36** — oprire **planificată** a întregului cluster, comandată din stația de
   admin (10.0.20.144). Guest-urile oprite ordonat prin API (`qmshutdown:303` la 12:25 de la
   `root@pam`), apoi nodurile. Oprirea a fost **curată** pe toate trei — `systemd-poweroff.service:
   Finished`, `Reached target poweroff.target`. Tiparul e exact al lui
   [`cluster-shutdown.ps1`](../scripts/cluster-shutdown.ps1).
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.
   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.**
6. **17:27:03** — corosync formează membership `1.1d8` fără nodul 3. Quorum păstrat (2/3).
7. **17:28:04–17:28:23** — HA fence executat **corect**: lock obținut, `vm:109` recuperat de
   pe nodul fenced pe pvemini și lăsat în starea în care era (`stopped`). Fără repornire
   nedorită, fără buclă OOM — spre deosebire de [incidentul din 2026-04-20](2026-04-20-cluster-outage.md).
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 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ț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
  **dry-run**, iar în jurnal nu există niciun poweroff/reboot trimis către 10.0.20.202.
- **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.

### ROOT CAUSE CONFIRMAT (2026-08-28, din jurnalul nodului)

Nodul **nu s-a oprit niciodată**. La verificarea din 28.08 ora 09:49, `uptime` arăta
**17 ore și 46 de minute**, cu boot-ul pornit la **2026-08-27 16:03:06** — a mers
neîntrerupt toată noaptea, fără rețea. Lista de boot-uri confirmă:

```
 -1  Thu 2026-08-27 13:20:28  ->  Thu 2026-08-27 16:02:44
  0  Thu 2026-08-27 16:03:06  ->  Fri 2026-08-28 09:49:22
```

**Vinovatul:** adaptorul USB de rețea — Realtek RTL8156B, `0bda:8156`, „USB 10/100/1G/2.5G
LAN", driver `r8152`, pe portul `usb 2-3` al controllerului `xhci_hcd 0000:00:14.0`.

**Ce s-a întâmplat la 16:01:45** — adaptorul s-a resetat și a fost re-enumerat:

```
xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
vmbr0: port 1(enx6c1ff71abe67) entered disabled state
r8152 2-3:1.0 enx6c1ff71abe67 (unregistering): left promiscuous mode
usb 2-3: new SuperSpeed USB device number 3 using xhci_hcd
r8152 2-3:1.0 enx6c1ff71abe67: renamed from eth0
```

Kernelul șterge interfața și o recreează. **Interfața nouă nu e readăugată automat în
`vmbr0` și nu e ridicată** — nu există regulă de hotplug. Din acel moment mașina merge
perfect, dar nu mai are rețea.

**De ce la 16:01 și-a revenit, iar la 17:26 nu.** La 16:01 nodul avea LRM-ul HA **activ**,
deci watchdog-ul era armat. Pierderea rețelei a dus la pierderea quorumului, iar watchdog-ul
a resetat mașina — repornire care a readus rețeaua *din întâmplare*, pentru că la boot
interfețele se ridică prin `auto`:

```
16:02:08  pmxcfs: node lost quorum
16:02:08  pve-ha-crm: lost lock 'ha_manager_lock' -> status change master => lost_manager_lock
16:02:09  pve-ha-lrm: lost lock 'ha_agent_pveelite_lock' -> status change active => lost_agent_lock
16:02:39  watchdog-mux: client watchdog expired - disable watchdog updates
16:02:44  (ultima linie din boot-ul -1 — resetul hardware)
```

La **17:26:41** s-a produs exact același reset USB. De data asta însă fence-ul mutase deja
`vm:109` pe pvemini, LRM-ul era **idle**, deci **watchdog-ul nu mai era armat**. Nimic nu a
mai repornit mașina, și a rămas pornită și fără rețea 16 ore.

> **Concluzia neplăcută:** singurul lucru care „repara" defectul ăsta era watchdog-ul HA,
> adică un efect secundar, nu un mecanism proiectat. Pe un nod fără servicii HA, aceeași
> defecțiune devine permanentă și tăcută.

**Remediul aplicat:** `ifreload -a` de la consola fizică, la 09:49. Interfața și puntea au
revenit imediat (`vmbr0 UP`, `enx6c1ff71abe67 UP,LOWER_UP`), nodul a reintrat în cluster.

**Nu a fost alimentarea.** Nicio semnătură de eroare hardware în jurnal — zero potriviri
pentru MCE, panic, temperatură peste prag, EDAC sau erori de I/O.

---

### DE CE se resetează adaptorul: ipoteza mouse-ului, INFIRMATĂ prin test (2026-08-28)

> **Concluzia secțiunii, pe scurt:** un mouse USB defect **există** pe pveelite și merită
> înlocuit, dar **nu el cauzează resetările adaptorului de rețea**. Testul controlat de la
> 11:24 a infirmat ipoteza în 8 minute. Cauza resetărilor rămâne **necunoscută**, iar
> mutarea pe `eno1` redevine reparația principală, nu una „de fond, pe lângă".
>
> Secțiunea e păstrată integral, cu ipoteza și infirmarea ei, ca să nu fie reluată.

Secțiunea precedentă explică *ce* se rupe — interfața recreată, nereatașată în punte. Nu
explica **de ce adaptorul se resetează**. Prima pistă a arătat foarte convingător, și a fost
greșită.

#### Ipoteza (11:20)

**Un mouse optic defect, pe același controller xHCI, se re-enumera de o mie de ori pe zi.**

| Dispozitiv | Port | Re-enumerări în boot-ul curent (43 h) |
|---|---|---|
| USB Optical Mouse (PixArt, `0461:4e84`) | hub `1-1`, port 1 | **1.127** — una la ~60 s |
| USB Multimedia Keyboard (Logitech, `046d:c313`) | hub `1-1`, port 4 | **1** |

Tastatura, pe **același hub**, e perfect stabilă. Asta elimină hub-ul, cablul spre hub și
controllerul ca vinovați: defectul e în mouse (sau în cablul lui).

Mouse-ul stă pe root hub-ul USB2, adaptorul LAN pe cel USB3, dar **ambele atârnă de același
controller PCI, `xhci_hcd 0000:00:14.0`**:

```
/sys/devices/pci0000:00/0000:00:14.0   <- mouse   (usb1 / 1-1.1)
/sys/devices/pci0000:00/0000:00:14.0   <- adaptor LAN (usb2 / 2-3)
```

Lanțul se vede curat la resetul din 28.08, ora 10:31 — mouse-ul se re-enumeră, iar
**trei secunde mai târziu** controllerul dă eroare și placa de rețea cade colateral:

```
10:31:36  usb 1-1.1: new low-speed USB device number 90        <- mouse, a 90-a oară
10:31:39  r8152-cfgselector 2-3: USB disconnect, device number 6
10:31:39  xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
10:31:39  r8152 2-3:1.0 enx6c1ff71abe67: Tx status -108
```

Toate cele 3 erori `xhci_hcd ... WARN` din boot-ul curent apar lipite de câte o resetare
r8152. Aceeași eroare deschide și citatul de la 16:01:45 din secțiunea precedentă — deci
și căderea de 16 ore intră pe același tipar.

#### Testul (11:24:04)

Portul mouse-ului dezactivat din sysfs, fără acces fizic — experiment reversibil, deliberat
**nepersistent** la reboot:

```bash
echo 1 > /sys/bus/usb/devices/1-1:1.0/1-1-port1/disable   # anulare: echo 0
```

Mouse-ul dispare din `lsusb`, tastatura rămâne. Criteriul stabilit înainte de test: dacă
resetările `r8152` încetează, ipoteza e validată.

#### INFIRMARE (11:31:52 — la 8 minute după test)

Adaptorul s-a resetat **cu mouse-ul complet oprit**, cu aceeași semnătură de eroare:

```
11:31:52  xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
11:31:52  xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
11:31:52  r8152-cfgselector 2-3: reset SuperSpeed USB device number 8 using xhci_hcd
```

Contorii la 46 de minute după dezactivare (`journalctl --since "2026-08-28 11:24:04"`):

| | |
|---|---|
| re-enumerări mouse | **0** — dezactivarea portului chiar a funcționat |
| resetări `r8152` | **1** |
| erori `xhci_hcd 0000:00:14.0: WARN` | **2** |

Deci mouse-ul **nu e necesar** pentru producerea defectului. Corelația de la 10:31 (mouse
re-enumerat, adaptor căzut 3 secunde mai târziu) a fost coincidență — mouse-ul se re-enumera
la fiecare ~60 s, deci *orice* eveniment de pe nod pica la câteva secunde după unul.

**Ce rămâne totuși adevărat:** mouse-ul e defect (1.127 re-enumerări față de 1 a tastaturii,
pe același hub) și merită înlocuit pe cont propriu. Doar că e o defecțiune separată.

#### Ce se știe acum despre resetări

Șase resetări spontane în 20 de ore de uptime, fără tipar de oră și fără corelație cu
încărcarea (nodul e idle):

```
27.08  17:26:40   <- caderea de 16 ore
27.08  17:33:27
28.08  05:50:29
28.08  09:32:06
28.08  10:31:39
28.08  11:31:52   <- cu mouse-ul dezactivat
```

Suspecții rămași, netestați: adaptorul RTL8156B însuși, portul / cablul USB3, controllerul
`xhci_hcd 0000:00:14.0`, alimentarea pe magistrala USB3. Un test ieftin, dacă se dorește
înainte de switch: mutarea dongle-ului în alt port USB3 (schimbă portul și traseul, păstrează
adaptorul) sau un alt adaptor USB LAN (schimbă adaptorul, păstrează portul).

**Ce ține nodul în picioare până atunci: regula de hotplug.** La resetul din 11:31:52 a
funcționat exact cum trebuie — reatașare în **4 secunde**, iar corosync a reformat membership
`1.1f4` cu 3 membri la 11:32:02. Un hopa de 10 secunde în loc de 16 ore.

> **Mutarea pe `eno1` redevine reparația principală**, nu una „de fond, pe lângă altele":
> scoate rețeaua nodului de pe magistrala USB cu totul, deci nu are nevoie să știe care dintre
> suspecții de mai sus e vinovatul.

---

### Ipoteza alternativă, formulată înainte de confirmare

**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)

| Ora | Nod | Eveniment | Sursa |
|-----|-----|-----------|-------|
| 12:25:02 | pvemini | `<root@pam> qmshutdown:303` — începe oprirea ordonată a guest-urilor | `pvedaemon` |
| 12:28:59 | pvemini | Stația de admin (10.0.20.144) se conectează prin SSH | `sshd` |
| 12:33:56 | pvemini | `Members left: 3` — pveelite se oprește primul | `corosync` |
| 12:35:58 | pvemini | `Members left: 1` — pve1 se oprește | `corosync` |
| 12:36:58 | pvemini | `Finished systemd-poweroff.service` — oprire curată, ultimul nod | `journalctl -b -1` |
| 13:20:24 | pve1 | boot | `uptime -s` |
| 13:20:26 | pvemini | boot | `uptime -s` |
| 13:20:41 | — | Cluster complet: membership `1.1c7`, Members[3]: 1 2 3 | `corosync` |
| 14:12:26 | pvemini | `ups-shutdown` orchestrat — **DRY-RUN**, fără efect. Status OL, baterie 100 % | `/var/log/ups-shutdown.log` |
| 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 ⇒ 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` |
| 17:26:35 | — | ultimul timestamp LRM pveelite | `ha-manager status` |
| **17:26:44** | pvemini | `link: host: 3 link: 0 is down` — cădere definitivă | `corosync` |
| 17:26:48 | pvemini | `Token has not been received in 7987 ms` | `corosync` |
| 17:27:03 | pvemini | Membership `1.1d8`, Members[2]: 1 2. **Quorum păstrat** | `corosync` |
| 17:27:13 | pvemini | `node 'pveelite': online => unknown` | `pve-ha-crm` |
| 17:28:04 | pvemini | `node 'pveelite': unknown => fence`; `vm:109` → `fence` | `pve-ha-crm` |
| 17:28:13 | pvemini | Lock de fence obținut; `vm:109` recuperat pe pvemini, `recovery` → `request_stop` | `pve-ha-crm` |
| 17:28:23 | pvemini | `vm:109` → `stopped`. Recovery încheiat curat | `pve-ha-crm` |
| **17:31** | pvemini | Alertă email trimisă (prag de 5 minute atins) | `/var/run/pveelite-down-alerted` |
| 21:22 | — | Verificare: ping 100 % loss, `ip neigh` → `FAILED`, nod inaccesibil de 4 ore | investigație |

---

## Starea la momentul investigației (27.08, ora 21:22 — înainte de a se cunoaște cauza)

### Cluster

```
Expected votes: 3 | Total votes: 2 | Quorum: 2 | Quorate: Yes
Members: 0x1 10.0.20.200 (pve1), 0x2 10.0.20.201 (pvemini, local)
/etc/pve/.members: pveelite online: 0
```

**Clusterul funcționează, dar fără nicio marjă.** Dacă mai cade un nod, se pierde quorumul
și `/etc/pve` devine read-only pe tot clusterul — toate guest-urile îngheață.

### Ce rula pe pveelite

**Nimic viu.** Singurul guest asignat nodului era `CT 301 docker-portainer-template`
(`template: 1`, oprit). `vm:109` era înregistrat în HA pe pveelite, dar în starea `stopped`,
și a fost recuperat pe pvemini la 17:28. Niciun serviciu HA activ nu era pe pveelite.

Motivul pentru care asta a mers bine: după incidentul din aprilie, sarcina a fost consolidată
pe pvemini/pve1, iar pveelite a rămas doar țintă de replicare + rezervă de failover.

### Replicare

| Job | Țintă | Ultima sincronizare | Stare |
|-----|-------|---------------------|-------|
| 100-1, 102-1, 103-1, 104-1 | pveelite | **2026-08-26** ~21:05–21:21 | ✗ eșec, FailCount 1 |
| 106-1 | pveelite | 2026-08-27 16:00:03 | ✗ eșec, FailCount 1 |
| 108-1, 171-1, 201-1 | pveelite | 2026-08-27 17:15 | ✗ eșec, FailCount 1 |
| 109-1 | pveelite | niciodată | ✗ eșec, FailCount 1 |
| **toate `*-0`** | **pve1** | **2026-08-27 20:00–21:20** | ✓ **OK** |

Eroarea e uniformă: `ssh ... root@10.0.20.202 -- pvesr prepare-local-job ... failed: exit code 255`
(SSH nu poate deschide conexiunea).

**Copia DR pe pve1 e intactă și la zi** — CT 108 Oracle și VM 201 replicate la 21:15, RPO 15 min
respectat. Redundanța a scăzut de la 2 copii la 1, nu la 0.

### Fără acces out-of-band

`tailscale status` → `pveelite ... offline, last seen 27d ago`. Nu doar că nodul e mort, dar
**tailscaled nu mai rulează pe el de 27 de zile** — deci nici dacă ar fi doar o problemă de
rețea LAN, tot n-am putea ajunge la el. Singura cale rămasă e fizică.

### Colateral observat

- `local-zfs` pe pvemini la **92,06 %** (69 GB liberi din 875 GB). Nu e cauza incidentului,
  dar e o problemă separată care merită tratată.
- Scriptul `/opt/scripts/pveelite-down-alert.sh` descrie în corpul alertei un export NFS
  `10.0.20.202:/mnt/pve/oracle-backups` care **nu mai există** în `storage.cfg`. Textul
  alertei e depășit și induce în eroare la citire.

---

## Ce a funcționat bine

Merită consemnat, pentru că sunt exact lucrurile reparate după aprilie:

1. **Fence-ul a mers curat.** Lock obținut, un singur serviciu recuperat, starea `stopped`
   respectată. Fără repornire nedorită, fără cascadă.
2. **Consolidarea sarcinii pe pvemini/pve1 a făcut incidentul un non-eveniment** pentru
   producție. În aprilie, căderea unui nod muta 4 containere pe o mașină de 16 GB și
   declanșa 3 ore de buclă OOM.
3. **Alertarea a funcționat** — prag de 5 minute, email livrat la 17:31 prin
   `mail.romfast.ro`, coadă goală, `status=sent`.
4. **Replicarea către pve1 nu a fost afectată** — a doua țintă și-a făcut treaba.

---

## Verificarea de la revenire — rezultate (2026-08-28 09:49)

Rulat [`verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1) din stația de admin:

| Verificare | Rezultat |
|---|---|
| Cauza căderii | **Cădere de rețea, nu de alimentare** — jurnalul continuă cu 58.454 de linii după 17:26:44 |
| Adaptor USB LAN | **Reseturi confirmate** la 16:01:45 și 17:26:41, cu re-enumerare `usb 2-3` |
| Semnături hardware | **Zero** — fără MCE, panic, temperatură peste prag, EDAC, erori de I/O |
| ZFS | `ONLINE`, fără erori de date, fără resilver |
| Cluster | **3 din 3 voturi**, marja de quorum refăcută |
| Replicare | se reia singură — `109-1 SYNCING`, restul `pending` |
| HA | LRM `idle` — normal, nodul nu are servicii asignate |
| SMART | fără `FAILED` pe discuri |
| Tailscale | serviciu pornit, dar **DELOGAT** — vezi Tier 1 |

### Trei defecte ale scriptului, găsite la prima rulare reală și reparate

1. **Fals pozitiv la semnăturile hardware.** Tiparele inițiale (`thermal`, `nmi`, `edac`,
   `BUG:`) prindeau linii normale de boot — „Registered thermal governor", „NMI watchdog:
   Enabled", „EDAC MC: Ver: 3.0.0" — și produceau un verdict de defect hardware care
   **contrazicea concluzia corectă din același bilanț**. Tiparele au fost strânse și
   filtrate prin `-p warning`; verificat pe nod: 0 potriviri.
2. **LRM `idle` raportat ca „stare neclară".** `idle` e starea normală a unui nod fără
   servicii HA. Acum e tratată ca atare — și, mai important, scriptul spune explicit că un
   LRM idle înseamnă **watchdog nearmat**, adică fix motivul pentru care căderea de la 17:26
   nu s-a auto-reparat.
3. **Tailscale raportat `[ok]` deși era delogat.** `systemctl is-active` întorcea `active`,
   dar `tailscale status` spunea `Logged out`. Verificarea se uită acum la starea reală.

---

## Plan de prevenție

### 🔴 Tier 1 — la repornirea nodului

**1. Tailscale pe pveelite**
Mort de 27 de zile. Fără el, orice incident viitor pe nodul ăsta cere din nou deplasare
fizică.
```bash
ssh root@10.0.20.202 "systemctl enable --now tailscaled && tailscale up && tailscale status"
```

**2. Mută rețeaua de pe adaptorul USB pe `eno1` — reparația de fond.**
`eno1` **există și e funcțional**, doar că nu are cablu: `Link detected: no`, driver
încărcat, `Supports Wake-on: pumbg`. Adaptorul USB e cauza a **două** incidente pe acest nod
(2026-04-20 și cel de față) și rămâne un punct unic de cedare pe magistrala USB.

Ordinea contează, altfel rămâi din nou fără rețea, cu drum până la nod:
```bash
# 1. Mută fizic cablul LAN din dongle-ul USB in portul eno1 de pe placa de baza.
# 2. De la CONSOLA fizica (nu prin SSH — reteaua pica in timpul operatiei):
sed -i 's/bridge-ports enx6c1ff71abe67/bridge-ports eno1/' /etc/network/interfaces
ifreload -a
ip -br link          # eno1 trebuie sa fie UP, vmbr0 UP
```
Dongle-ul USB rămâne ca rezervă, scos din `vmbr0`.

**3. Regulă de hotplug, dacă adaptorul USB rămâne în uz.**
Cauza reală nu e resetul USB în sine — e faptul că interfața recreată **nu e readăugată în
punte**. `auto enx...` în `/etc/network/interfaces` ridică interfața doar la boot;
`allow-hotplug` o ridică și la re-enumerare. Fără asta, orice reset USB scoate nodul din
rețea definitiv.

**4. Adresele MAC — consemnate acum, ca să nu se mai piardă.**

| Interfață | MAC | Wake-on-LAN |
|---|---|---|
| `eno1` (placă de bază) | `84:69:93:57:b2:ea` | `Supports: pumbg`, activ `g` |
| `enx6c1ff71abe67` (USB Realtek RTL8156B) | `6c:1f:f7:1a:be:67` | `Supports: pumbg`, activ `g` |

În timpul incidentului s-a pus întrebarea dacă nodul poate fi trezit cu un magic packet.
**Nu s-a putut nici măcar încerca:** intrarea ARP expirase peste tot — `ip neigh` pe pvemini
(`INCOMPLETE`) și pe pve1 (`FAILED`), tabela stației de admin, LXC-urile de pe LAN. Nodurile
au IP static, deci nu există lease DHCP, iar MAC-ul nu era consemnat nicăieri.

Concluzia, scrisă explicit ca să nu se reia discuția: **WoL nu ar fi ajutat oricum** — mașina
nu era oprită, ci pornită și fără rețea. Un magic packet nu are ce trezi. După mutarea pe
`eno1`, WoL devine însă realmente utilizabil, pentru că e placă integrată, alimentată în
soft-off — spre deosebire de un dongle USB.

**5. ~~Textul alertei — scos exportul NFS inexistent.~~ ALARMĂ FALSĂ, verificat 28.08.**
Se afirmase că `/opt/scripts/pveelite-down-alert.sh` menționează un export
`10.0.20.202:/mnt/pve/oracle-backups` care nu mai există, pentru că nu apare în
`storage.cfg`. **Exportul există și e viu** — nu e storage Proxmox, ci export NFS la nivel
de sistem către mașina de DR:

```
# /etc/exports pe pveelite — exportfs -v
/mnt/pve/oracle-backups  10.0.20.37(rw,sync,no_subtree_check,no_root_squash)
```

`nfs-server` e `active`, iar datasetul a primit backup-uri RMAN pe 28.08 la 10:11 (`L0_ROA_20260828`,
6 GB), imediat după revenirea nodului. **Textul alertei e corect, nu se atinge.** Lecția e de
metodă: absența din `storage.cfg` nu înseamnă absența exportului.

**5-bis. `ha-manager: command not found` în alerta de pe pveelite — REPARAT 28.08.**
`/opt/scripts/pvemini-down-alert.sh` rula din cron cu PATH minimal (`/usr/bin:/bin`), iar
`ha-manager` e în `/usr/sbin`. Secțiunea „HA status" ieșea goală la fiecare declanșare, tăcut.
Adăugat `export PATH=...` — la fel cum avea deja `pveelite-down-alert.sh`. Verificat cu
`env -i PATH=/usr/bin:/bin`: comanda se rezolvă și întoarce `quorum OK`.

### 🟡 Tier 2

**6. Detecția tăcerii — nodul a stat 16 ore căzut fără să afle nimeni.**
Alerta a funcționat corect la 17:31, dar apoi incidentul a rămas nesupravegheat peste noapte.
Mai grav: pe un nod **fără servicii HA**, watchdog-ul nu e armat, deci nu există niciun
mecanism care să repare sau măcar să semnaleze o cădere de rețea. Nodul rămâne pornit,
sănătos și invizibil. Merită o alertă de repetiție (nu doar una la început de incident) sau
un al doilea inel corosync pe `eno1`, care ar fi ținut nodul în cluster peste căderea USB.

**7. ~~`local-zfs` pe pvemini la 92 %.~~ REZOLVAT 28.08 — 93 % → 44 %.**
Nu era creștere organică. Replicarea `rpool/oracle-backups` (pveelite → pvemini, la 15 min)
**tăia snapshoturile doar pe sursă**:

```bash
KEEP_SNAPS=5   # rolling history on source side
```

Pe destinație nu curăța nimeni, niciodată. Din 25.04 se adunaseră **11.886 snapshoturi care
țineau 941 GB** — pe nodul cu toată producția. Problema era invizibilă de pe pveelite, unde
datasetul arăta cuminte, cu 6 snapshoturi.

Reparat în [`zfs-replicate-oracle-backups.sh`](../../vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh):
`KEEP_SNAPS_DEST=288` (288 × 15 min = 72 h de puncte de recuperare pe destinație, față de
75 de minute pe sursă). Restanța ștearsă pe interval, cu dry-run înainte:

```
pvemini rpool:  93 % / 118 G liberi  ->  44 % / 1,01 T liberi
rpool/oracle-backups:  955 G  ->  45,3 G     snapshoturi:  11.886  ->  288
```

Verificat în producție: rularea cron de la 11:15 a adăugat un snapshot și a tăiat cel mai
vechi — destinația a rămas fix la 288.

> **Capcană, dacă vreodată se rescrie curățarea:** ștergerea pe interval (`zfs destroy
> ds@a%b`) prinde **toate** snapshoturile dintre capete, inclusiv `@failback_` / `@init_`,
> nu doar cele cu prefixul căutat. De aceea scriptul șterge câte unul (`xargs -n1`), unde
> oricum e un singur snapshot pe rulare; intervalul s-a folosit o singură dată, manual,
> după ce s-a verificat că pe destinație nu există niciun snapshot non-`repl_`.

---

## Referințe

- [Incident 2026-04-20 — cluster outage pvemini + pveelite](2026-04-20-cluster-outage.md) —
  precedentul de „nod care moare fără niciun log"
- [Incident 2026-04-30 — Kingston backup SSD hang](2026-04-30-pvemini-backup-ssd-hang.md)
- [Oprire planificată a clusterului](../docs/oprire-planificata-cluster.md)
- [Failover și replicare](../failover/README.md)
- Script de verificare: [`../scripts/verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1)