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 libvirtdefaultconsume 45G de 50G; ofensor único =netbox.qcow242G.nagios.qcow23G. 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 pooldefaultal poolhome. 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 pooldefaultpor 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 poseidon —
electrosystems/servers/poseidon/README.mdactualizado: storage refrescado, tabla de pools rehecha (pooldefaultvacío 45.3 GB libres, poolhome1.5 TiB libres con netbox+nagios+5 más), política nueva escrita, entrada nueva en Changelog. - (2026-05-21) #147 Mover
nagios.qcow2al poolhome— Resuelto./poseidon 16% → 10% (46 GB libres), pooldefaultcompletamente 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 endefault. - Cross-filesystem
mvpuede tardar varios minutos en qcow2 grandes (≥20 GB). Usarnohup+tail -fcomo se hizo en orion el 2026-05-11 si la VM es grande.
Acceso:
- SSH alias
poseidonya configurado (192.168.20.3:58695, root, llaveid_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):
- Pre-checks:
virsh dumpxml nagios→ CentOS 7, 4 vCPU / 4 GB RAM, MAC52:54:00:8a:60:c2, vda único qcow2 50G virtual / 3.0G real. IP192.168.20.6(deip neighprevio). - Backup XML:
/root/nagios.xml.backup-2026-05-21(6254 bytes). - Shutdown graceful: ACPI, shut off en ~7s (vs 22s netbox; Nagios CentOS apaga mucho más rápido que Ubuntu).
mvcross-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).chown qemu:qemu+qemu-img infoOK.- Update XML: mismo flow que netbox (sed sobre dumpxml → diff 1 línea →
virsh define). - Start: running OK. RSS 619 MB en ~10s post-boot. Ping OK en intento 2.
- 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).
- Pre-checks:
- 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:
defaultempty / 45.3 GB free;home1.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.
- Storage section refrescada:
- 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
doneen 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:
- 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. - Backup XML:
virsh dumpxml netbox > /root/netbox.xml.backup-2026-05-21(6281 bytes). - Shutdown graceful:
virsh shutdown netbox→ ACPI a Ubuntu 22.04 (sin guest agent activo) → shut off en ~22s (poll cada 3s). - Mv cross-fs:
nohup mv /var/lib/libvirt/images/netbox.qcow2 /home/libvirt/images/netbox.qcow2en bg. Tardó ~5 min (cp 50G + rm). Monitor porstat -c %sdel destino cada 15s mostró progreso lineal ~9 GB/min. Final: 53.69 GB exactos = match exacto con source. - 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). - Update XML + redefine:
virsh dumpxml --inactive netbox > /tmp/netbox.xml.new→sed -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. - 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). - Validación funcional:
ping 192.168.20.15OK 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.
- Pre-checks:
- 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 pooldefaultvacío para retipificación. orion-decommissionya 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.
- #146 actualizar
2026-05-21 (tarde) — #143 cerrado
- Pidió Sergio: “vamos a atacar la tarea #143”.
- Hice: ejecutado diagnóstico read-only sobre poseidon (
ssh poseidonautorizado 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/log1.2G,/var/tmp1.2G,/var/cache264M,/root53M,/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.qcow2del pooldefaultal poolhome(libera 42G de golpe →/baja a ~15%). #144 degradado a opcional/mantenimiento; #145 reformulado como acción concreta sobrenetbox. - 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 pooldefault.