Hub

electrosystems

orion-decommission

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

Pendientes abiertos (10)

Ver todos →

🎯 Top de ataque (10)

  • #139 📅 2026-06-05 Decidir destino de dokuwiki — coordinar con docs-platform. Opción A: migrar VM tal cual a poseidon. Opción B (ya pre-elegida en docs-platform): importar contenido a Wiki.js y decommissionar el VM sin migrar. RSS real 704 MB / qcow2 20 GB. Decidir antes de iniciar migración.
  • #140 📅 2026-06-10 Migrar otrs a poseidon (primero del lote, la más liviana confirmada en uso). RSS real 1.7 GB / allocated 2 GB / qcow2 20 GB. Observar swap/load 24-48 h antes de pasar a la siguiente. Bloqueado por: triage de / en poseidon (poseidon-root-triage).
  • #141 📅 2026-06-08 Migrar BORRAR traccar2025. ✅ Resuelto el "a dónde": #396 confirmó que el Traccar real vive en el host ares (192.168.3.2, vivo con ~20.5M check-ins). El traccar2025 de orion es un leftover de migración muerto (-incoming, NIC nunca cableado) — no hay servicio que preservar ni migrar. Acción: borrar la VM de orion (confirmar con Sergio antes del virsh undefine/borrado del qcow2). No bloqueante para el decommission.
  • #142 📅 2026-06-20 Considerar +RAM en poseidon como upgrade preventivo (oversubscribed con swap 100%). No bloquea la migración — los 2.5 GB RSS reales de las 3 VMs caben en los 9.6 GB available de poseidon — pero quita el miedo de raíz y compra runway para el refresh del hypervisor (poseidon también es CentOS 7 EOL).
  • #021 📅 2026-06-15 Decommissionar FreePBX/Asterisk local de orion. Descubierto el 2026-05-11. Sergio confirmó (2026-05-11): no está en uso actualmente, se usaba hace mucho tiempo. Se puede prescindir sin problema → simplificar el end-game: solo apagar el servicio + limpiar configuración antes de apagar el host, sin migración a otro PBX.
  • #023 cond:migracion-completa Decidir destino de la VM paused bookstack (parte de docs-platform).
  • #024 cond:migracion-completa Inventariar VMs archivadas en orion y decidir borrado o snapshot off-host antes de apagar.
  • #400 cond:migracion-completa Confirmar nada vivo apunta a orion (DNS, monitoring, scripts en otros hosts).
  • #401 cond:migracion-completa Documentar en INVENTORY.md el cambio de status a "decommissioned" cuando ocurra.
  • #402 cond:migracion-completa Apagar físicamente.

Actividad en bitácora 3 días

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

Orion — Decommission y migración de cargas

Contexto

orion es un hipervisor KVM legado de Electrosystems. MSI MS-7693 (board workstation/consumer reciclado), AMD FX-8350 8-core, 16 GB RAM. CentOS 6 (EOL desde Nov 2020), kernel 2.6.32-504.8.1.el6 (2015). IP 192.168.20.2. Hostea VMs viejas: traccar2025, otrs, dokuwiki (activos), más varias VMs archivadas.

Riesgo operacional activo: /dev/sda2 (root) está al 100% — host-level writes están fallando. La separada /dev/sdb1 (electrorepo, 2.8 TB con 628 GB libres) es el espacio donde podrían moverse las VMs.

Hallazgo 2026-05-11: orion también corre FreePBX/Asterisk activo (asterisk y safe_asterisk running, freepbx.log con escrituras en tiempo real). El README de electrosystems lo describía solo como hypervisor — actualizado el 2026-05-11. Esto cambia el end-game: apagar orion no es solo migrar 3 VMs, también es migrar/decommissionar un PBX que aparentemente está en producción.

End-game: apagar orion y mover sus cargas (3 VMs activas + el PBX local) a un hipervisor moderno (probablemente poseidon, ya hospeda ~16 VMs de producción).

Decisión 2026-05-21: se descartó reemplazar orion con un Dell PowerEdge T110 disponible. El T110 es upgrade en confiabilidad (ECC RAM, iDRAC, chassis server-grade) pero no en performance vs el FX-8350 actual, y no resolvería el problema estructural (CentOS 6 EOL + hardware viejo). Se mantiene el plan original: consolidar en poseidon. Ver bitácora 2026-05-21.

