[A04.P005] Refactorizacion documental añadiendo Contexto/Conclusion por fase
This commit is contained in:
@@ -58,6 +58,8 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
|
||||
### ✅ **FASE 1: Preparación del Entorno en srv-dasu** *(completada 2026-03-27)*
|
||||
|
||||
> **Contexto / Conclusión:** El objetivo fue sanear la configuración subyacente del hipervisor Proxmox para abandonar el enrutamiento complejo (NAT/Red Privada 10.x). Se logró al unir el bridge `vmbr0` directo a la red física, permitiendo a las VMs ser tratadas como equipos independientes frente al DHCP de la institución.
|
||||
|
||||
- [x] **1.1:** Verificar estado de srv-dasu: conectividad Tailscale ✅ (100.112.46.104, activo), RAM 15 GB total / 10 GB libres / 12 GB disponibles, disco 94 GB / 30 GB disponibles (68%).
|
||||
- [x] **1.2:** Confirmar que las VMs originales (100, 101, 102) están apagadas ✅ (todas `stopped`).
|
||||
- [x] **1.3:** Definir IDs y configuración de las nuevas VMs:
|
||||
@@ -71,6 +73,8 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
|
||||
### ✅ **FASE 2: Creación de VM SQL Server (sin dominio)** *(completada 2026-03-28)*
|
||||
|
||||
> **Contexto / Conclusión:** Desplegar una prueba de concepto usando Windows Server Core para el motor de base de datos. Se comprobó la viabilidad de utilizar SQL Server Autónomo sin Active Directory, usando W-Zombi y SSH para la gestión headless en una red DHCP.
|
||||
|
||||
- [x] **2.1:** Crear VM 103 en Proxmox ✅ (4 GB RAM, 2 vCPU, 60 GB disco SATA, vmbr0, SeaBIOS, i440fx). MAC: `BC:24:11:8D:EC:46`.
|
||||
- [x] **2.2:** Instalar Windows Server 2022 Core ✅. Instalado vía consola noVNC. Drivers VirtIO instalados vía `pnputil /add-driver D:\*.inf /subdirs /install`. Red operativa (DHCP ISP). Credencial Admin guardada en candados (`dasu-sql2:Administrator`). Backup vzdump realizado (modo stop, zstd, 3.28 GB).
|
||||
- [x] **2.3:** Configurar red: DHCP del ISP ✅. IP actual asignada: `192.168.1.14/24`, gateway `192.168.1.1`.
|
||||
@@ -83,6 +87,8 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
|
||||
### ⏳ **FASE 3: Creación de VM PC Cliente (sin dominio)**
|
||||
|
||||
> **Contexto / Conclusión:** Esta fase resultó transicional / pivotante. Se intentó construir un Windows 10 desde cero que tropezó sistemáticamente con problemas de los drivers de red virtuales. Llevó a repensar la estrategia general y decidir recuperar un "Test-Bed" desde verdaderos backups (Fase 6) para ir a lo seguro.
|
||||
|
||||
- [x] **3.1:** Crear VM 104 en Proxmox (4 GB RAM, 2 vCPU, 50 GB disco SATA, vmbr0, SeaBIOS, i440fx) ✅. Instalador de Win 10 LTS montado en IDE2, VirtIO en IDE0. Red: e1000.
|
||||
- [x] **3.2:** Instalar Windows 10 LTSC ✅.
|
||||
- [x] **3.3:** Configurar red: **DHCP del ISP** (gateway del ISP). Anotar IP asignada. ✅ IP: `192.168.1.15`.
|
||||
@@ -96,6 +102,8 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
|
||||
### ✅ **FASE 4: Nueva VM dasu-sql4 (VM 106)** *(2026-04-09 — 2026-04-10)*
|
||||
|
||||
> **Contexto / Conclusión:** Ante los traspiés de la Fase 3, se re-orquestó un servidor backend definitivo (`dasu-sql4`) puliendo la automatización. Esta iteración incluyó discos separados para SQL (buenas prácticas) y la creación de un túnel/relay seguro con W-Zombi que garantizó el control remoto absoluto sin depender de la GUI de Proxmox.
|
||||
|
||||
- [x] **4.N1:** Crear VM 106 (dasu-sql4) ✅. Eliminar VMs anteriores problemáticas, crear VM limpia.
|
||||
- [x] **4.N2:** ISO Windows Server 2022 Español ✅. Usar `Windows_Server_2022_Spanish_Evaluation.iso`.
|
||||
- [x] **4.N3:** Discos SATA ✅. 60GB (sata0) para SO + 120GB (sata1) para datos SQL.
|
||||
@@ -111,6 +119,8 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
|
||||
### ✅ **FASE 5: Migración de Base de Datos a dasu-sql4** *(completada 2026-04-11)*
|
||||
|
||||
> **Contexto / Conclusión:** Logística de movimientos profundos. Abarcó la exportación de la base legacy comprimida y las transferencias a través de los nodos de la VPN (Tailscale) y SMB. La restauración culminó de manera exitosa corroborando que la arquitectura de hardware virtual fue holgadamente dimensionada (Restore en 26s a 350+MB/s).
|
||||
|
||||
- [x] **5.1:** Obtener backup comprimido de DASUTEN ✅. Generado con `BACKUP DATABASE ... WITH COMPRESSION` en `srvv-fenix` vía `tiny_tds` (script `dasuten_backup_origen.rb`). Archivo: `sysdasuten_compressed_ADN.bak` en `E:\BK_SQL` (~1.33 GB).
|
||||
- [x] **5.2a:** Descargar `.bak` desde `srvv-fenix` → `srv-ns8` (SMB) ✅. 1333 MB descargados a `/var/tmp/` en ~17 seg (76 MB/s).
|
||||
- [x] **5.2b:** Transferir `.bak` desde `srv-ns8` → `srv-dasu` (SCP vía Tailscale) ✅. Re-transferido el 2026-04-11 (se perdió del `/tmp` tmpfs tras reboot por corte de luz).
|
||||
@@ -121,6 +131,8 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
|
||||
### ✅ **FASE 5b: Hardening y Persistencia de Servicios** *(completada 2026-04-11)*
|
||||
|
||||
> **Contexto / Conclusión:** Certificación de autonomía. Una vez resuelta la base, se puso a prueba la tolerancia a fallas. Validamos que el puente sshd y los servicios de SQL arranquen automáticamente sin intervención humana tras reinicios forzados.
|
||||
|
||||
#### Tests de persistencia (sobreviven reboot)
|
||||
- [x] **5b.1:** OpenSSH Server (`sshd`) → StartType: `Automatic`, Status: `Running` ✅
|
||||
- [x] **5b.2:** QEMU Guest Agent → ⚠️ **Incompatible/no instala** en WS2022 con VirtIO 0.1.285. **No bloqueante** — gestión remota asegurada vía SSH :7022.
|
||||
|
||||
Reference in New Issue
Block a user