romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c67e7d8361e0564ebbd93e6e283999c9c02d2f82
ROMFASTSQL/proxmox/cluster/README.md
Marius c67e7d8361 docs(cluster): pveelite are LAN pe USB - a doua ipoteza pentru caderea de ieri 
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
2026-08-27 21:53:34 +03:00

892 lines
31 KiB
Markdown
Raw Blame History

# 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)
```bash
# 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
```bash
# 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
```bash
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):**
```bash
/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:**
```bash
/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`):
```perl
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`:
```bash
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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
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
```bash
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
```bash
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 | stopped |
#### 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`.
```bash
# 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
```bash
# 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
```bash
# 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ă):
```bash
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.
```bash
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ă:
```bash
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` | stopped | template, recreabil |
| 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:
```bash
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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
ssh root@10.0.20.201 "ha-manager status"
ssh root@10.0.20.201 "ha-manager config"
```
### Modificare limite HA (exemplu)
```bash
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:
```bash
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
```bash
# 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.
```bash
# 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
```bash
# 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
```bash
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
```bash
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
```bash
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
```bash
# 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
```bash
ssh root@10.0.20.202 "swapon --show; sysctl vm.swappiness"
```
### Recreare (dacă e nevoie)
```bash
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 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`
### 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
Reference in New Issue View Git Blame Copy Permalink