Bloqueante descubierto 2026-05-21: / de poseidon al 99% (875 MB libres), mismo patrón que orion antes de la limpieza. La migración orion→poseidon queda bloqueada hasta que se atienda. Ver poseidon-root-triage.

Tareas pendientes

Urgente — desblockear root partition

  • (2026-05-11) Triage de /dev/sda2 100% lleno → resuelto. Limpieza low-risk liberó 159G de logs/basura/backups viejos (100% → 64%). Migración de 5 qcow2 archivados + ISOs al pool electrorepo libera ~190G adicionales. Detalle en bitácora 2026-05-11.

Migración de cargas activas

  • #138 Validar que traccar2025 está realmente sirviendo → RESUELTO 2026-05-28: NO está sirviendo. Diagnóstico read-only (ver bitácora 2026-05-28): el guest ejecuta (cpu_time avanza, running (restored)) pero su red está completamente muerta — tap vnet0 con RX=5/TX=0 paquetes en toda su vida, 0 en 30s de tcpdump, MAC no resuelve por ARP en su segmento. El RSS=47 MB era pista falsa (VM idle + swap del host, no “rota”). Implicación para el decommission: este servicio NO hay que preservarlo/migrarlo tal cual — está caído. La pregunta abierta (dónde vive el Traccar/GPS real de la flotilla, si existe) se rastrea en amadeus-control-retorno.md #396. #141 (migrar traccar2025) queda en duda — no tiene sentido migrar una VM con servicio muerto; evaluar borrarla en vez de migrarla.
  • #139 📅 2026-06-05 — Decidir destino de dokuwiki — coordinar con docs-platform. Opción A: migrar VM tal cual a poseidon. Opción B (ya pre-elegida en docs-platform): importar contenido a Wiki.js y decommissionar el VM sin migrar. RSS real 704 MB / qcow2 20 GB. Decidir antes de iniciar migración.
  • #140 📅 2026-06-10 — Migrar otrs a poseidon (primero del lote, la más liviana confirmada en uso). RSS real 1.7 GB / allocated 2 GB / qcow2 20 GB. Observar swap/load 24-48 h antes de pasar a la siguiente. Bloqueado por: triage de / en poseidon (poseidon-root-triage).
  • #141 📅 2026-06-08 — Migrar BORRAR traccar2025. ✅ Resuelto el “a dónde”: #396 confirmó que el Traccar real vive en el host ares (192.168.3.2, vivo con ~20.5M check-ins). El traccar2025 de orion es un leftover de migración muerto (-incoming, NIC nunca cableado) — no hay servicio que preservar ni migrar. Acción: borrar la VM de orion (confirmar con Sergio antes del virsh undefine/borrado del qcow2). No bloqueante para el decommission.
  • #142 📅 2026-06-20 — Considerar +RAM en poseidon como upgrade preventivo (oversubscribed con swap 100%). No bloquea la migración — los 2.5 GB RSS reales de las 3 VMs caben en los 9.6 GB available de poseidon — pero quita el miedo de raíz y compra runway para el refresh del hypervisor (poseidon también es CentOS 7 EOL).
  • #021 📅 2026-06-15 — Decommissionar FreePBX/Asterisk local de orion. Descubierto el 2026-05-11. Sergio confirmó (2026-05-11): no está en uso actualmente, se usaba hace mucho tiempo. Se puede prescindir sin problema → simplificar el end-game: solo apagar el servicio + limpiar configuración antes de apagar el host, sin migración a otro PBX.

Cleanup

  • #023 📅 cond:migracion-completa — Decidir destino de la VM paused bookstack (parte de docs-platform).
  • #024 📅 cond:migracion-completa — Inventariar VMs archivadas en orion y decidir borrado o snapshot off-host antes de apagar.

Apagado final

  • #400 📅 cond:migracion-completa — Confirmar nada vivo apunta a orion (DNS, monitoring, scripts en otros hosts).
  • #401 📅 cond:migracion-completa — Documentar en INVENTORY.md el cambio de status a “decommissioned” cuando ocurra.
  • #402 📅 cond:migracion-completa — Apagar físicamente.

Notas técnicas

Restricciones del host:

  • Hardware viejo (consumer-grade), reemplazarlo no es opción.
  • CentOS 6 EOL — sin parches, libvirt/qemu viejo. Cuidado con cualquier virt-clone cross-version: validar que los qcow2 sean compatibles con el qemu de poseidon (CentOS 7).

