ROMFASTSQL/proxmox/cluster

Ghid Conexiune SSH la Cluster Proxmox

Informații Generale Cluster

• Nume Cluster: romfast
• Număr Noduri: 3
• Status Quorum: Activ (3/3 noduri)
• Transport: knet
• Secure Auth: on

Noduri Cluster

Nod	IP	Status	Node ID	Descriere
pve1	10.0.20.200	Online	1	Nod cluster 1
pvemini (local)	10.0.20.201	Online	2	Nod principal (aici rulează LXC-urile)
pveelite	10.0.20.202	Online	3	Nod cluster 3

Versiune Proxmox

• Versiune: pve-manager/8.4.14/b502d23c55afcba1 (kernel: 6.8.12-15-pve)
• Utilizator SSH: root

Configurare Inițială SSH

1. Generare Cheie SSH (din WSL/Linux)

# Generează cheie SSH RSA 4096-bit
ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

# Locația default: ~/.ssh/id_rsa
# Apasă Enter pentru locația default
# Setează parolă opțională pentru cheie

2. Copierea Cheii pe Proxmox

# Metoda automată
ssh-copy-id root@10.0.20.201

# Metoda manuală
cat ~/.ssh/id_rsa.pub | ssh root@10.0.20.201 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

3. Testare Conexiune

ssh root@10.0.20.201

Storage Configuration

Storage-uri Disponibile (Cluster)

Storage	Tip	Noduri	Status	Capacitate	Utilizat	Locație	Content
local	dir	Toate (separat pe fiecare)	active	1.51 TiB	128 KB	/var/lib/vz	ISO, templates, backup
local-zfs	zfspool	pvemini, pve1, pveelite	active	1.75 TiB	324 GiB (18%)	rpool/data	VM disks, LXC rootfs
backup	dir	Doar pvemini	active	1.79 TiB	333 GiB (18%)	/mnt/backup	Backup-uri principale
backup-ssd	dir	Doar pve1	disabled	-	-	/mnt/pve/backup-ssd	Backup-uri SSD
backup-nfs	nfs	-	disabled	-	-	NFS server 10.0.20.201	-
backup-pvemini-nfs	nfs	pve1, pveelite	disabled	-	-	NFS server 10.0.20.201	-

Explicații Storage

local (Director local)

• Scop: ISO-uri, template-uri CT, backup-uri temporare
• Locație: Fiecare nod are propriul /var/lib/vz SEPARAT
• Non-partajat: Fișierele nu sunt vizibile între noduri
• Conținut: ISO, vztmpl (templates), backup

local-zfs (ZFS Pool partajat)

• Scop: Storage PRINCIPAL pentru VM-uri și LXC-uri
• Pool: rpool/data (ZFS)
• Partajat: Disponibil pe pvemini, pve1, pveelite
• Conținut: images (VM disks), rootdir (LXC root filesystems)
• Performanță: Cea mai bună (ZFS + local storage)
• Sparse: Enabled (economie spațiu)

backup (Director backup pe pvemini)

• Scop: Backup-uri principale job automat
• Locație: DOAR pe pvemini (10.0.20.201) - /mnt/backup
• Non-partajat: Accesibil doar pe pvemini
• Conținut: Toate tipurile (VM, LXC, templates)
• Retention: keep-all=1 (păstrează toate backup-urile)

backup-ssd (Director backup pe pve1)

• Status: Disabled
• Locație: DOAR pe pve1 - /mnt/pve/backup-ssd

backup-nfs și backup-pvemini-nfs

• Status: Disabled
• Server NFS: 10.0.20.201 (pvemini)
• Export: /mnt/backup de pe pvemini
• Note: Dezactivate - se folosește backup (director local)

Căi Storage Important

Pe pvemini (10.0.20.201):

/var/lib/vz/                    # local storage
/var/lib/vz/dump/               # backup-uri local
/mnt/backup/                    # backup storage principal
/mnt/backup/dump/               # backup-uri job automat
rpool/data                      # ZFS pool pentru VM/LXC

ISO-uri și Templates:

/var/lib/vz/template/iso/       # ISO-uri pe fiecare nod (local)
/var/lib/vz/template/cache/     # LXC templates

