feat(retea): retea dedicata de cluster pe switch separat, vmbr0 mutat de pe USB

Replicarea, migrarea si backup-ul NFS trec acum pe o insula 10.10.10.0/24
(switch 1, fara gateway), iar vmbr0 a fost mutat de pe dongle-urile USB
Realtek pe placile Intel onboard.

Castigul nu e viteza. Masurat: replicarea mergea deja la 272 MB/s, adica
~95% din firul de 2.5G, iar criptarea SSH nu era limita. 10G e imposibil
cat timp pve1 si pveelite au doar dongle-uri USB de 2.5G si niciun slot
PCIe liber; placa X710 din pvemini e SFP+ cu cage-urile goale, iar switch-ul
are doar porturi RJ45. Replicarea ruleaza si strict secvential
(Replication.pm:138, un singur lock, fara fork), deci nici agregarea de
linkuri nu ar ajuta.

Castigul e ca IP-ul de cluster si corosync ring0 nu mai stau pe dongle-ul
USB care a lasat pveelite invizibil 16 ore pe 2026-08-27 - fara sa fie
nevoie de vreo modificare in corosync.conf, fiindca IP-urile au ramas
aceleasi. Plus izolarea replicarii de productie, WoL persistat pe onboard,
si o cale out-of-band catre noduri prin insula.

Aplicat si verificat: cvorum pe 3 pe tot parcursul, 262-273 MB/s pe insula,
job real de replicare confirmat cu numarare de octeti pe interfete
(4959 KB pe insula vs 1553 KB pe productie), NFS activ si scriibil.

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

proxmox/cluster/README.md

@@ -870,7 +870,14 @@ 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 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`
+- **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`. **Reparație de fond aplicată pe 2026-08-29:** `vmbr0` a fost mutat pe `eno1` (Intel onboard) pe pve1 și pveelite — vezi `docs/switch-2.5g-dedicat-noduri.md`. Verificare: `scripts/verifica-pveelite.ps1`
+
+### Rețea
+- **Rețea dedicată de cluster pe switch separat (aplicat 2026-08-29):**
+  `docs/switch-2.5g-dedicat-noduri.md` — harta celor două switch-uri cu porturi și IP-uri,
+  insula `10.10.10.0/24` pentru replicare/migrare/backup, mutarea lui `vmbr0` de pe dongle-urile
+  USB pe plăcile Intel onboard, plus măsurătorile care arată că **nu mai există viteză de
+  câștigat** (2.5G e plafon dur, replicarea rulează la 95% din fir)
 
 ### LXC Containers
 - **LXC 108 - Oracle Database:** `../lxc108-oracle/README.md`

proxmox/cluster/docs/switch-2.5g-dedicat-noduri.md