Bitácora

2026-05-08

  • Pidió Sergio: capturar pendientes del escaneo de electrosystems.
  • Hice: creado este proyecto consolidando los 3 items relacionados con orion (root full + workload migration + bookstack cleanup).
  • Falta: desbloquear root primero (urgente), después planear las migraciones.

2026-05-11

  • Pidió Sergio: arrancar con orion como prioridad del día; objetivo “desbloquear root” (no end-game todavía).

  • Hice:

    • Diagnóstico read-only vía SSH. Cuadro: /var 400G de los 436G; dentro de eso /var/log 151G y /var/lib/libvirt/images 228G. En /opt 25G, /root 4.8G, /tmp 1.8G.
    • Round 1 — golpe grande (142G): rm -rf /var/log/antenas_rrdtool2 (90G, legacy RRD de antenas) + rm /var/log/esconfigbackup.log (52G, archivo único sin rotar de un proceso de backup que Sergio acaba de desactivar). 100% → 68%.
    • Round 2 — logs secundarios (~2.3G): rm /var/log/maillog-*.gz (51 archivos, ~48M, mailogs comprimidos de 2023), rm /var/log/rsyncd.log (1.3G, sin proceso vivo), truncate -s 0 /var/log/smsd.log (723M, daemon vivo desde 2025 — truncate para preservar el FD), rm -rf /var/log/antenas_rrdtool (231M, v1 también legacy).
    • Round 3 — basura + /opt (~18G): rm -rf /tmp/esbackup.orion.electrosystemsnet.com (1.8G, backup en /tmp), rm /root/bd_speedtest.sql (118M), rm -rf /root/zabbix-5.0.1* (132M installer viejo), rm -rf /opt/antenas_backup (16G residuo).
    • Round 2.5 — dudosos confirmados (~11G): rm /var/log/waterhouse_ftp (6.9G), rm -rf /var/log/antenas_rrdtool v1 (legacy), rm /root/Contabilidad-0.qcow2 (3.8G qcow2 huérfano de 2017). Root quedó en 62%.
    • Round 4 — mover qcow2 archivados (lanzado en background nohup, ~190G): creado /media/electrorepo/orion-archived-vms/ + subcarpeta isos/. virsh dumpxml de las 5 VMs shut off guardado como <vm>.xml al lado del qcow2 (Reporteador 80G, plataformas-web 30G, plataformas-web-mario 30G, traccar viejo 20G, vtiger 20G). mv cross-filesystem (sda2 → sdb1) corriendo via script /root/mv-orion-archive.sh con nohup (PPID=1, adoptado por init — sobrevive desconexión). Log en /var/log/orion-mv-archive.log, sentinel /var/log/orion-mv-archive.done al terminar. ISOs viejos también van a isos/ (CentOS 6/7, Ubuntu 18.04/22.04, Proxmox MG 7/8, FreePBX SNG7). Velocidad observada: 16-90 MB/s (varía por load de las VMs activas). Estimado total: 1-3 horas.

    Verificación del Round 4 (cuando Sergio quiera):

    ssh orion 'tail -30 /var/log/orion-mv-archive.log'   # ver avance
ssh orion 'ls -la /var/log/orion-mv-archive.done'    # existe = terminó
ssh orion 'df -h / /media/electrorepo'                # estado final del disco

  • Hallazgos:

    • 🚨 Orion también es FreePBX/Asterisk activo (no documentado en README). safe_asterisk y asterisk corriendo; freepbx.log con writes en tiempo real. Esto cambia el end-game del decommission. Agregada tarea de migración/decom del PBX.
    • VM prometheus (shut off) tiene su qcow2 ya en /media/electrorepo/libvirt/images/ — no requiere movimiento, pero existe.
    • bookstack (paused, 25G) sigue en sda2 — fuera de scope esta sesión (parte de docs-platform).
    • smsd daemon vivo desde 2025 pero su log no escribía desde Sept 2025. Daemon raro, vale revisarlo: ¿sigue siendo necesario? Está sirviendo SMS de Electrosystems o es residuo? Pendiente menor.
    • Asterisk de orion podría tener relación con el cluster ADFSA o ser un PBX independiente. Investigar antes de tocar.

  • Pendientes nuevos disparados por esta sesión (no creados, pero reafirmados):

    • Sergio reafirmó prioridad de vpn-clientes y backups-infra al desactivar esconfigbackup (era backup automático de servidores vía VPN, ya desactualizado). Ambos proyectos ya capturados — no se duplicaron.
    • DokuWiki → Wiki.js ya está en docs-platform.md:31 (diferido 2026-04-25).

  • Falta:

    • Terminar Round 4 (mv en background corriendo).
    • Actualizar README de orion en electrosystems (FreePBX activo + nuevas métricas de disco).
    • Limpieza/análisis adicional: el bookstack.img paused, el daemon smsd huérfano, el rol real del FreePBX local.
    • End-game: migración de las 3 VMs activas + FreePBX a poseidon.