⚠️ Linked clone → full clone: qm move-disk NU merge pe local-zfs

Un VM clonat din template rămâne linked clone (zfs list -o name,origin arată un origin), iar template-ul sursă nu poate fi șters cât timp există. Metoda evidentă — qm move-disk <vmid> virtio0 local-zfs --delete 1 — eșuează întotdeauna. PVE respinge mutarea pe același storage (/usr/share/perl5/PVE/API2/Qemu.pm:4688):

die "you can't move to the same storage with same format\n"
    if $oldstoreid eq $storeid && (!$format || !$oldfmt || $oldfmt eq $format);

Pentru zvol-uri $oldfmt e mereu undef (numele n-are sufix .raw), deci condiția e adevărată indiferent de parametri. Nici storage-ul local nu e o rută de ocolire — are content iso,vztmpl,backup, fără images.

Ce funcționează (aplicat pe VM 303 în 2026-08-11, ~8 min downtime pentru 64 GB): backup vzdump întâi, apoi ștergerea snapshot-urilor VM-ului (blochează detașarea sursei), oprire curată, și copie ZFS locală cu swap de volid în /etc/pve/qemu-server/<vmid>.conf:

zfs snapshot rpool/data/vm-303-disk-1@fullclone
zfs send rpool/data/vm-303-disk-1@fullclone | zfs recv rpool/data/vm-303-disk-2
zfs destroy rpool/data/vm-303-disk-2@fullclone
zfs destroy rpool/data/vm-303-disk-1@fullclone
zfs set refreservation=none rpool/data/vm-303-disk-2   # local-zfs e sparse 1

zfs send fără -i produce un flux complet, deci datasetul rezultat nu are origin. În config, discul vechi se lasă ca unusedN — rollback prin swap invers, ~1 minut. Ambele discuri trebuie tratate, inclusiv efidisk0.

Comenzi Utile Proxmox

Gestiune VM-uri

# Listare toate VM-urile
qm list

# Status VM specific
qm status <VMID>

# Start/Stop/Restart VM
qm start <VMID>
qm stop <VMID>
qm restart <VMID>

# Configurație VM
qm config <VMID>

# Modificare configurație
qm set <VMID> --memory 4096 --cores 2

Gestiune LXC Containers

# Listare containere
pct list

# Status container
pct status <CTID>

# Start/Stop container
pct start <CTID>
pct stop <CTID>

# Configurație container
pct config <CTID>

# Intrare în container
pct enter <CTID>

Gestiune Storage

# Listare storage-uri
pvesm status

# Conținut storage
pvesm list <storage_name>

# Spațiu disponibil
pvesm list local-zfs

# Ștergere volum
pvesm free <volume_id>

Gestiune Backup-uri

# Listare backup-uri
pvesh get /cluster/backup

# Backup manual VM
vzdump <VMID> --storage backup --compress gzip

# Restore backup
qmrestore /path/to/backup.vma.gz <VMID> --storage local-zfs

# Căutare backup-uri pentru VM specific
find /mnt/pve/backup-nfs/dump/ -name "*<VMID>*" | sort -V

Configurații Hardware Recomandate

Pentru VM Windows 11

qm set <VMID> --cpu host --cores 2 --memory 4096 --kvm 1
qm set <VMID> --machine q35 --bios ovmf --ostype win11
qm set <VMID> --net0 e1000=<MAC>,bridge=vmbr0,firewall=1
qm set <VMID> --virtio0 local-zfs:80,format=raw

Pentru VM Windows 7/10

qm set <VMID> --cpu host --cores 2 --memory 4096 --kvm 1
qm set <VMID> --machine pc-i440fx-2.12 --bios seabios --ostype win10
qm set <VMID> --net0 virtio=<MAC>,bridge=vmbr0,firewall=1
qm set <VMID> --virtio0 local-zfs:60,format=raw

Pentru LXC Ubuntu/Debian

pct set <CTID> --cores 2 --memory 2048
pct set <CTID> --net0 name=eth0,bridge=vmbr0,ip=dhcp,type=veth
pct set <CTID> --rootfs local-zfs:20

Template-uri și ISO-uri Disponibile

Windows ISO-uri

