f5c8df7adf
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
LXC 301 — docker-portainer-template (TEMPLATE, predecesorul VM 109)
VMID: 301 · Nod: pveelite (10.0.20.202) · Stare: template (nepornibil)
Descriere din Proxmox: „LXC Template cu Docker si Portainer" · Tags: docker, oracle19
Container vechi, convertit in template Proxmox (template: 1 in config). Nu e folosit
de nimic si nu are niciun clon. Documentat aici fiindca era singurul guest din cluster
fara nicio pagina.
De ce apare „oprit" in GUI
Un template nu e un container oprit — e o imagine, marcata template: 1, cu volumul root
transformat in basevol-* si snapshot-ul @__base__ din care se cloneaza. Proxmox il
afiseaza gri, cu starea stopped, fiindca un template nu poate fi pornit deloc:
pct start 301 esueaza, iar onboot: 1 din config e ignorat pentru template-uri.
IP-ul 10.0.20.37 — mostenit de VM 109, fara risc activ
| LXC 301 | VM 109 | |
|---|---|---|
| IP | 10.0.20.37 (static, in net0) |
10.0.20.37 (static, in Windows) |
onboot |
1 — ignorat, e template | 0 — pornit manual, doar la teste DR |
| Rol | fost DR Oracle 19c, inlocuit | DR Oracle activ |
DR_WINDOWS_VM_IMPLEMENTATION_PLAN.md confirma mostenirea: „IP: 10.0.20.37 (same as
current LXC)". VM 109 a preluat adresa containerului pe care il inlocuia, iar configul
containerului si-a pastrat-o.
Nu e un conflict activ. Cat timp 301 ramane template, nu porneste la reboot-ul lui
pveelite si nu revendica adresa. Riscul ar reaparea doar daca cineva il converteste inapoi
in container (Convert to CT / pct set 301 -template 0) — atunci onboot: 1 redevine
efectiv si trebuie intai pus -onboot 0 sau schimbat IP-ul.
Se poate sterge
Nimic nu depinde de el — snapshot-ul basevol-301-disk-0@__base__ nu are niciun clon
(verificat pe pveelite, 2026-08-31):
rpool/data/basevol-301-disk-0 916M origin -
rpool/data/basevol-301-disk-0@__base__ 1008K origin -
Ocupa ~916 MB pe local-zfs de pe pveelite. Stergerea (pct destroy 301) e sigura, dar
ramane la decizia utilizatorului — nu e urgenta, si e singura urma a setup-ului DR Oracle
19c de dinaintea lui VM 109.
Configuratie
| Parametru | Valoare |
|---|---|
| Hostname | docker-portainer-template |
| RAM / CPU | 8 GB / 2 nuclee |
| Disc | local-zfs:basevol-301-disk-0, 100 GB alocat, ~916 MB folositi |
| Retea | vmbr0, 10.0.20.37/24, gw 10.0.20.1 |
| OS | Debian, unprivileged, nesting=1,keyctl=1,fuse=1 |
| Template | template: 1 |
Comenzi
ssh root@10.0.20.202 "pct config 301" # configuratia
ssh root@10.0.20.202 "zfs list -o name,used,origin -r rpool/data | grep 301" # cloni
ssh root@10.0.20.202 "pct destroy 301" # stergere definitiva
Daca vreodata e convertit inapoi in container: pct set 301 -onboot 0 inainte de a-l
porni, altfel intra in conflict cu VM 109. Vezi vm109-windows-dr/README.md.