Hub

electrosystems

poseidon-root-triage

active high work
Creado
2026-05-21
Actualizado
2026-05-29
Directorios
  • /home/sergio/agy/electrosystems/servers/poseidon

Pendientes abiertos (1)

Ver todos →

🎯 Top de ataque (1)

  • #144 📅 2026-06-15 Limpieza low-risk (opcional, baja ganancia). El diagnóstico de #143 mostró que /var/log (1.2G) + /var/tmp (1.2G) + /root (53M) es el único terreno disponible para limpieza in-place — máximo ~2 GB recuperables, insuficiente para sacar / del rango crítico. Saltar este paso y ejecutar #145 directo. Mantener este pendiente como segunda barrida de mantenimiento DESPUÉS de #145.

Actividad en bitácora 1 día

jun
jul
ago
sep
oct
nov
dic
ene
feb
mar
abr
may
L
X
V
Menos
Más

Poseidon — Triage de / (root partition al 99%)

Contexto

poseidon es el hipervisor primario de Electrosystems (KVM/libvirt, CentOS 7, 24 vCPU / 86 GB RAM / 19 VMs running de producción). IP 192.168.20.3. Documentado en electrosystems/servers/poseidon/README.md.

Problema descubierto 2026-05-21: /dev/mapper/centos-root (50 GB total) está al 99% — solo 875 MB libres. Mismo patrón que orion antes del triage del 2026-05-11 (donde escaló a 100% y empezó a fallar writes a nivel host). En poseidon todavía no falla, pero el margen es mínimo y la tendencia es de empeoramiento (en el snapshot de 2026-04-24 había 2.1 GB libres; un mes después quedan 875 MB).

Por qué importa: es el host de prod más cargado del datacenter (clientes, contabilidad-2024, vitalpbx4, nominas-win2k22, reverse-proxy, wireguard, es-monitoreo, etc.). Si / llega a 100%, escenarios posibles:

  • Writes a nivel host fallan (igual que orion).
  • journald, libvirt, qemu-monitors no pueden escribir.
  • VMs corriendo siguen vivas mientras no haya snapshots/dump activos, pero el host se vuelve inoperable para administración.

Bloqueante directo: la migración orion→poseidon (orion-decommission) queda pausada hasta que se libere espacio en / de poseidon. No tiene sentido meter más VMs a un host que está por reventarse el root.

Causa probable (per README de poseidon): el pool libvirt default apunta a /var/lib/libvirt/images (dentro de /). El README ya marcaba el pool como “TIGHT — do not use” y recomendaba mover existing VM disks de default a home. Esa tarea de auditoría nunca se hizo; probablemente hay qcow2 ahí inflándose con el tiempo.

Tareas pendientes

Diagnóstico inicial (read-only)

  • (2026-05-21) #143 Mapear qué consume / en poseidon. Resuelto: pool libvirt default consume 45G de 50G; ofensor único = netbox.qcow2 42G. nagios.qcow2 3G. Resto de /var < 3G combinado. Ver bitácora 2026-05-21.

Limpieza low-risk

  • #144 📅 2026-06-15 — Limpieza low-risk (opcional, baja ganancia). El diagnóstico de #143 mostró que /var/log (1.2G) + /var/tmp (1.2G) + /root (53M) es el único terreno disponible para limpieza in-place — máximo ~2 GB recuperables, insuficiente para sacar / del rango crítico. Saltar este paso y ejecutar #145 directo. Mantener este pendiente como segunda barrida de mantenimiento DESPUÉS de #145.

Fix estructural

  • (2026-05-21) #145 Mover netbox.qcow2 (42G) del pool default al pool home. Resuelto: / bajó de 99% (874 MB libres) → 16% (43 GB libres). Downtime real de NetBox ~6 min (shutdown 22s + mv 5min + start + boot). NetBox responde HTTP 200 en / y /api/status/. Nagios queda en pool default por ahora (3G real, pool con 42 GiB libres → sin urgencia). Ver bitácora 2026-05-21 noche.