• Win11_24H2_Original.iso - Windows 11 original (5.8GB)
• windows11rufus.iso - Windows 11 modificat cu Rufus (5.8GB)
• windows10.iso - Windows 10 (4.6GB)

Drivere

• virtio-win-0.1.141.iso - Drivere VirtIO pentru Windows

Rețea

Configurația Bridge

• Bridge: vmbr0
• Interfață Fizică: enp87s0
• IP Bridge: 10.0.20.201/24
• Gateway: 10.0.20.1
• Subnet: 10.0.20.0/24

VM-uri și Containere Active

Regenerat din date live 2026-07-31 (pvesh get /cluster/resources --type vm).

LXC Containers

VMID	Nume	Nod	IP	CPU	RAM	Storage	Status
100	portainer	pvemini	10.0.20.170	2 cores	4 GB	20 GB	running
102	docker.romfast.ro	pvemini	10.0.20.113	4 cores	12 GB	30 GB	running
103	dokploy	pvemini	10.0.20.167	2 cores	4 GB	50 GB	running
104	flowise	pvemini	10.0.20.161	4 cores	8 GB	100 GB	running
106	gitea	pvemini	10.0.20.165	2 cores	4 GB	250 GB	running
108	central-oracle	pvemini	10.0.20.121	2 cores	8 GB	50 GB	running
171	claude-agent	pvemini	10.0.20.171	4 cores	16 GB	32 GB	running
101	minecraft	pve1	-	4 cores	8 GB	100 GB	running
110	moltbot	pve1	10.0.20.173	6 cores	8 GB	50 GB	running
301	docker-portainer-template	pveelite	-	2 cores	8 GB	100 GB	template

Virtual Machines (QEMU)

VMID	Nume	Nod	IP	CPU	RAM	Storage	Status
201	roacentral	pvemini	10.0.20.122	4 cores	6 GB	500 GB	running
303	Win11-Adina	pvemini	DHCP	4 cores	8 GB	500 GB	running
310	Win11-Template-Sysprep	pvemini	-	2 cores	4 GB	500 GB	template ✅
302	oracle-test-302	pvemini	-	4 cores	4 GB	500 GB	stopped
109	oracle-dr-windows	pveelite	10.0.20.37	4 cores	6 GB	500 GB	stopped

Notă memorie: valorile sunt limite, nu rezervări — LXC-urile consumă doar cât folosesc. Suma nominală depășește RAM-ul fizic al nodurilor, ceea ce e normal. Vezi ../lxc171-claude-agent/README.md → „Memorie & OOM" pentru starea swap-ului pe noduri.

---

🔧 LXC 108 - Oracle Database (Acces Rapid)

Informații Container

• VMID: 108 | Nume: central-oracle | IP: 10.0.20.121
• CPU: 2 cores | RAM: 4 GB | Storage: 50 GB (local-zfs)
• Docker: oracle-xe (Oracle XE 21c) | Status: Running
• Portainer: http://10.0.20.121:9443

Acces în LXC (fără user/parolă)

Nu ai nevoie de credențiale pentru LXC 108! Accesul se face prin Proxmox folosind pct enter sau pct exec.

# Metoda 1: Intrare directă în LXC
ssh root@10.0.20.201
pct enter 108

# Metoda 2: Execuție comandă din Proxmox
ssh root@10.0.20.201 "pct exec 108 -- docker ps"

Restart Oracle Database

# Opțiunea 1: Restart Oracle container (RAPID)
ssh root@10.0.20.201 "pct exec 108 -- docker restart oracle-xe"

# Opțiunea 2: Restart LXC complet
ssh root@10.0.20.201 "pct restart 108"

# Verificare după restart
ssh root@10.0.20.201 "pct exec 108 -- docker ps"

Verificări Rapide

# Status containere Docker
ssh root@10.0.20.201 "pct exec 108 -- docker ps"

# Loguri Oracle
ssh root@10.0.20.201 "pct exec 108 -- docker logs oracle-xe --tail 50"

# Test conexiune Oracle
nc -zv 10.0.20.121 1521

📖 Documentație Completă Oracle

Pentru detalii despre:

• Conexiuni Oracle (PDB-uri: roa, roa2)
• Useri și parole Oracle
• SQL*Plus, JDBC, TNS configurations
• Export/import DMP
• Comenzi SQL și troubleshooting