2026-05-21

  • Pidió Sergio: evaluar Dell PowerEdge T110 disponible como reemplazo de orion + recomendación de SO si aplica; después validar capacidad real de poseidon para absorber las cargas.

  • Hice:

    • T110 evaluado y descartado. Análisis: T110 (2009-2010, Xeon X3400/Core i3, máx 32 GB ECC) o T110 II (2011-2013, Xeon E3-1200 v1/v2). Vs orion actual (FX-8350 8-core, 16 GB no-ECC): el FX-8350 rinde parecido o ligeramente mejor en multi-thread que un Xeon E3-1230 v1/v2. Sí mejora confiabilidad (ECC, iDRAC6, chassis server-grade), no mejora performance. Si se hubiera elegido, el SO recomendado habría sido Proxmox VE 8 (KVM + LXC + ZFS + web UI, importa qcow2 directo con qm importdisk). Alternativas: AlmaLinux 9 + libvirt (continuidad RHEL) o Debian 12 + libvirt (minimalista). Sergio confirmó: descartar T110, mantener plan original de consolidar en poseidon.

    • Revalidación read-only de poseidon (snapshot fresco vs README de 2026-04-24):

      MétricaSnapshot 2026-04-242026-05-21Cambio
      Load avg6.3 / 248.35 / 24 (~35%)Subió, OK
      RAM available14 GB9.6 GBEmpeoró
      Swap4/4 GB (100%)4/4 GB (100%)Igual
      / root2.1 GB libres875 MB libres (99%)🚨 Crítico
      VMs running1619 (+docs, +paginas-web, +oxidized)Más carga

    • virsh dommemstat de las 3 VMs activas en orion:

      VMAllocatedRSS realCPUsqcow2
      traccar20254 GB47 MB ⚠️250 GB
      otrs2 GB1.7 GB120 GB
      dokuwiki1 GB704 MB120 GB
      Total7 GB~2.5 GB490 GB

  • Hallazgos:

    • 🚨 Bloqueante real para la migración: / de poseidon al 99% (875 MB libres). Mismo patrón que orion antes de la limpieza. Abierto proyecto separado poseidon-root-triage. Migración orion→poseidon queda bloqueada hasta que se atienda.
    • El miedo de RAM en poseidon NO es el problema. RSS real total a migrar = 2.5 GB, cabe holgado en los 9.6 GB available. Si dokuwiki va a Wiki.js, solo se migran 2 VMs (otrs + traccar) ≈ 1.75 GB RSS. CPU sobra (35% load en 24 vCPU). Disco sobra en pool home (1.57 TiB libres).
    • traccar2025 con RSS = 47 MB es rarísimo — Traccar Java sirviendo GPS debería usar bastante más. O tiene ballooning agresivo (libera lo no usado), o la VM está prácticamente idle/rota. Validación previa a migración añadida como #138.
    • Poseidon ganó 3 VMs nuevas desde el snapshot de abril (docs, paginas-web, oxidized) — la presión es real, no teórica. Refuerza la idea de +RAM preventiva (#142) y el refresh del hypervisor a medio plazo (poseidon también es CentOS 7 EOL desde junio 2024).

  • Falta:

    • Triage de / en poseidon — abierto como proyecto propio poseidon-root-triage (bloqueante).
    • Validar #138 (traccar2025 vivo).
    • Decidir #139 (DokuWiki → Wiki.js o migrar VM).
    • Una vez desbloqueado: migrar otrs → observar 24-48h → migrar traccar2025 → decommissionar FreePBX → apagar orion.