Validación final

  • (2026-05-21) #146 Documentar nuevo estado en README de poseidonelectrosystems/servers/poseidon/README.md actualizado: storage refrescado, tabla de pools rehecha (pool default vacío 45.3 GB libres, pool home 1.5 TiB libres con netbox+nagios+5 más), política nueva escrita, entrada nueva en Changelog.
  • (2026-05-21) #147 Mover nagios.qcow2 al pool home — Resuelto. / poseidon 16% → 10% (46 GB libres), pool default completamente vacío. Nagios responde HTTP 401 en /nagios/ (Basic Auth challenge = servicio vivo). Downtime nagios ~30s (shutdown 7s + mv casi instantáneo + start + boot 10s).

Estado final (2026-05-21)

Triage crítico COMPLETO. Resueltos #143 (diagnóstico) + #145 (mover netbox) + #147 (mover nagios) + #146 (README). #144 (limpieza low-risk) queda abierto como mantenimiento opcional sin urgencia (con 46 GB libres en / ya no aporta valor crítico).

  • / poseidon: 99% → 10% (874 MB libres → 46 GB libres).
  • Pool libvirt default: vacío.
  • Pool libvirt home: ganó netbox.qcow2 + nagios.qcow2.
  • Migración orion→poseidon: DESBLOQUEADA.
  • README de poseidon documentando la política nueva.

status: active puede pasar a done en una próxima pasada del hub.

Notas técnicas

