From 5e31d975dfe6d9c414876e58c0ce2c23e129069d Mon Sep 17 00:00:00 2001 From: Marius Date: Fri, 28 Aug 2026 09:55:10 +0300 Subject: [PATCH] docs(cluster): pveelite - cauza confirmata, resetul adaptorului USB LAN Nodul nu s-a oprit niciodata. La verificarea de azi avea uptime 17h46m, cu boot pornit la 27.08 ora 16:03:06 - a mers toata noaptea, fara retea. Jurnalul continua cu 58.454 de linii dupa 17:26:44, ceea ce inchide definitiv discutia alimentare vs retea. Vinovatul, din jurnalul kernel: Realtek RTL8156B (0bda:8156, driver r8152) pe usb 2-3. La 16:01:45 si la 17:26:41 adaptorul s-a resetat si a fost re-enumerat. Kernelul sterge interfata si o recreeaza - dar nimeni nu o readauga in vmbr0 si nu o ridica, pentru ca nu exista regula de hotplug. Din acel moment masina merge perfect si e invizibila in retea. Partea care merita retinuta e de ce la 16:01 si-a revenit si la 17:26 nu. La 16:01 LRM-ul HA era activ, deci watchdog-ul era armat: pierderea retelei a dus la pierderea quorumului, watchdog-mux a expirat la 16:02:39 si a resetat masina la 16:02:44 - repornire care a readus reteaua din intamplare, pentru ca la boot interfetele se ridica prin auto. La 17:26 fence-ul mutase deja vm:109 pe pvemini, LRM-ul era idle, watchdog-ul nearmat. Nimic nu a mai repornit masina. Singurul lucru care "repara" defectul asta era un efect secundar, nu un mecanism proiectat - pe un nod fara servicii HA, aceeasi defectiune devine permanenta si tacuta. Reparat cu ifreload -a de la consola, la 09:49. Restul verificarii e curat: ZFS ONLINE fara erori, cluster 3/3, SMART fara FAILED, replicarea se reia singura. Reparatia de fond intra in Tier 1: eno1 exista si e functional, doar ca nu are cablu (Link detected: no). Adaptorul USB e cauza a doua incidente pe nodul asta. Am scris si ordinea operatiilor, pentru ca inversata te lasa fara retea cu drum pana la nod. Prima rulare reala a scriptului a scos la iveala trei defecte ale lui, toate reparate aici: - tiparele de semnatura hardware prindeau linii normale de boot ("Registered thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0") si produceau un verdict de defect hardware care contrazicea concluzia corecta din acelasi bilant. Strans tiparele si filtrat prin -p warning; verificat pe nod: 0 potriviri. - LRM idle era raportat ca "stare neclara". E starea normala a unui nod fara servicii HA - iar scriptul spune acum explicit ca idle inseamna watchdog nearmat, adica exact motivul pentru care caderea de la 17:26 nu s-a auto-reparat. - Tailscale era raportat [ok] desi e delogat: systemctl is-active zice active, dar tailscale status zice "Logged out". De aici si cele 27 de zile de offline. Consemnat si raspunsul la intrebarea cu magic packet, cu MAC-urile ambelor interfete, ca sa nu se reia: WoL nu ar fi ajutat oricum, masina nu era oprita. Dupa mutarea pe eno1 devine insa realmente utilizabil. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8 --- proxmox/README.md | 2 +- proxmox/cluster/README.md | 2 +- .../incidents/2026-08-27-pveelite-down.md | 180 +++++++++++++----- proxmox/cluster/scripts/verifica-pveelite.ps1 | 42 +++- 4 files changed, 169 insertions(+), 57 deletions(-) diff --git a/proxmox/README.md b/proxmox/README.md index 622ec7f..4564ade 100644 --- a/proxmox/README.md +++ b/proxmox/README.md @@ -13,7 +13,7 @@ proxmox/ │ │ ├── 2026-04-20-cluster-outage.md # Cascadă OOM pveelite + USB LAN watchdog │ │ ├── 2026-04-30-pvemini-backup-ssd-hang.md # Kingston SSD hang → emergency mode │ │ ├── 2026-07-31-lxc110-dns-tailscale-oom.md # DNS mort (Tailscale logout) + zram pe pve1 -│ │ └── 2026-08-27-pveelite-down.md # DESCHIS — pveelite mort, suspiciune alimentare/hardware +│ │ └── 2026-08-27-pveelite-down.md # Reset adaptor USB LAN → pveelite fără rețea 16h │ └── ups/ # Sistem UPS pentru cluster │ ├── README.md │ ├── docs/ diff --git a/proxmox/cluster/README.md b/proxmox/cluster/README.md index 7283287..10b5799 100644 --- a/proxmox/cluster/README.md +++ b/proxmox/cluster/README.md @@ -870,7 +870,7 @@ swapon -a - **2026-04-20 Cluster Outage:** `incidents/2026-04-20-cluster-outage.md` — post-mortem complet + plan prevenție - **2026-04-30 pvemini backup SSD hang:** `incidents/2026-04-30-pvemini-backup-ssd-hang.md` — Kingston thermal hang → emergency mode - **2026-07-31 LXC 110 DNS + OOM:** `incidents/2026-07-31-lxc110-dns-tailscale-oom.md` — logout Tailscale → DNS mort; zram instalat pe pve1 -- **2026-08-27 pveelite down:** `incidents/2026-08-27-pveelite-down.md` — **DESCHIS** — nodul dispare la 16:01, revine, apoi cade definitiv la 17:26. Două ipoteze hardware: alimentare sau adaptorul USB de rețea. Verificare la revenire: `scripts/verifica-pveelite.ps1` +- **2026-08-27 pveelite fără rețea 16h:** `incidents/2026-08-27-pveelite-down.md` — resetul adaptorului USB LAN scoate interfața din `vmbr0` și nu o mai readaugă nimeni; mașina merge, dar e invizibilă. Fix: `ifreload -a`. De fond: mutarea pe `eno1`. Verificare: `scripts/verifica-pveelite.ps1` ### LXC Containers - **LXC 108 - Oracle Database:** `../lxc108-oracle/README.md` diff --git a/proxmox/cluster/incidents/2026-08-27-pveelite-down.md b/proxmox/cluster/incidents/2026-08-27-pveelite-down.md index ae35b07..9db07f3 100644 --- a/proxmox/cluster/incidents/2026-08-27-pveelite-down.md +++ b/proxmox/cluster/incidents/2026-08-27-pveelite-down.md @@ -1,10 +1,12 @@ -# Incident 2026-08-27 — pveelite cade definitiv la 4 ore după repornirea planificată a clusterului +# 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) -**Status:** **DESCHIS** — nodul e inaccesibil, necesită intervenție fizică +**Resolved:** 2026-08-28 09:49 EEST (`ifreload -a` de la consola fizică) +**Status:** **REZOLVAT** — cauză confirmată din jurnal. Rămâne o acțiune de fond: +mutarea rețelei de pe adaptorul USB pe `eno1` **Author:** Claude Code (mmarius28@gmail.com) --- @@ -51,7 +53,64 @@ sau cedarea adaptorului USB de rețea. Ce se poate afirma acum: - **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 +### 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. + +--- + +### 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 @@ -117,7 +176,7 @@ Dacă da, mașina a mers mai departe și a căzut doar rețeaua. --- -## Starea la momentul investigației (21:22) +## Starea la momentul investigației (27.08, ora 21:22 — înainte de a se cunoaște cauza) ### Cluster @@ -186,30 +245,35 @@ Merită consemnat, pentru că sunt exact lucrurile reparate după aprilie: --- -## Ce urmează — verificare la repornirea nodului +## Verificarea de la revenire — rezultate (2026-08-28 09:49) -Nodul se pornește fizic. Imediat după ce revine, se rulează -[`verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1) din stația de admin: +Rulat [`verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1) din stația de admin: -```powershell -.\proxmox\cluster\scripts\verifica-pveelite.ps1 -``` +| 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 | -Scriptul acoperă, în ordine: +### Trei defecte ale scriptului, găsite la prima rulare reală și reparate -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. -3. **Revenirea în cluster** — quorum 3/3, `pvecm status`, `/etc/pve/.members`. -4. **Repornirea replicării** — `pvesr status`, FailCount înapoi la 0, toate cele 9 job-uri - recuperate. Nu necesită intervenție manuală; se reiau singure. -5. **HA** — LRM pveelite `active`, nu `dead`. -6. **SMART pe discuri** — temperaturi și erori, dat fiind precedentul Kingston. -7. **Tailscale** — repornit și `Online`, ca să existe acces out-of-band data viitoare. +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ă. --- @@ -224,40 +288,58 @@ fizică. ssh root@10.0.20.202 "systemctl enable --now tailscaled && tailscale up && tailscale status" ``` -**2. Verdictul hardware, scris explicit.** -Dacă `journalctl -b -1` nu conține nimic înainte de 17:26 (tăcere completă, ca la pvemini pe -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". +**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. -**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: +Ordinea contează, altfel rămâi din nou fără rețea, cu drum până la nod: ```bash -ssh root@10.0.20.202 "ip -br link; ethtool | grep -iE 'Wake-on|Supports Wake'" +# 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 ``` -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. +Dongle-ul USB rămâne ca rezervă, scos din `vmbr0`. -**4. Textul alertei — scos exportul NFS inexistent.** +**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.** `/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 +### 🟡 Tier 2 -**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. +**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. -**6. `local-zfs` pe pvemini la 92 %.** +**7. `local-zfs` pe pvemini la 92 %.** Separat de incident, dar pe același nod pe care stă acum toată producția. --- diff --git a/proxmox/cluster/scripts/verifica-pveelite.ps1 b/proxmox/cluster/scripts/verifica-pveelite.ps1 index bb39c7f..9814d6b 100644 --- a/proxmox/cluster/scripts/verifica-pveelite.ps1 +++ b/proxmox/cluster/scripts/verifica-pveelite.ps1 @@ -67,8 +67,18 @@ $IncidentStart = '2026-08-27 13:20' # boot-ul de dupa oprirea planificata # Tipare de eroare hardware in jurnalul kernel. Daca NICIUNUL nu apare, verdictul # inclina spre alimentare (masina nu apuca sa scrie nimic inainte sa dispara). -$TipareHw = 'mce|machine check|hardware error|thermal|temperature above|critical temp|' + - 'nmi|kernel panic|oops|BUG:|edac|pcieport.*error|ATA bus error|I/O error' +# +# Tiparele sunt deliberat STRANSE. Prima versiune cauta 'thermal', 'nmi', 'edac', +# 'BUG:' si a raportat fals pozitiv la rularea din 28.08: liniile normale de boot +# ("Registered thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0", +# "DPC: error containment capabilities") au declansat un verdict de defect hardware +# care contrazicea concluzia corecta. Un fals pozitiv aici nu e zgomot inofensiv - +# trimite pe pista gresita exact cand trebuie luata o decizie. +$TipareHw = 'Machine Check|mce: |Hardware Error|Uncorrected error|' + + 'temperature above threshold|critical temperature|' + + 'Kernel panic|Oops: |watchdog: BUG: soft lockup|' + + 'EDAC.*(CE|UE) .*error|AER: .*error|Buffer I/O error|' + + 'blk_update_request.*I/O error|ATA bus error' $ReplJobs = 9 # 9 job-uri de replicare au pveelite ca tinta @@ -241,14 +251,16 @@ if ($usbEv) { # Cautarea tintita de semnaturi hardware, peste toate boot-urile de ieri. Write-Host "" Write-Info "--- semnaturi hardware in jurnal (MCE / termic / panic / EDAC) ---" +# -p warning taie zgomotul de boot inainte de a ajunge la grep: mesajele de +# inregistrare a guvernatorilor termici, EDAC si NMI sunt de nivel info. $hw = Invoke-Node -Node pveelite -Command ` - "journalctl --since '$IncidentStart' --no-pager | grep -iE '$TipareHw' | tail -25" + "journalctl --since '$IncidentStart' -p warning --no-pager | grep -E '$TipareHw' | tail -25" $verdictHw = $false if ($hw) { Write-Bad "GASIT - nodul a lasat urme de eroare hardware:" $hw | ForEach-Object { Write-Host " $_" -ForegroundColor Red } - Add-Rezultat 'Cauza caderii' 'bad' 'semnaturi hardware in jurnal - vezi liniile de mai sus' + Add-Rezultat 'Semnaturi hardware' 'bad' 'erori hardware in jurnal - vezi liniile de mai sus' $verdictHw = $true } else { Write-Info "niciun MCE, eroare termica, panic sau EDAC in jurnal" @@ -354,6 +366,16 @@ $ha | ForEach-Object { Write-Info $_ } if ($ha -match 'lrm pveelite \(active') { Write-Ok "LRM pveelite activ" Add-Rezultat 'HA' 'ok' 'LRM activ' +} elseif ($ha -match 'lrm pveelite \(idle') { + # 'idle' e starea normala pentru un nod fara servicii HA asignate - si e + # exact cazul lui pveelite dupa ce fence-ul a mutat vm:109 pe pvemini. + # ATENTIE: cu LRM idle, watchdog-ul NU e armat. La 16:01 watchdog-ul a + # repornit nodul si i-a readus reteaua; la 17:26, fara el, nodul a ramas + # pornit si fara retea pana dimineata. + Write-Ok "LRM pveelite idle - normal, nodul nu are servicii HA asignate" + Write-Info "Consecinta: watchdog-ul nu e armat, deci o cadere de retea nu se" + Write-Info "mai auto-repara prin reboot, cum s-a intamplat la 16:01." + Add-Rezultat 'HA' 'ok' 'LRM idle (fara servicii asignate) - watchdog nearmat' } elseif ($ha -match 'lrm pveelite.*old timestamp') { Write-Warn "LRM pveelite inca 'dead' - poate dura un minut dupa boot; reverifica" Add-Rezultat 'HA' 'warn' "LRM inca 'old timestamp'" @@ -406,8 +428,16 @@ Write-Info "viitoare a nodului cere din nou deplasare fizica." $ts = Invoke-Node -Node pveelite -Command 'systemctl is-active tailscaled 2>/dev/null; tailscale status 2>&1 | head -3' $ts | ForEach-Object { Write-Info $_ } -if ($ts -match '^active') { - Write-Ok "tailscaled activ" +if ($ts -match 'Logged out|Stopped') { + # Capcana: serviciul poate fi 'active' si totusi inutilizabil. Exact asa arata + # pveelite la 28.08 - tailscaled pornit, dar delogat, ceea ce explica cele 27 + # de zile de "offline". A verifica doar systemctl is-active da un fals OK. + Write-Bad "tailscaled ruleaza, dar e DELOGAT - nu exista acces out-of-band" + Write-Info "Reautentificare (cere deschiderea link-ului afisat intr-un browser):" + Write-Info " ssh root@$($NodeIp.pveelite) 'tailscale up'" + Add-Rezultat 'Tailscale' 'bad' 'delogat - fara acces out-of-band' +} elseif ($ts -match '^active') { + Write-Ok "tailscaled activ si autentificat" Add-Rezultat 'Tailscale' 'ok' 'activ' } else { Write-Warn "tailscaled NU e activ - reactiveaza-l acum:"