Vezi: ../lxc108-oracle/README.md

---

Backup Job Configuration

Nu există un job unic, ci 8 job-uri separate, alternate pe zile pare/impare ca să nu se suprapună sarcina termică și de I/O. Sursa de adevăr e /etc/pve/jobs.cfg (pvesh get /cluster/backup), nu tabelul de mai jos — verifică-l dacă ceva nu se potrivește.

Job	Guest	Când	Storage	Retenție
backup-impare-oracle	108 (Oracle)	zile impare, 02:00	backup	keep-last=2, keep-weekly=1
backup-impare-rest	100, 103, 106, 171	zile impare, 03:00	backup	keep-last=2, keep-weekly=1
backup-pve1-minecraft	101	zile impare, 22:00	backup-ssd	keep-last=2, keep-weekly=1
backup-pare-flowise	104	zile pare, 02:00	backup	keep-last=2, keep-weekly=1
backup-pare-docker	102 (Docker + sbx)	zile pare, 03:00	backup	keep-last=2, keep-weekly=1
backup-pare-windows	201 (roacentral)	zile pare, 03:30	backup	keep-last=2, keep-weekly=1
backup-pve1-moltbot	110	zile pare, 22:00	backup-ssd	keep-last=2, keep-weekly=1
backup-lunar-adina	303 (Win11-Adina)	prima sâmbătă din lună, 04:30	backup	keep-monthly=3
backup-f1c87584-8eb2	109 (DR)	prima sâmbătă din lună, 15:00	backup-pvemini-nfs	keep-monthly=1

Toate rulează cu mode snapshot, compress zstd, notes-template {{guestname}}.

⚠️ sat *-1..7 = prima sâmbătă a lunii. Dacă adaugi un job lunar la mijlocul lunii, prima rulare automată e abia luna următoare — rulează manual un vzdump ca punct de plecare, altfel guest-ul rămâne descoperit până atunci. Ora 04:30 e aleasă ca să nu se suprapună cu job-urile pare/impare de la 03:30, fiindcă prima sâmbătă poate cădea în orice zi. Job-urile sunt executate de daemonul pvescheduler (nu de un timer systemd — nu căuta pvescheduler.timer, nu există):

systemctl is-active pvescheduler
pvesh get /cluster/backup          # lista reala a job-urilor

⚠️ Replicarea ZFS NU e backup

Job-urile din pvesr status oglindesc starea curentă. O ștergere accidentală sau o corupție ajunge pe toate nodurile la următorul sync — nu există niciun punct în timp din care să revii. Replicarea protejează împotriva pierderii unui nod; backup-ul, împotriva pierderii de date. Sunt necesare amândouă, pe mecanisme și storage-uri diferite.

Toate guest-urile running replică pe alte două noduri (verificat 2026-08-11). LXC 102 a fost adăugat atunci — vezi capcana de mai jos.

pvesr status                                    # toate job-urile, LastSync, FailCount
pvesr create-local-job 102-0 pve1 --schedule 21:20
pvesr run --id 102-0 --verbose                  # sync manual, util la prima rulare

Capcană: volume orfane blochează re-crearea unei replicări. Când un job de replicare e șters, volumul rămâne pe nodurile țintă. La recreare, sync-ul eșuează imediat cu:

No common base snapshot on volume(s) local-zfs:subvol-102-disk-0

Nu e o problemă de spațiu sau de rețea — pur și simplu există deja un dataset cu acel nume, fără snapshot comun din care să continue. Se rezolvă ștergând volumul de pe fiecare țintă, apoi rulând sync-ul, care va face o copie completă:

pvesh get /nodes/pve1/storage/local-zfs/content --output-format json   # ce e pe nodul tinta
pvesh delete /nodes/pve1/storage/local-zfs/content/local-zfs:subvol-102-disk-0

Verifică întâi că guest-ul nu rulează pe nodul respectiv — un volum cu vmid care trăiește pe alt nod e prin definiție orfan. Aici, pve1 avea o copie de 50 GB iar pveelite una de 30 GB, din epoci diferite, ambele nefolosite.