Restricciones del host:

  • Es prod. Mover qcow2 implica apagar la VM (downtime breve, por eso #145 es VM-por-VM, no batch). Coordinar con Sergio antes de tocar cualquier VM con servicio activo (clientes, vitalpbx4, contabilidad-2024, nominas-win2k22, reverse-proxy, wireguard, es-monitoreo, nagios, uisp).
  • VMs candidatas más seguras para mover primero: las shut off (clientes-new, viaticos) — no hay downtime y libera espacio inmediato si están en default.
  • Cross-filesystem mv puede tardar varios minutos en qcow2 grandes (≥20 GB). Usar nohup + tail -f como se hizo en orion el 2026-05-11 si la VM es grande.

Acceso:

  • SSH alias poseidon ya configurado (192.168.20.3:58695, root, llave id_rsa_es).
  • SSH read-only autorizado por default (memoria [[feedback-prod-read-only-diagnostics-authorized]]).
  • Mutaciones (rm, mv, virsh shutdown, virsh define) requieren autorización per-sesión.

Comandos seguros de diagnóstico:

ssh poseidon 'df -h / /home /storage'
ssh poseidon 'du -sh /var/* 2>/dev/null | sort -rh | head -20'
ssh poseidon 'du -sh /var/lib/libvirt/images/* 2>/dev/null | sort -rh'
ssh poseidon 'virsh pool-list --all; virsh pool-info default; virsh pool-info home'
ssh poseidon 'for vm in $(virsh list --all --name); do [ -n "$vm" ] && echo "=== $vm ==="; virsh domblklist "$vm" 2>/dev/null; done'

Bitácora

2026-05-21

  • Pidió Sergio: abrir proyecto separado para el triage de / en poseidon, descubierto como bloqueante de la migración orion→poseidon.
  • Hice: Proyecto creado. Capturados snapshot inicial (load avg 8.35/24, RAM available 9.6 GB, swap 4/4 GB, / 875 MB libres = 99%, 19 VMs running). Definidos 4 pendientes secuenciales (#143 → #144 → #145 → #146).
  • Falta: ejecutar #143 (diagnóstico read-only) en próxima sesión. Coordinar con Sergio antes de cualquier mutación.

2026-05-21 noche tardío — #147 + #146 cerrados, triage crítico completo

  • Pidió Sergio: “dale a los 2” (autorización per-sesión combinada para #146 + #147).
  • Hice #147 primero (para que el README de #146 documentara el estado final):
    1. Pre-checks: virsh dumpxml nagios → CentOS 7, 4 vCPU / 4 GB RAM, MAC 52:54:00:8a:60:c2, vda único qcow2 50G virtual / 3.0G real. IP 192.168.20.6 (de ip neigh previo).
    2. Backup XML: /root/nagios.xml.backup-2026-05-21 (6254 bytes).
    3. Shutdown graceful: ACPI, shut off en ~7s (vs 22s netbox; Nagios CentOS apaga mucho más rápido que Ubuntu).
    4. mv cross-fs: casi instantáneo (3G real). Resultado: 53.69 GB exactos en /home/libvirt/images/, disk size cosmético 3.8G (sparse holes no preservados, sin impacto).
    5. chown qemu:qemu + qemu-img info OK.
    6. Update XML: mismo flow que netbox (sed sobre dumpxml → diff 1 línea → virsh define).
    7. Start: running OK. RSS 619 MB en ~10s post-boot. Ping OK en intento 2.
    8. Validación HTTP: curl http://192.168.20.6/nagios/HTTP 401 (Basic Auth challenge, normal de Nagios Core sin creds = servicio vivo); curl http://192.168.20.6/ → 403 (Apache default).
  • Hice #146: actualicé electrosystems/servers/poseidon/README.md:
    • Storage section refrescada: / ahora “50 GB, 4.7 GB used, 46 GB free (healthy)” en vez del antiguo “TIGHT — do not use”.
    • Tabla de pools rehecha: default empty / 45.3 GB free; home 1.5 TiB free con netbox+nagios+5 más enumerados.
    • Policy section nueva: “no crear VMs en default — reservarlo para ephemeral/test”.
    • Notes section: removida la línea del audit pendiente (ya hecho).
    • Changelog: entrada 2026-05-21 con resumen del triage + ubicación de XML backups.
  • Resultados finales:
    • / poseidon: 99% → 10% (874 MB → 46 GB libres).
    • Pool default: completamente vacío (Allocation 4.63 GiB es el FS overhead, sin imágenes).
    • Pool home: 281 GiB usados, 1.5 TiB libres.
    • ls /var/lib/libvirt/images/ ya solo muestra . .. (sin qcow2).
    • Migración orion→poseidon: vía libre ya documentada.
  • Falta: nada crítico. #144 (limpieza low-risk) queda como mantenimiento opcional sin urgencia. El status del proyecto puede pasar a done en próxima limpieza.

2026-05-21 noche — #145 cerrado, migración orion→poseidon desbloqueada

  • Pidió Sergio: “dale a #145” (autorización per-sesión para la mutación).
  • Hice:
    1. Pre-checks: virsh pool-dumpxml home → target /home/libvirt/images (231G usados / 1.6T libres). virsh dumpxml netbox → vda único en virtio, qcow2 50G virtual / 42G real, SELinux dynamic relabel, DAC dynamic relabel → libvirt re-aplica seclabel al start.
    2. Backup XML: virsh dumpxml netbox > /root/netbox.xml.backup-2026-05-21 (6281 bytes).
    3. Shutdown graceful: virsh shutdown netbox → ACPI a Ubuntu 22.04 (sin guest agent activo) → shut off en ~22s (poll cada 3s).
    4. Mv cross-fs: nohup mv /var/lib/libvirt/images/netbox.qcow2 /home/libvirt/images/netbox.qcow2 en bg. Tardó ~5 min (cp 50G + rm). Monitor por stat -c %s del destino cada 15s mostró progreso lineal ~9 GB/min. Final: 53.69 GB exactos = match exacto con source.
    5. chown + verify: chown qemu:qemu /home/libvirt/images/netbox.qcow2 + qemu-img info → virtual 50G, format qcow2 compat 1.1, sin corrupción. Disk size subió de 42→49 GB (ext4 destino no preservó sparse holes de XFS source; sin impacto funcional).
    6. Update XML + redefine: virsh dumpxml --inactive netbox > /tmp/netbox.xml.newsed -i "s|/var/lib/...|/home/libvirt/images/...|g" → diff confirma una sola línea cambia (line 41, <source file>) → virsh define /tmp/netbox.xml.new. Verificado.
    7. Start: virsh start netbox → running OK. RSS subió linealmente de 270 MB → 1.74 GB en ~60s (PostgreSQL + Redis + gunicorn + nginx levantando, consistente con RSS pre-shutdown).
    8. Validación funcional: ping 192.168.20.15 OK en primer intento, curl https://192.168.20.15/HTTP 200 (6.4s warmup, normal post-boot), curl https://192.168.20.15/api/status/HTTP 200.
  • Resultado:
    • / poseidon: 99% → 16% (874 MB libres → 43 GB libres) ✅
    • Pool default: Allocation 48.34 → 7.60 GiB; Available 1.64 → 42.38 GiB ✅
    • Pool home: 213 → 281 GiB allocated (gain neto +68 GiB en visible; el archivo nuevo ocupa más bytes por sparse holes no preservados — solo overhead cosmético).
    • NetBox sirviendo normal, downtime real estimado ~6 min (shutdown + mv + start + boot).
  • Falta:
    • #146 actualizar electrosystems/servers/poseidon/README.md (quitar banner “TIGHT — do not use” del pool default, registrar nuevo estado, política nueva de allocation).
    • #147 (opcional) mover nagios.qcow2 (3G real) también al pool home si Sergio quiere dejar pool default vacío para retipificación.
    • orion-decommission ya tiene vía libre — el bloqueante de / quedó resuelto. RAM available de poseidon era el otro temor (9.6 GB) y RSS real combinado de las 3 VMs en orion (~2.5 GB) cabe holgado.

2026-05-21 (tarde) — #143 cerrado

  • Pidió Sergio: “vamos a atacar la tarea #143”.
  • Hice: ejecutado diagnóstico read-only sobre poseidon (ssh poseidon autorizado por default). Comandos: df -h / /home /storage, du -sh /var/* | sort -rh | head -20, du -sh /root /opt /tmp /usr/local, ls -lah /var/lib/libvirt/images/, du -sh /var/lib/libvirt/images/*, virsh pool-info default home, virsh domstate/domblklist netbox nagios.
  • Hallazgos:
    • / 50G total, 49G usados, 874M libres (99%) — empeoró 1 MB en la sesión.
    • /var/lib/libvirt/images/ = 45G (el ofensor único; 90% del root).
      • netbox.qcow2 = 42G (running, vda)
      • nagios.qcow2 = 3G (running, vda)
    • Pool default: Allocation 48.34 GiB / Capacity 49.98 GiB → Available 1.64 GiB.
    • Pool home: 1.56 TiB libres → destino obvio.
    • Resto: /var/log 1.2G, /var/tmp 1.2G, /var/cache 264M, /root 53M, /opt /tmp /usr/local ≈ 0.
    • /home (1.8T): 231G usados, 1.6T libres ✓
    • /storage (3.6T): 3.0T usados, 488G libres ✓
  • Conclusión: la limpieza low-risk (#144) ya NO resuelve — máximo ~2 GB recuperables vs 12+ GB necesarios para salir del rango crítico. El fix real es mover netbox.qcow2 del pool default al pool home (libera 42G de golpe → / baja a ~15%). #144 degradado a opcional/mantenimiento; #145 reformulado como acción concreta sobre netbox.
  • Falta: ejecutar #145 (mover netbox.qcow2 a pool home) — requiere autorización per-sesión + ventana de downtime breve coordinada con Sergio. Considerar también mover nagios.qcow2 (3G) en la misma ventana para vaciar pool default.