@@ -0,0 +1,342 @@
+# Switch 2.5GbE suplimentar — porturi fizice conectate pe cele 3 noduri
+
+**Data verificării:** 2026-08-29 (verificat de trei ori — vezi secțiunea de măsurători)
+**Autor:** Claude Code (mmarius28@gmail.com)
+**Status: TERMINAT pe 2026-08-29.** Rețeaua dedicată de cluster `10.10.10.0/24` e activă pe toate
+3 nodurile, `vmbr0` a fost mutat pe interfețele onboard, uplink-ul dintre switch-uri a fost scos,
+iar replicarea și backup-ul NFS trec verificat pe insulă. Singurele lucruri rămase sunt
+opționale — vezi „Ce a rămas de făcut".
+
+---
+
+## Harta switch-urilor — starea finală, 2026-08-29
+
+**Switch 1 — insula de cluster `10.10.10.0/24`** (2×10G RJ45 pe p5/p6, 4×2.5G pe p1–p4).
+Fără router, fără gateway. Toate cele 3 legături negociază **2.5 Gbps**.
+
+| Port | Viteză port | Conectat la | IP |
+|---|---|---|---|
+| p1 | 2.5G | liber *(fostul uplink către switch 2, scos)* | — |
+| p2 | 2.5G | pvemini — `enp87s0` (Intel I226) | `10.10.10.201` |
+| p3 | 2.5G | pve1 — `enx6c1ff759e2cb` (dongle USB 2.5G) | `10.10.10.200` |
+| p4 | 2.5G | pveelite — `enx6c1ff71abe67` (dongle USB 2.5G) | `10.10.10.202` |
+| p5 | **10G** | **liber** — rezervat pentru un PBS/NAS cu 10GBase-T | — |
+| p6 | **10G** | **liber** — rezervat pentru un PBS/NAS cu 10GBase-T | — |
+
+Ambele porturi de 10G sunt libere **pe insulă** — singurul loc din infrastructură unde 10G ar
+aduce ceva real: un PBS/NAS cu 10GBase-T pus acolo ar putea primi backup de la toate 3 nodurile
+simultan, la 2.5G fiecare, fără să se sufoce reciproc.
+
+**Switch 2 — producție `10.0.20.0/24`** (8×2.5G):
+
+| Conectat la | Interfață | IP |
+|---|---|---|
+| pve1 | `eno1` (Intel I219-LM, 1G) | `vmbr0` `10.0.20.200` |
+| pvemini | `enp90s0` (Intel I226, 2.5G) | `vmbr0` `10.0.20.201` |
+| pveelite | `eno1` (Intel I219-LM, 1G) | `vmbr0` `10.0.20.202` |
+| router | — | `10.0.20.1` (link 1G, internet 500 Mbps) |
+| stația de administrare | — | — |
+| access point | — | — |
+
+Cele două switch-uri **nu mai sunt legate între ele**. Switch 1 e o insulă fără gateway; switch 2
+are tot ce are nevoie de internet. Switch 1 are 3 porturi libere (p1 plus **ambele porturi de
+10G**), switch 2 are 2 porturi libere.
+
+**Hardware, pentru referință:** pvemini e un Minisforum MS-01 — 2× SFP+ 10G (placa Intel X710,
+cage-uri goale) și 2× RJ45 2.5G (Intel I226). Nu are port RJ45 de 10G. pve1 și pveelite au
+onboard Intel I219-LM (1G) plus câte un dongle USB Realtek r8152 (2.5G).
+
+---
+
+## Ce am verificat
+
+Switch-ul nou a fost conectat la portul de rezervă (neutilizat) de pe fiecare nod. Porturile
+erau setate `iface ... inet manual` fără `auto`, deci niciodată ridicate la boot — de-aia nu
+arătau link la prima verificare. Ridicate manual (`ip link set <if> up`), linkul a apărut după
+~5-10s de negociere:
+
+| Nod | Interfață | Chipset | Viteză max NIC | Link negociat | MAC |
+|---|---|---|---|---|---|
+| pve1 (10.0.20.200) | `eno1` | Intel I219-LM | **1 Gbps** (nu suportă 2.5G) | 1000 Mbps Full Duplex | `fc:3f:db:0a:0d:d8` |
+| pvemini (10.0.20.201) | `enp90s0` | Intel I226-V | 2.5 Gbps | **2500 Mbps Full Duplex** | `58:47:ca:7d:51:3c` |
+| pveelite (10.0.20.202) | `eno1` | Intel I219-LM | **1 Gbps** (nu suportă 2.5G) | 1000 Mbps Full Duplex | `84:69:93:57:b2:ea` |
+
+**Nicio interfață nu are IP.** Sunt doar `manual`, ridicate acum administrativ pentru test —
+**nepersistat** în `/etc/network/interfaces` (revine la `DOWN` la următorul reboot dacă nu se
+adaugă `auto` + configurare).
+
+### Constatare importantă, neaflată până acum
+
+Doar **pvemini** poate profita cu adevărat de 2.5G pe rețeaua nouă — placa lui de rezervă
+(I226-V) suportă viteza integral. **pve1 și pveelite au NIC-uri de rezervă vechi (I219-LM),
+limitate la 1 Gbps**, indiferent de switch. Rețeaua dedicată va fi deci mixtă: 2.5G doar pe
+segmentul pvemini, 1G pe segmentele pve1/pveelite — tot un upgrade real față de starea actuală
+(vezi mai jos), dar nu 2.5G capăt la capăt.
+
+## Constatare colaterală: pve1 rulează rețeaua principală tot pe adaptor USB
+
+Investigând porturile de rezervă, a ieșit la iveală ceva nedocumentat: **nu doar pveelite**
+rulează `vmbr0` (IP-ul principal de cluster) pe un dongle USB Realtek — **și pve1**:
+
+| Nod | Interfața din `vmbr0` (producție) | Tip |
+|---|---|---|
+| pve1 | `enx6c1ff759e2cb` | USB 2.5G (Realtek r8152) |
+| pveelite | `enx6c1ff71abe67` | USB 2.5G (Realtek r8152) |
+| pvemini | `enp87s0` | **Onboard** (Intel I226, integrat pe placă) |
+
+Incidentul [2026-08-27](../incidents/2026-08-27-pveelite-down.md) a documentat defectul strict
+pentru pveelite (reset spontan al adaptorului USB → interfața nu se readaugă în punte → nod
+invizibil 16 ore). **Același risc structural există și pe pve1** — chipset identic (r8152),
+aceeași lipsă de regulă hotplug în `/etc/network/interfaces`. Nu s-a manifestat încă pe pve1,
+dar asta nu înseamnă că nu poate.
+
+---
+
+## Măsurători și corecții — a doua verificare, 2026-08-29
+
+Prima verificare a lăsat deschisă ipoteza că se poate câștiga viteză prin 10G pe pvemini.
+**Măsurătorile au infirmat-o.** Datele de mai jos sunt scumpe de re-obținut; nu le redescoperi.
+
+### Replicarea rulează deja la viteza firului
+
+Test pe exact calea folosită de `pvesr` (flux SSH criptat, `dd` 3 GB prin `ssh ... cat >/dev/null`):
+
+| Traseu | Debit măsurat |
+|---|---|
+| pvemini → pve1 | **272 MB/s** (2.18 Gbps) |
+| pvemini → pveelite | **274 MB/s** (2.19 Gbps) |
+
+Maximul teoretic pe 2.5GbE după overhead TCP e ~285 MB/s. Suntem la **~95% din fir**.
+Criptarea SSH **nu** e limita (i9-12900H cu AES-NI) — firul e. Durata replicării incrementale
+în `pve-replication-state.json`: **3–8 secunde**.
+
+Corolar: `migration: type=insecure` aduce sub 5%. Se ia pentru că e gratis pe o rețea izolată,
+nu pentru viteză.
+
+### Replicarea e strict secvențială — agregarea de linkuri nu ajută
+
+`/usr/share/perl5/PVE/API2/Replication.pm:138` (`run_jobs`) iterează joburile într-un `while`
+sub un singur `PVE::Tools::lock_file($pvesr_lock_path)`, **fără fork**. Nu există joburi
+paralele pe un nod, oricât de multe ar cădea în aceeași fereastră `*/15`.
+
+Consecință: un singur flux TCP la un moment dat. LACP hashuiește un flux pe un singur link
+(câștig zero), iar `balance-rr` produce reordonare de pachete și de obicei scade debitul.
+**Niciun bond, niciun dongle suplimentar nu aduce nimic.**
+
+### Placa X710 de 10G e o fundătură
+
+```
+i40e 0000:02:00.0 enp2s0f0np0: Cannot read module EEPROM memory. No module connected.
+i40e 0000:02:00.1 enp2s0f1np1: Cannot read module EEPROM memory. No module connected.
+```
+
+Ambele cage-uri SFP+ sunt goale. Porturile de 10G ale switch-ului principal sunt **RJ45**, deci
+X710-ul (SFP+) ar cere transceiver SFP+ → 10GBase-T: ~2.5W consum într-un cage care livrează
+mult mai puțin, plus whitelist de module pe controlerele Intel. Combinație cunoscută ca
+nefuncțională, 250–450 lei ca să afli asta.
+
+Și chiar dacă ar merge, n-ar folosi la nimic: **pve1 și pveelite sunt plafonate hardware la
+2.5G** (dongle USB Realtek; onboard-urile I219 fac 1G) și n-au slot PCIe liber. Receptorul
+oprește transferul, indiferent ce are emițătorul.
+
+### pvemini nu are porturi RJ45 de 10G
+
+```
+enp87s0 / enp90s0:  Supported link modes: ... 2500baseT/Full    (driver igc = Intel I226)
+```
+
+Nu apare `5000baseT` sau `10000baseT`. Portul din switch poate fi 10GBase-T — NIC-ul negociază
+2.5G și acolo se oprește. Singurul hardware de 10G din pvemini rămâne X710-ul, nefolosibil.
+
+### Concluzie
+
+**Nu mai există viteză de câștigat pe replicare/migrare cu hardware-ul actual.** Ce se poate
+câștiga e fiabilitate (scoaterea IP-ului de cluster de pe dongle-ul USB) și izolare (traficul
+de replicare/backup separat de producție).
+
+---
+
+## De ce insula e pe switch 1 și nu pe switch 2
+
+Prima variantă a planului punea insula de cluster pe switch 2 (cel de 8 porturi). **Constrângerea
+care a răsturnat-o:** stația de administrare și access point-ul sunt pe switch 2, deci switch 2
+nu poate fi izolat — s-ar tăia internetul la amândouă. Rezultă că insula trebuie să fie switch 1,
+iar producția pe switch 2.
+
+Consecință fericită: fiecare nod avea deja câte un cablu în fiecare switch, deci **nu s-a mutat
+niciun cablu de nod** — s-a schimbat doar ce rol are fiecare interfață. Pe pvemini nici măcar nu
+s-au inversat cabluri: `vmbr0` a trecut de pe `enp87s0` pe `enp90s0`, iar `enp87s0` (deja în
+switch 1) a primit IP-ul de pe insulă.
+
+Ce s-a câștigat:
+
+- **management + corosync ring0 trec de pe dongle-ul USB Realtek pe Intel-ul onboard** — exact
+  componenta care a lăsat pveelite mort 16 ore pe 27 august nu mai ține IP-ul de cluster;
+- replicarea rămâne la aceiași 2.5G, dar **izolată** de traficul de producție;
+- `eno1` ajunge în LAN-ul de producție, pe același segment cu stația de admin — **WoL** merge
+  direct (dongle-urile USB nu suportă WoL, pierd alimentarea la oprire);
+- **cale out-of-band nouă:** pvemini ajunge la pve1/pveelite pe `10.10.10.0/24` fără gateway.
+  Dacă `eno1` sau portul din switch cedează la un nod, ai SSH la el din pvemini.
+
+Ce plătești: producția scade la 1G pe pve1/pveelite. Acolo rulează 101 minecraft, 110 moltbot,
+109 Windows DR — niciunul nu cere mai mult, iar internetul e oricum 500 Mbps.
+
+**Bonus:** porturile de 10G RJ45 (5 și 6) ajung pe insula de cluster. Mutând dongle-ul lui pve1
+de pe portul 6 pe portul 2 (2.5G, liber) se eliberează ambele porturi de 10G pe rețeaua de
+replicare — singurul loc din infrastructură unde 10G ar aduce ceva real: un viitor PBS/NAS cu
+10GBase-T ar putea primi backup de la toate 3 nodurile simultan, la 2.5G fiecare.
+
+---
+
+## Ce s-a aplicat efectiv, 2026-08-29
+
+Cheia execuției fără deplasare la consolă: **cât timp uplink-ul din p1 există, cele două
+switch-uri sunt un singur domeniu L2**, deci mutarea lui `vmbr0` de pe o interfață pe alta a
+nodului rămâne accesibilă prin uplink. Fiecare nod a fost modificat cu o **plasă de siguranță**:
+un timer `systemd-run --on-active=180` care readucea configurația veche dacă nodul devenea
+inaccesibil, dezarmat manual după verificare.
+
+### 1. sysctl ARP — toate 3 nodurile
+
+`/etc/sysctl.d/99-cluster-arp.conf`:
+
+```
+net.ipv4.conf.all.arp_ignore = 1
+net.ipv4.conf.all.arp_announce = 2
+```
+
+Erau `0`/`0`. Obligatoriu cât timp cele două subrețele împart un domeniu L2, altfel replicarea
+poate lua tăcut calea lentă. După scoaterea uplink-ului devin inutile, dar rămân puse.
+
+### 2. `/etc/network/interfaces` — toate 3 nodurile
+
+Backup pe fiecare nod: `/etc/network/interfaces.bak-2026-08-29` și `/root/interfaces.rollback`.
+
+| Nod | `vmbr0` (producție) | interfața de insulă |
+|---|---|---|
+| pvemini | `bridge-ports enp90s0` | `auto enp87s0` → `10.10.10.201/24` |
+| pve1 | `bridge-ports eno1` | `auto enx6c1ff759e2cb` → `10.10.10.200/24` |
+| pveelite | `bridge-ports eno1` | `auto enx6c1ff71abe67` → `10.10.10.202/24` |
+
+Interfețele de insulă sunt **fără punte și fără gateway**.
+
+**WoL persistent:** `post-up /sbin/ethtool -s <if> wol g || true` pe `vmbr0` la fiecare nod (și
+pe `enp87s0` la pvemini). `|| true` e intenționat — un `ethtool` eșuat nu trebuie să blocheze
+ridicarea interfeței. Nu s-a pus pe dongle-urile USB: nu păstrează alimentarea la oprire, deci
+WoL pe ele n-ar face nimic. Bitul din BIOS cere în continuare acces fizic.
+
+### 3. NFS — `/etc/exports` pe pvemini
+
+Backup: `/etc/exports.bak-2026-08-29`. Subrețeaua insulei a fost adăugată **înainte** de
+repointare, altfel montarea ar fi fost refuzată:
+
+```
+/mnt/backup 10.0.20.0/24(rw,sync,no_subtree_check,no_root_squash) 10.10.10.0/24(rw,sync,no_subtree_check,no_root_squash)
+```
+
+### 4. `/etc/pve/storage.cfg`
+
+Backup: `/root/storage.cfg.bak-2026-08-29` pe pvemini. `backup-pvemini-nfs` → `server
+10.10.10.201`. Storage-ul `backup-nfs` (dezactivat) a rămas intenționat pe `10.0.20.201`.
+Montările vechi au fost demontate și refăcute — verificat `clientaddr=10.10.10.200/202`.
+
+### 5. `/etc/pve/datacenter.cfg`
+
+Backup: `/root/datacenter.cfg.bak-2026-08-29` pe pvemini.
+
+```
+ha: shutdown_policy=freeze
+migration: network=10.10.10.0/24,type=insecure
+```
+
+### Verificări după aplicare
+
+- `pvecm status` — cvorat, 3 voturi, pe tot parcursul;
+- guest-urile au rămas în punte (Oracle LXC 108 răspunde la ping);
+- ping reciproc pe `10.10.10.x` între toate 3 nodurile — OK;
+- debit pe insulă: **pvemini → pve1 267 MB/s**, **pvemini → pveelite 273 MB/s** — identic cu cel
+  de pe producție înainte de mutare, deci nu s-a pierdut nimic;
+- NFS activ și scriibil de pe ambele noduri prin insulă;
+- `pvesr run --id 108-0` cu numărare de octeți pe interfețe: **4959 KB pe insulă (`enp87s0`) vs
+  1553 KB pe producție (`enp90s0`)** — fluxul de date merge pe rețeaua dedicată, pe producție
+  rămâne doar canalul de control.
+
+### Capcană evitată: cheile SSH pentru IP-urile noi
+
+Un `ssh 10.10.10.200` manual eșuează cu *Host key verification failed* — cheile nu sunt cunoscute
+pentru IP-urile de pe insulă. **Replicarea nu e afectată:** `PVE/SSHInfo.pm:70` construiește
+comanda cu `-o HostKeyAlias=<nume_nod>`, deci cheia e căutată după numele nodului, nu după IP.
+Nu trebuie adăugat nimic în `known_hosts`.
+
+---
+
+## Ce a rămas de făcut
+
+Nimic obligatoriu. Uplink-ul a fost scos și `enp87s0` mutat de pe p5 pe p2 — verificat după
+fiecare pas: link 2500 Mbps, ping pe toată insula, **262 / 272 MB/s**, job real de replicare
+(`171-0`) încheiat cu succes, NFS `active` pe ambele noduri, cvorum pe 3.
+
+Opționale, în ordinea valorii:
+
+1. **corosync ring1** pe `10.10.10.0/24` — vezi mai jos, cere fereastră dedicată.
+2. **MTU 9000** pe segmentul dedicat — de testat, nu se știe dacă switch-ul suportă.
+3. **Test la reboot.** Configurația nu a fost validată printr-o repornire. Dongle-urile USB au
+   acum `auto` în loc să fie porturi de punte; dacă la boot USB-ul se enumeră târziu, interfața
+   de insulă poate rămâne neconfigurată. Chiar și atunci nodul pornește normal pe producție și
+   doar replicarea are de suferit — invers față de cum era înainte, când o problemă pe dongle
+   lua nodul offline complet. De verificat la următoarea repornire planificată.
+
+**De reținut:** `vmbr0` și-a schimbat MAC-ul pe toate 3 nodurile (a preluat MAC-ul noii
+interfețe). Dacă apar reguli pe router legate de MAC, acolo e cauza.
+
+---
+
+## Îmbunătățiri posibile, în ordinea impactului
+
+### 1. Al doilea inel corosync (link1) pe switch-ul nou — cel mai valoros pas următor
+
+Cluster-ul are azi un singur inel corosync (`linknumber: 0`, peste `vmbr0`/IP-ul principal —
+vezi `/etc/pve/corosync.conf`). Când adaptorul USB al lui pveelite s-a resetat (aprilie și
+august), corosync a pierdut nodul respectiv fiindcă **nu exista rută alternativă**. Adăugarea
+switch-ului nou ca **link1** dedicat corosync ar fi ținut clusterul stabil în ambele incidente,
+inclusiv pe pve1 dacă i s-ar întâmpla la fel.
+
+**Precondiția e îndeplinită** din 2026-08-29: IP-urile `10.10.10.200/201/202` există și sunt
+verificate. Ring0 stă acum pe interfețele onboard (mai robuste), iar ring1 pe insulă ar acoperi
+și cazul în care dongle-ul USB sau portul din switch cedează.
+
+```bash
+pvecm status   # verifică starea curentă înainte de orice modificare
+# adăugare link1 se face editând /etc/pve/corosync.conf, incrementând config_version,
+# adăugând ring1_addr = 10.10.10.20x la fiecare nod + interface { linknumber: 1 } în totem
+```
+
+**Neaplicat** — schimbarea corosync.conf e sensibilă (poate rupe cvorumul dacă sintaxa greșește)
+și merită o fereastră dedicată.
+
+### 2, 3 și 4 — aplicate pe 2026-08-29
+
+Rețeaua dedicată, IP-urile fixe și mutarea IP-ului principal de pe dongle-ul USB pe onboard sunt
+**făcute** — vezi „Ce s-a aplicat efectiv". Decizia de arhitectură dintre variantele A
+(„IP-ul principal rămâne pe USB, `eno1` preia replicarea") și B („IP-ul principal se mută pe
+`eno1`") a fost tranșată de măsurători în favoarea lui **B**: dongle-ul rămâne 2.5G indiferent pe
+ce switch stă, deci mutându-l pe rețeaua dedicată nu se pierde nimic la replicare, iar producția
+pe 1G nu costă nimic pe pve1/pveelite.
+
+---
+
+## Ce NU s-a schimbat
+
+- `/etc/pve/corosync.conf` — **neatins.** Ring0 folosește în continuare IP-urile `10.0.20.20x`,
+  care acum stau pe interfețele onboard — deci corosync a câștigat robustețe fără nicio
+  modificare de configurație.
+- Cablurile nodurilor — **niciunul mutat de scripturi.** Toate mutările fizice au fost făcute
+  manual de utilizator (routerul pe switch 2, dongle-ul lui pveelite pe p4, al lui pve1 pe p3).
+- Cage-urile SFP+ ale plăcii X710 de pe pvemini — rămân goale, placa nefolosită. La verificări,
+  cele două interfețe au fost ridicate și **coborâte la loc**, doar ca să se citească EEPROM-ul.
+
+## Referințe
+
+- [Incident 2026-08-27 — pveelite fără rețea 16h (USB LAN reset)](../incidents/2026-08-27-pveelite-down.md)
+- [Corosync Tuning](../README.md#corosync-tuning) — tokenul de 10s, motivat de fragilitatea USB
+- [cluster/README.md — Rețea](../README.md#rețea)