SSH între noduri trece prin Tailscale și cere autentificare interactivă, deci ssh root@10.0.20.201 "ssh pve1 ..." se blochează. Pentru orice inspecție pe alt nod, folosește pvesh get /nodes/<nod>/... — merge din pvemini fără autentificare suplimentară.

Guest-uri FĂRĂ backup

Guest	Stare	Comentariu
301 docker-portainer-template	template	nepornibil, fara cloni — se poate sterge
302 oracle-test-302	stopped	mediu de test, recreabil din 310
310 Win11-Template-Sysprep	stopped	template — de evaluat dacă merită backup

Toate guest-urile running sunt acoperite (verificat 2026-08-11).

Capcană dovedită: trecerea de la job-ul unic backup-fbb668c0-726e la job-urile per-guest a scăpat LXC 102 pe dinafară — a rămas 7 luni fără backup (ultimul din 10 ianuarie 2026), fără ca ceva să semnaleze. Job-urile care rulează cu succes nu spun nimic despre guest-urile pe care nu le conțin. După orice reorganizare de job-uri, compară lista de guest-uri cu suma vmid-urilor din job-uri.

Verificare rapidă a acoperirii:

pvesh get /cluster/resources --type vm --output-format json | \
  python3 -c "import sys,json;[print(r['vmid'],r.get('name'),r['status']) for r in json.load(sys.stdin)]"
pvesh get /cluster/backup --output-format json | grep -o '\"vmid\":\"[^\"]*\"'

Comenzi Cluster

# Verificare status cluster
pvecm status

# Listare noduri
pvecm nodes

# Listare toate resurse cluster
pvesh get /cluster/resources

# Verificare configurație cluster
cat /etc/pve/corosync.conf

📡 Hartă Rapidă IP-uri

Noduri Proxmox Cluster

Nod	IP	Rol	Web GUI
pve1	10.0.20.200	Nod cluster 1	https://10.0.20.200:8006
pvemini	10.0.20.201	Nod principal (LXC-uri active)	https://10.0.20.201:8006
pveelite	10.0.20.202	Nod cluster 3	https://10.0.20.202:8006

LXC Containers (Servicii)

VMID	Nume	IP	Port(uri)	Serviciu
100	portainer	10.0.20.170	9443, 8000	Portainer (Docker management)
103	dokploy	10.0.20.167	3000	Dokploy (Deployment platform)
104	flowise	10.0.20.161	3000	Flowise AI + Ollama
106	gitea	10.0.20.165	3000, 22	Gitea (Git server)
108	central-oracle	10.0.20.121	1521, 5500, 9443	Oracle XE 21c + Portainer

Virtual Machines

VMID	Nume	IP	OS	Rol
201	roacentral	DHCP	Windows 11	Client aplicații
303	Win11-Adina	DHCP (10.0.20.101)	Windows 11	Stație de lucru
310	Win11-Template-Sysprep	-	Windows 11	✅ Singurul template de clonare (sysprep-uit)

VM 300 Win11-Template — șters 2026-08-11. Nu era sysprep-uit: purta numele ROACENTRAL și SID-ul de mașină al VM 201 și le transmitea fiecărei clone, iar două mașini cu același SID de mașină nu se pot autentifica între ele prin SMB/NTLM. Înlocuit de VM 310, generalizat cu sysprep /generalize.

Accesuri Rapide

# Oracle Database (LXC 108) - Vezi ../lxc108-oracle/README.md pentru detalii
nc -zv 10.0.20.121 1521              # Test port Oracle
sqlplus sys/romfastsoft@10.0.20.121:1521/roa as sysdba

# Portainer Oracle
http://10.0.20.121:9443

# Portainer Principal
http://10.0.20.170:9443

# Gitea
http://10.0.20.165:3000

# Dokploy
http://10.0.20.167:3000

# Flowise AI
http://10.0.20.161:3000

Pentru conexiuni Oracle detaliate (PDB-uri, useri, TNS, export DMP): Vezi fișierul ../lxc108-oracle/README.md

---

Troubleshooting

Probleme Comune SSH

# Regenerare host keys pentru toate nodurile
ssh-keygen -R 10.0.20.200
ssh-keygen -R 10.0.20.201
ssh-keygen -R 10.0.20.202

# Conectare cu debug
ssh -v root@10.0.20.201

