Documentatia de ieri descria LXC 301 ca un container oprit cu `onboot: 1` care
ar fura 10.0.20.37 de la VM 109 la reboot-ul lui pveelite. Configul are insa
`template: 1`: un template nu poate fi pornit, iar `onboot` e ignorat pentru el.
Riscul reapare doar daca e convertit inapoi in container.
Verificat si ca `basevol-301-disk-0@__base__` nu are niciun clon, ceea ce
infirma cealalta grija din pagina — se poate sterge in siguranta (~916 MB).
Recomandarea `pct set 301 -onboot 0` din handover e marcata infirmata, nu
stearsa, ca sa nu reapara intr-o sesiune viitoare.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SGMEagPnRavdLhWFqJHdja
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
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Intrebarea "nu-l putem trezi cu un magic packet?" a scos la iveala ceva ce
schimba diagnosticul, nu doar raspunsul la ea.
Pe WoL, pe scurt: nu se poate nici macar incerca. MAC-ul lui pveelite nu mai
exista nicaieri - intrarea ARP a expirat pe pvemini (INCOMPLETE), pe pve1
(FAILED), in tabela statiei de admin si pe LXC-urile de pe LAN; nodurile au IP
static, deci nu exista lease DHCP; in documentatie nu e consemnat. Raman tabela
routerului sau citirea fizica de pe nod. Si chiar cu MAC-ul, placa de retea e pe
USB, iar un dongle USB e nealimentat in soft-off, deci nu asculta dupa magic
packet.
Partea care conteaza insa e alta: pveelite ARE placa de retea pe USB, si
deconectarea ei e modul de defectare deja documentat al acestui nod - incidentul
2026-04-20 a pornit exact de la un USB LAN disconnect, motiv pentru care tokenul
corosync a fost marit la 10 s. Un nod care si-a pierdut adaptorul de retea arata
din exterior identic cu unul oprit: fara ping, fara ARP, fara corosync, fara SSH.
Toate observatiile din incident sunt compatibile cu ambele scenarii, iar eu
scrisesem doar unul.
Pentru 16:01 dovezile inclina in continuare spre repornire - curba de memorie din
RRD se reseteaza (2,43 GB la 16:00 -> 2,10 GB la 16:30, sub valoarea de dupa boot)
si NFS-ul se reataseaza. Pentru 17:26 nu exista niciun indiciu echivalent: nodul
pur si simplu a incetat sa fie vizibil, ceea ce o deconectare USB explica la fel
de bine ca o pierdere de alimentare. Am slabit corespunzator formularile din TL;DR
si din cronologie, unde afirmasem repornirea ca fapt.
Consecinta practica, pusa in document ca avertisment inainte de orice altceva:
prima observatie la fata locului e daca masina merge - ventilatoare, LED-uri,
imagine. Daca e pornita, nu a fost o cadere de alimentare, jurnalul e intact si
reparatia e la dongle, cablu sau portul de switch. Nu apasa butonul de power
inainte sa te uiti.
In script, pasul 1 nu mai citeste boot-urile dupa index - indexurile difera intre
cele doua scenarii si ar fi dus la concluzii gresite. Acum taie jurnalul dupa ora
si pune intai testul decisiv: exista intrari dupa 17:26:44? Daca da, masina a mers
mai departe si a cazut doar reteaua, iar verdictul si remediile se schimba complet.
Adaugat si un bloc de diagnostic pentru adaptorul USB (interfete, drivere, lsusb,
deconectari si evenimente de link in jurnalul kernel).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
pveelite s-a resetat singur la 16:01 si a murit definitiv la 17:26, pe o masina
complet idle (CPU 0,4%, load 0,10, RAM 2,15 din 15,3 GB). E inaccesibil si la
nivel L2 - ip neigh raporteaza FAILED - deci diagnosticul nu se poate duce mai
departe de la distanta.
Ce exclud dovezile: nu e resurse (RRD-ul de pe pvemini arata nodul inactiv), nu e
retea (niciun flap knet in 7 zile in afara zilei de azi, pve1 si pvemini stabile
de la 13:20), nu e UPS (OL, baterie 100%, input 239,6 V), nu e comanda de la noi
(singura rulare ups-shutdown de azi a fost dry-run, iar in jurnal nu exista niciun
poweroff catre .202). Ramane alimentarea sau hardware-ul.
Oprirea de la pranz a fost planificata, nu o cadere: qmshutdown:303 de la root@pam
la 12:25, statia de admin conectata la 12:28:59, poweroff curat pe toate trei la
12:33-12:36. pveelite a revenit normal la 13:20 si a mers 2h40m. Cedarea vine deci
dupa ciclul de oprire-pornire, ceea ce intareste ipoteza de alimentare.
Impactul pe productie e zero - pe nod nu era decat CT 301, care e template oprit,
iar vm:109 era oprit si a fost recuperat curat pe pvemini de fence la 17:28.
Replicarea catre pve1 e intacta si la zi (RPO 15 min respectat). Ce ramane in
aer: clusterul sta pe 2 voturi din 3, fara marja, si replicarea catre pveelite e
oprita pe toate cele 9 job-uri.
Trei lucruri au mers pentru ca au fost reparate dupa aprilie: fence-ul a recuperat
un singur serviciu si i-a respectat starea oprita, consolidarea sarcinii pe
pvemini/pve1 a facut caderea un non-eveniment, iar alerta a plecat pe email la
17:31.
Scriptul de verificare se ruleaza cand nodul e pornit fizic la loc. Ordinea nu e
intamplatoare - intai de ce a cazut, din jurnalul boot-urilor care abia acum devin
citibile, si abia apoi starea. Daca jurnalul e tacut inainte de ambele caderi,
scriptul NU declara nodul sanatos: da verdict de alimentare/hardware si cere
testarea sursei si a memoriei inainte ca pveelite sa fie iar tinta de failover.
Exact capcana din 2026-04-20, unde pvemini a repornit singur si parea in regula.
Verificat pe clusterul viu: cei trei parseri (voturi quorum, job-uri de replicare
esuate, stare LRM) intorc 2, 9 si "LRM mort", adica starea reala de acum.
Doua lucruri colaterale, consemnate in document, nu rezolvate aici: tailscaled e
mort pe pveelite de 27 de zile, deci nu exista acces out-of-band, iar textul
alertei pveelite-down-alert.sh trimite la un export NFS care nu mai e in
storage.cfg.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Docker host-ul era singurul guest fara replicare. Adaugate job-urile 102-0
(pve1, 21:20) si 102-1 (pveelite, 21:21), in sloturi libere. Sync initial
rulat manual: ~88s fiecare, ambele OK.
Prima incercare a esuat cu "No common base snapshot": ambele noduri tinta
aveau volume orfane ramase de la o replicare stearsa candva (pve1 50 GB,
pveelite 30 GB, din epoci diferite, nefolosite). Sterse prin API, apoi sync
complet.
Documentate: capcana volumelor orfane si faptul ca SSH intre noduri trece
prin Tailscale — pentru inspectii pe alt nod se foloseste `pvesh get
/nodes/<nod>/...`, nu ssh imbricat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
LXC 102 nu avea nici backup, nici replicare — singurul guest fara nicio
protectie. Ultimele arhive erau din 10 ianuarie 2026: trecerea de la job-ul
unic la job-urile per-guest l-a scapat pe dinafara, 7 luni fara sa semnaleze
nimic.
Creat `backup-pare-docker` (zile pare 03:00, keep-last=2 keep-weekly=1) si
rulat un backup imediat — 9 GB arhiva din 12.3 GB folositi.
Toate guest-urile `running` sunt acum acoperite. Notata in README capcana:
job-urile care ruleaza cu succes nu spun nimic despre guest-urile care nu
sunt in ele.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
LXC 103 avea replicare ZFS zilnica (21:02 pve1, 21:03 pveelite) dar niciun
backup. Replicarea oglindeste starea curenta: o stergere sau o coruptie
ajunge pe toate nodurile la urmatorul sync, fara punct de revenire.
Adaugat in job-ul de containere usoare (zile impare 03:00, keep-last=2
keep-weekly=1) — 8.24 GB folositi, 4.3 GB arhiva. Rulat si un backup
initial, fiindca urmatoarea rulare automata era abia pe 13 august.
Ramane descoperit doar LXC 102, singurul `running` fara backup.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
`backup-impare-adina` (la 2 zile) inlocuit cu `backup-lunar-adina`:
prima sambata din luna la 04:30, keep-monthly=3.
Ora 04:30 evita coliziunea cu job-urile pare/impare de la 03:30 — prima
sambata a lunii poate cadea in orice zi.
Notat in README ca `sat *-1..7` inseamna prima sambata: un job lunar adaugat
la mijlocul lunii nu ruleaza pana luna urmatoare.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 303 nu era in niciun job de backup dupa transformarea in full clone.
Adaugat `backup-impare-adina` (zile impare 03:30, storage backup,
keep-last=2 keep-weekly=1), pe zile impare ca sa nu se suprapuna cu VM 201
care ruleaza in acelasi slot pe zile pare.
Sectiunea "Backup Job Configuration" din README descria un job unic
(`backup-fbb668c0-726e`, daily 02:00) care nu mai exista de mult. Inlocuita
cu cele 8 job-uri reale.
Semnalate guest-urile fara backup: LXC 102 si 103, ambele `running`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
`qm move-disk <vmid> <disk> local-zfs --delete 1` esueaza intotdeauna pentru
zvol-uri: PVE respinge mutarea pe acelasi storage, iar conditia din
Qemu.pm:4688 e mereu adevarata fiindca numele volumului n-are sufix de format.
Nici storage-ul `local` nu e ruta de ocolire — n-are `images` in content.
Documentata metoda care functioneaza (zfs send/recv local + swap de volid),
asa cum a fost aplicata pe VM 303.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 303 rula ca linked clone din VM 300, deci template-ul contaminat nu putea
fi sters. Transformat in full clone si VM 300 eliminat din infrastructura.
Metoda: zfs send/recv local + swap de volid in config. `qm move-disk` nu era
o optiune — PVE respinge mutarea pe acelasi storage, iar pentru zvol-uri
conditia din Qemu.pm:4688 e mereu adevarata (numele n-are sufix de format).
- inventarele nu mai listeaza VM 300; VM 310 ramane singurul template
- clone-vm300.sh: comentariul spune de ce sursa e 310 (numele e istoric)
- handoff-ul sters la cererea utilizatorului; faptele care mai conteaza sunt
mutate inline in README-uri, ca sa nu ramana referinte moarte
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 300 `Win11-Template` nu a fost sysprep-uit: poarta numele ROACENTRAL si
SID-ul de masina al VM 201 (S-1-5-21-1850128657-3079265004-705332634).
Clonele lui mostenesc acea identitate, iar NTLM intre doua masini cu acelasi
SID de masina esueaza — de aici imposibilitatea accesarii share-urilor SMB
intre VM 303 si VM 201, in ambele sensuri.
VM 300 nu poate fi reparat in loc: e template read-only, iar VM 303 e linked
clone din el. Solutia: clona completa 300 -> 310, sysprep acolo, conversie in
template. Verificat pe o clona de proba: nume si SID noi la fiecare pornire.
- clone-vm300.sh: SOURCE_VMID 300 -> 310
- README-uri: VM 310 marcat ca template de clonare, VM 300 ca "nu clona"
- vm302-oracle-test: corectat exemplul care clona in VM 303 (deja ocupat)
- docs/handoff-smb-vm303-roacentral.md: probele, capcanele de sysprep, stare
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
Alerta "OOM x2 on pvemini" (09:36) arata procese mici ucise (dbus-daemon,
oom_score_adj:200), dar mesajul kernel dadea containerul real:
oom_memcg=/lxc/102. OOM local containerului, nu presiune de host - pvemini
avea 24Gi disponibili si zram functional.
Baseline masurat cu ZERO sandbox-uri active: ~1.9GB (sbx 863M + claude 317M +
VS Code Remote 450M + docker/tailscale/portainer 205M). Un sandbox real mai
adauga ~1.9GB (containerd-shim) -> plafonul de 4GB era depasit sistematic.
Contoare cumulate: oom_kill 24, 9279 depasiri memory.high, memory.peak fix pe
limita, swap 510/512 epuizat.
Verificat explicit ca sbx NU are memory leak: RSS urca la ~863M la pornire si
se plafoneaza (esantionat la 10s timp de un minut).
Fix: pct set 102 --memory 12288 --swap 4096 (live, fara restart).
Tabelul de resurse din cluster/README.md era vechi (102 aparea ca "coolify
stopped", lipseau 110 si 171, RAM gresit peste tot) - regenerat din pvesh.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
LXC 110 (moltbot) a picat dupa un OOM local containerului urmat de reboot:
tailscaled a ramas delogat, iar containerul mostenea resolv.conf-ul Tailscale
de la host-ul pve1 (doar MagicDNS 100.100.100.100) -> rezolutie DNS zero desi
L3 era functional -> echo-core in crash-loop pe telegram.error.TimedOut.
Fixuri aplicate:
- pct set 110 --nameserver '10.0.20.1 1.1.1.1' (elimina dependenta de Tailscale)
- zram-tools pe pve1 (8G zstd, prio 100) - `swap: 4096` din config era fictiv,
host-ul nu avea niciun swap; root pe ZFS deci zram, nu swapfile
- MemoryHigh/MemoryMax pe pocket-tts + supertonic-tts - toate serviciile user
rulau cu limite `infinity`, de unde OOM-uri recurente (Apr 25, May 28 x4)
cu victime aleatorii alese dupa oom_score_adj
Documentatie:
- nou post-mortem in cluster/incidents/, adaugat in indexuri
- README lxc110: host corectat pveelite -> pve1 (+ RAM/CPU/storage reale),
comenzile pct redirectionate spre nodul corect
- README lxc171: tabel cu starea swap pe cele 3 noduri (pveelite are zvol,
nu zram - nu necesita acelasi fix)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Proxmox default-matcher acum trimite doar la mail-to-root (pve1 smtp
eliminat din matcher → fix emailuri duble pentru backup/vzdump)
- Adaugat tabel cron jobs per nod cu motivul redirect-ului > /dev/null
- Regula: scripturi cu propriile notificari trebuie sa aiba redirect in
crontab, altfel cron genereaza email suplimentar de confirmare
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Following the 2026-04-20 cluster outage, the cluster README now covers
HA resource limits, corosync token tuning (10s tolerance for USB glitches),
rasdaemon/netconsole/kdump diagnostic stack on pvemini, mail relay via
mail.romfast.ro with SMTP auth, OOM alerting via cron, and swap on pveelite.
VM 109 README now clearly states it was removed from HA and is only
started by the weekly DR test script.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Create cluster/ for Proxmox cluster infrastructure (SSH guide, HA monitor, UPS)
- Create lxc108-oracle/ for Oracle Database documentation and scripts
- Create vm201-windows/ for Windows 11 VM docs and SSL certificate scripts
- Add SSL certificate monitoring scripts (check-ssl-certificates.ps1, monitor-ssl-certificates.sh)
- Remove archived VM107 references (decommissioned)
- Update all cross-references between files
- Update main README.md with new structure and navigation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
