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

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

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

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:

# 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ă:

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: 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 — precedentul de „nod care moare fără niciun log"
• Incident 2026-04-30 — Kingston backup SSD hang
• Oprire planificată a clusterului
• Failover și replicare
• Script de verificare: ../scripts/verifica-pveelite.ps1