# Test conectivitate toate nodurile
ping -c 3 10.0.20.200
ping -c 3 10.0.20.201
ping -c 3 10.0.20.202

Probleme Cluster

# Verificare quorum
pvecm status

# Restart servicii cluster
systemctl restart pve-cluster
systemctl restart corosync

# Verificare log-uri cluster
journalctl -u corosync -f
journalctl -u pve-cluster -f

Probleme VM Windows 11

# Bypass cerințe TPM/Secure Boot în setup
reg add "HKLM\SYSTEM\Setup\LabConfig" /v "BypassTPMCheck" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\Setup\LabConfig" /v "BypassSecureBootCheck" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\Setup\LabConfig" /v "BypassRAMCheck" /t REG_DWORD /d 1 /f

# Forțare cont local în OOBE
oobe\BypassNRO.cmd

Verificare Status Servicii

# Status servicii Proxmox
systemctl status pveproxy
systemctl status pvedaemon
systemctl status pvestatd

# Restart servicii dacă e nevoie
systemctl restart pveproxy

Web Interface

Accesare Web GUI

• Nod pvemini (principal): https://10.0.20.201:8006
• Nod pve1: https://10.0.20.200:8006
• Nod pveelite: https://10.0.20.202:8006
• Utilizator: root
• Port: 8006 (HTTPS)

Note Importante

Cluster și High Availability

1. Clusterul are 3 noduri - Quorum necesită 2/3 noduri online
2. Întotdeauna fă backup înainte de modificări majore
3. Storage sincronizat - backup și backup-nfs sunt disponibile pe toate nodurile

Performance și Configurații

4. Folosește storage local-zfs pentru performanță optimă VM-uri/containere
5. Pentru Windows 11 folosește placa de rețea e1000 în loc de VirtIO pentru compatibilitate
6. CPU type 'host' oferă performanțe maxime cu KVM=1
7. VM 201 (Windows 11) rulează pe local-zfs pentru performanță optimă
8. LXC 108 (Oracle XE 21c) - IP: 10.0.20.121 - Acces fără user/parolă prin pct enter 108

Backup și Siguranță

9. Backup zilnic la 02:00 pentru toate containerele active și VM 201
10. Retention policy: 1 daily + 1 weekly
11. Compression zstd pentru backup-uri eficiente
12. Testează conexiunea SSH pe toate nodurile înainte de automatizări

Containere Active

13. 6 containere LXC active - Portainer (170), Dokploy (167), Flowise (161), Gitea (165), Oracle (121)
14. Container 103 (Dokploy) - Platform deployment și management Docker
15. Container 108 (Oracle XE 21c) - Database principal
    • Restart rapid: ssh root@10.0.20.201 "pct exec 108 -- docker restart oracle-xe"
    • Restart complet LXC: ssh root@10.0.20.201 "pct restart 108"
    • Portainer: http://10.0.20.121:9443

---

High Availability (HA)

Cluster-ul folosește HA pentru failover automat al containerelor critice. Configurația a fost revizuită după incidentul 2026-04-20 (vezi incidents/2026-04-20-cluster-outage.md).

Grupuri HA

group: ha-group-main     → pvemini (primar 100), pveelite (50), pve1 (33)
group: ha-group-elite    → pveelite (primar 100), pve1 (33), pvemini (50)

Resurse HA active

Resursă	Grup	Home node	Max restart	Max relocate	Notă
ct:100 portainer	ha-group-main	pvemini	3	3
ct:101 minecraft	ha-group-elite	pvemini	3	3	Rulează pe pveelite
ct:104 flowise	ha-group-main	pvemini	3	2	Limite adăugate 2026-04-20
ct:105 test	ha-group-elite	pvemini	-	-	Stopped
ct:106 gitea	ha-group-main	pvemini	3	3
ct:108 central-oracle	ha-group-main	pvemini	3	2	Limite adăugate 2026-04-20

VM 109 (oracle-dr-windows) NU mai e în HA — scos intenționat 2026-04-20 după buclă OOM. Pornit exclusiv de scriptul DR test sâmbăta 06:00.

Verificare HA

ssh root@10.0.20.201 "ha-manager status"
ssh root@10.0.20.201 "ha-manager config"

Modificare limite HA (exemplu)

ha-manager set ct:108 --max_restart 3 --max_relocate 2

---

Corosync Tuning

După incidentul 2026-04-20 (crash pveelite din USB LAN disconnect → pierdere cvorum → watchdog reset), tokenul corosync a fost mărit pentru a tolera glitch-uri scurte de rețea.

Config curent (/etc/pve/corosync.conf, config_version: 16):

totem {
  token: 10000
  token_retransmits_before_loss_const: 10
}

Impact: cluster-ul așteaptă 10 secunde înainte să declare un nod mort (default era 1 sec). Tolerează USB disconnect scurt pe pveelite fără să forțeze reboot.

Verificare:

ssh root@10.0.20.201 "corosync-cmapctl | grep 'totem.token '"
# runtime.config.totem.token (u32) = 10650
# totem.token (u32) = 10000

---

Diagnostic Tools (pvemini)

Instalate 2026-04-20 pentru a prinde cauza crash-ului din 00:23 (care nu a lăsat niciun log).

rasdaemon — MCE + PCIe AER monitoring

# Verificare erori hardware istorice
ssh root@10.0.20.201 "ras-mc-ctl --summary"
# Memory errors / PCIe AER errors / Extlog / MCE

netconsole — kernel logs către pve1

pvemini trimite log-uri kernel via UDP către pve1. Dacă pvemini crashează hard, ultimele linii kernel sunt captate pe pve1.

# Logs pre-crash pe pve1
ssh root@10.0.20.200 "tail /var/log/netconsole-pvemini.log"

# Status serviciu listener
ssh root@10.0.20.200 "systemctl status netconsole-receiver"

Config pe pvemini: /etc/modules-load.d/netconsole.conf Config pe pve1: /etc/systemd/system/netconsole-receiver.service + /var/log/netconsole-pvemini.log

kdump-tools — captură kernel crash dump

# Verificare configurare
ssh root@10.0.20.201 "cat /proc/cmdline | grep crashkernel"
ssh root@10.0.20.201 "systemctl is-active kdump-tools"

# La următorul crash, dump-ul va fi în:
ssh root@10.0.20.201 "ls /var/crash/"

Parametru: crashkernel=128M în /etc/kernel/cmdline (Proxmox folosește systemd-boot prin proxmox-boot-tool, nu GRUB).

kernel.panic auto-reboot

ssh root@10.0.20.201 "sysctl kernel.panic"
# kernel.panic = 10 → auto-reboot după 10s la kernel panic

---

Mail Notifications

Toate 3 nodurile trimit mail prin mail.romfast.ro:465 cu autentificare SMTP SASL (cont ups@romfast.ro).

Configurare Postfix

Config în /etc/postfix/main.cf pe fiecare nod:

relayhost = [mail.romfast.ro]:465
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt

Credentiale în /etc/postfix/sasl_passwd (permisiuni 600).

Test rapid

ssh root@10.0.20.201 "echo 'test' | mail -r 'ups@romfast.ro' -s 'test $(hostname)' mmarius28@gmail.com"
ssh root@10.0.20.201 "journalctl -u postfix@- --since '1 min ago' | grep status="
# Trebuie să vezi: status=sent (250 OK ...)

Dependințe

• libsasl2-modules (instalat 2026-04-20 — fără el: SASL authentication failure: No worthy mechs found)

Proxmox Notification Targets (/etc/pve/notifications.cfg)

Două target-uri definite, doar mail-to-root activ în matcher:

Target	Tip	From	Folosit
mail-to-root	sendmail	proxmox@romfast.ro	DA — default-matcher
pve1	smtp (mail.romfast.ro:465)	pve1@romfast.ro	NU (definit, dar scos din matcher)

default-matcher → trimite DOAR la mail-to-root:

matcher: default-matcher
    mode all
    target mail-to-root

Toate backup job-urile folosesc DEFAULT (nu au notification-target explicit), deci fiecare backup trimite un singur email.

ATENȚIE: Dacă adaugi un nou notification target, nu-l adăuga în default-matcher dacă mail-to-root e deja acolo — vei primi emailuri duble pentru fiecare backup și alert.

Cron Jobs — Regula stdout

Cron trimite email dacă scriptul produce orice output pe stdout/stderr. Scripturile care își trimit propriile notificări (via mail sau PVE::Notify) trebuie să aibă > /dev/null 2>&1 în crontab, altfel generează un email suplimentar de "confirmare execuție".

Stare curentă crontab pvemini (10.0.20.201):

Script	Schedule	Redirect	Motiv
oom-alert.sh	* * * * *	—	Silențios când nu e OOM
ha-monitor.sh	0 0 * * *	—	Output captat intern în $()
ups-monthly-test.sh	0 0 1 * *	> /dev/null 2>&1	Folosește tee → stdout
vm109-watchdog.sh	* * * * *	—	Scrie în log file
pveelite-down-alert.sh	* * * * *	—	Silențios fără alertă
weekly-dr-test-proxmox.sh	0 6 * * 6	> /dev/null 2>&1	Folosește tee → stdout
kingston-thermal-monitor.sh	*/30 * * * *	—	Folosește logger, silențios
kingston-thermal-report.sh --mail	0 8 * * *	> /dev/null 2>&1	Trimite raport via mail, confirmarea pe stdout

Stare curentă crontab pveelite (10.0.20.202):

Script	Schedule	Redirect	Motiv
oracle-backup-monitor-proxmox.sh	0 21 * * *	—	Silențios
oom-alert.sh	* * * * *	—	Silențios când nu e OOM
pvemini-down-alert.sh	* * * * *	—	Silențios fără alertă
vm109-watchdog.sh	* * * * *	—	Scrie în log file
zfs-replicate-oracle-backups.sh	*/15 * * * *	—	Silențios
nightly-backup-mirror.sh	0 4 * * *	—	Silențios
weekly-dr-test-proxmox.sh	0 6 * * 6	> /dev/null 2>&1	Folosește tee → stdout

---

OOM Alerting

Cron pe fiecare nod verifică la 1 minut dacă au avut loc OOM-kills. Dacă da, trimite mail cu detalii.

Configurare

• Script: /opt/scripts/oom-alert.sh pe fiecare nod (pve1, pvemini, pveelite)
• Cron: * * * * * /opt/scripts/oom-alert.sh
• Mail destinat: mmarius28@gmail.com (de la ups@romfast.ro)

Verificare script instalat

for ip in 10.0.20.200 10.0.20.201 10.0.20.202; do
    ssh root@$ip "crontab -l | grep oom-alert"
done

Test simulare

# Generează OOM kill mesaj fals (NU omoară nimic, doar log)
ssh root@10.0.20.202 "logger -t kernel -p kern.warn 'Killed process 99999 (fake-test) total-vm:1kB'"
# Așteaptă 1 min, verifică inbox

---

Swap pe pveelite

Adăugat 2026-04-20 ca insurance împotriva OOM cascade (pveelite are doar 16 GB RAM).

• Swap device: /dev/zvol/rpool/swap (ZFS zvol 8 GB)
• Mount: /etc/fstab
• swappiness: 10 (folosește swap doar sub presiune reală)

Verificare

ssh root@10.0.20.202 "swapon --show; sysctl vm.swappiness"

Recreare (dacă e nevoie)

zfs create -V 8G -b 4K -o compression=zle -o logbias=throughput \
    -o sync=always -o primarycache=metadata -o secondarycache=none \
    rpool/swap
mkswap -f /dev/zvol/rpool/swap
echo '/dev/zvol/rpool/swap none swap sw 0 0' >> /etc/fstab
swapon -a

---

Documentație Asociată

Index Principal

• README.md - ../README.md - Index complet documentație Proxmox

Incidents

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

Virtual Machines

• VM 201 - Windows 11: ../vm201-windows/README.md
  • SSL Certificates: ../vm201-windows/docs/vm201-certificat-letsencrypt-iis.md
  • Troubleshooting: ../vm201-windows/docs/
• VM 109 - Oracle DR Windows: ../vm109-windows-dr/README.md — NU mai e în HA din 2026-04-20

Cluster Resources (acest director)

• HA Monitor: cluster-ha-monitor.sh
• Sistem UPS: ups/README.md

---

Ultima actualizare: 2026-05-01 Autor: Marius Mutu Proiect: ROMFASTSQL - Proxmox Infrastructure Documentation