El curso lleva cuatro módulos echando en falta lo mismo. En el Módulo 4, el release 3.3.0 no arrancó y desplegar.sh hizo un rollback automático —correcto— pero nadie llegó a diagnosticar por qué no arrancaba, porque no había dónde reproducirlo. En 07-01 practicaste la recuperación de arranque rompiendo el fstab del servidor real, con snapshot previo y cruzando los dedos. En 07-03, el último ejercicio pedía vaciar la caché de página, quitar el ionice y parar la aplicación para medir el planificador de E/S: tres cosas que no se hacen en producción. Y quedó pendiente comprobar si la CPU expone AES-NI al huésped, que es un cambio de configuración de la máquina virtual.

Todo eso apunta a la misma carencia: falta un entorno de pruebas. Esta lección lo construye, y por el camino te enseña la pila de virtualización desde dentro — que es lo que hará que la lección siguiente, contenedores, se entienda por contraste y no por analogía equivocada.

1. Qué es virtualizar: los tres modelos
2. Hipervisores de tipo 1 y de tipo 2
3. Virtualización frente a contenedores
4. KVM, QEMU y libvirt: quién hace qué
5. Instalación y comprobación del soporte
6. virsh: gestionar máquinas desde la línea de comandos
7. Crear una máquina con virt-install
8. Aprovisionamiento desatendido con cloud-init
9. Almacenamiento: formatos, pools y snapshots
10. Red: NAT, aislada y puente
11. Rendimiento: virtio y configuración de CPU
12. Clonar y crear srv-tramontana-pruebas

Virtualizar es ejecutar un sistema operativo completo dentro de otro, haciéndole creer que tiene su propio hardware. El problema técnico de fondo: ciertas instrucciones de la CPU son privilegiadas y solo puede ejecutarlas el kernel. Si el sistema huésped cree ser el kernel y ejecuta una de ellas, hay que interceptarla y hacer algo con ella. Las tres formas de resolverlo definen los tres modelos:

La emulación sigue teniendo su uso: es lo que permite ejecutar ARM sobre x86 (qemu-system-aarch64) o un sistema de 1985. Para virtualizar Linux sobre Linux en la misma arquitectura, es absurdamente lenta.

La paravirtualización fue la técnica dominante antes de 2006 (Xen la popularizó) y exigía un kernel modificado. Hoy sobrevive en algo mucho más importante de lo que parece: los drivers paravirtualizados, virtio, que verás más adelante y que son la diferencia entre una VM lenta y una rápida.

La virtualización asistida por hardware es lo que usa srv-tramontana y lo que se usa en cualquier sitio hoy. Intel la llama VT-x y AMD, AMD-V; ambas añaden un nivel de privilegio por debajo del kernel donde vive el hipervisor.

Y KVM desafía esa clasificación, que es lo interesante: es un módulo del kernel de Linux, así que técnicamente hay un sistema operativo debajo (tipo 2), pero ese sistema operativo se convierte en el hipervisor al cargarlo, con acceso directo a las extensiones de virtualización (tipo 1). La respuesta honesta es que es un híbrido, y en la práctica rinde como un tipo 1.

Tu portátil está ejecutando VirtualBox, que es tipo 2. srv-tramontana es una VM dentro de él. Y en esta lección vas a crear una VM dentro de srv-tramontana, lo que se llama virtualización anidada y requiere que VirtualBox exponga las extensiones de CPU al huésped. Volveremos a ello en el apartado de instalación.

Esta comparación es el puente hacia la lección siguiente, y conviene verla antes de tocar contenedores para no adquirir la analogía equivocada:

La diferencia estructural está en una sola fila del diagrama: cada VM tiene su propio kernel; los contenedores comparten el del anfitrión. De ahí se derivan todas las demás diferencias:

Y las dos consecuencias que hay que retener:

• Para aislamiento de seguridad, la VM es superior. Un escape de contenedor es un fallo del kernel compartido y da acceso al anfitrión. Un escape de VM requiere vulnerar el hipervisor, que es una superficie mucho menor. Por eso los proveedores de nube ejecutan cargas de clientes distintos en VM separadas, no en contenedores del mismo kernel.
• Para densidad y velocidad, el contenedor gana por órdenes de magnitud. Arrancar cien contenedores es cuestión de segundos; cien VM son cien kernels.

No son alternativas: se combinan. Lo habitual hoy es ejecutar contenedores dentro de máquinas virtuales, aprovechando el aislamiento de la VM entre inquilinos y la densidad del contenedor dentro de cada uno.

Tres piezas que se confunden constantemente. Cada una resuelve un problema distinto:

La división de trabajo entre las dos primeras es la clave: KVM se encarga de la CPU y la memoria, que es donde el rendimiento importa; QEMU emula los dispositivos, que se acceden mucho menos. Sin KVM, QEMU emularía también la CPU y tendrías el modelo lento del primer apartado. La combinación se suele escribir «QEMU/KVM».

Y libvirt aporta algo que no es obvio hasta que gestionas más de dos máquinas: una capa de abstracción estable. La línea de comandos de QEMU es larguísima y cambia entre versiones; libvirt define la máquina en XML, y virsh habla siempre igual. Además gestiona redes virtuales, pools de almacenamiento y permisos, y es la API que usan virt-manager, Vagrant, OpenStack y Terraform.

Primero, comprobar que hay soporte de hardware. Y aquí aparece la complicación de la virtualización anidada:

srv-tramontana es una VM de VirtualBox, y por defecto VirtualBox no expone las extensiones de virtualización al huésped. Hay que activarlo desde el anfitrión, con la máquina apagada:

En VMware la opción equivalente es Virtualize Intel VT-x/EPT, y en un servidor físico basta con activar VT-x/AMD-V en la UEFI. Tras encender de nuevo:

Si kvm-ok sigue fallando, la virtualización funcionará por emulación pura: utilizable para probar la mecánica de esta lección, inutilizable para trabajar de verdad.

Fíjate en qemu:///system frente a qemu:///session: el primero son máquinas del sistema, gestionadas por el demonio como root, con acceso a las redes y pools compartidos. El segundo son máquinas del usuario, sin privilegios, con red limitada. Para un servidor, siempre system, y conviene fijarlo para no tener que escribirlo:

Y una comprobación importante que cierra el círculo con 07-01: al instalar libvirt aparece virbr0, la interfaz de la red NAT por defecto, y es exactamente la que costaba 35 segundos de arranque porque systemd-networkd-wait-online esperaba a que tuviera enlace:

Sigue en 12 segundos porque en el ejercicio de 07-01 limitaste systemd-networkd-wait-online a enp0s3 con un drop-in. Sin ese arreglo, instalar libvirt habría vuelto a añadir 35 segundos al arranque, y probablemente nadie habría relacionado las dos cosas.

virsh es la herramienta principal. Sus operaciones esenciales:

La distinción entre shutdown y destroy merece énfasis porque el nombre engaña: destroy no borra nada, es el equivalente a tirar del cable. No destruye la definición ni los discos, pero sí puede dejar el sistema de ficheros del huésped inconsistente. Es la misma lógica del shutdown frente a tirar del cable de 01-05, y el orden correcto es siempre intentar shutdown primero y esperar:

Es exactamente el patrón SIGTERM → esperar → verificar → SIGKILL que aprendiste en 03-06, aplicado a máquinas enteras.

Y virsh console es la herramienta que hace practicable todo lo de 07-01: da acceso a la consola serie del huésped, así que puedes ver el menú de GRUB, entrar en modo emergencia y recuperar un fstab roto sin necesidad de interfaz gráfica. Se sale con Ctrl+].

virt-install es la forma no interactiva de definir y arrancar una máquina. El ejemplo completo, comentado línea a línea:

Los dos últimos van juntos y son la pareja que hace que virsh console funcione: sin console=ttyS0 en la línea de comandos del kernel, el huésped escribiría en una pantalla virtual que nadie mira, y verías una consola en blanco. Es un fallo desconcertante y muy común.

Una instalación interactiva desde el instalador de Ubuntu tarda veinte minutos y hay que responder preguntas. Para un entorno de pruebas que quieres poder recrear, eso no sirve. La alternativa es la siguiente sección.

Las distribuciones publican imágenes de nube: discos ya instalados, con cloud-init dentro, que se configuran solos en el primer arranque a partir de unos datos que les entregas.

Fíjate en la diferencia entre virtual size y disk size: 3,5 GiB declarados, 588 MiB ocupados. Es el aprovisionamiento fino de qcow2, que se explica en el apartado siguiente.

Los datos de configuración se entregan en dos ficheros YAML:

Los dos ficheros se empaquetan en una imagen ISO minúscula que la máquina lee como si fuera un CD:

Y ahora se crea la máquina, con un detalle importante: la imagen descargada no se usa directamente, se crea un disco nuevo que la usa como respaldo:

Menos de dos minutos, sin una sola pregunta, y con la configuración de producción ya aplicada. Y —esto es lo que hace valioso el método— el user-data es un fichero de texto que se versiona en git: la máquina de pruebas es reproducible. Es la misma idea de infraestructura como código que verás con Ansible en 07-06, en su forma más simple.

Fíjate en la diferencia entre ls y du para prueba.raw: ls dice 10 GB, du dice 0. Es un fichero disperso (sparse), así que raw también hace aprovisionamiento fino en sistemas de ficheros que lo soportan. La diferencia real entre los formatos está en otra parte:

La decisión práctica: qcow2 salvo que midas que el 2-5 % de rendimiento importa. Los snapshots y los discos de respaldo valen mucho más que ese margen en un entorno de pruebas, y para producción existen alternativas mejores que ambos (un volumen LVM directo, que es lo que usan muchos hipervisores).

El disco de respaldo (backing file) es la pieza que hace eficiente un laboratorio: la imagen base se comparte y cada VM solo guarda sus diferencias. Diez máquinas de pruebas ocupan la base más diez pequeños ficheros de cambios, no diez sistemas completos. Con una regla que hay que respetar: si modificas la imagen base, todos los discos que se respaldan en ella se corrompen. La base es de solo lectura, en la práctica.

libvirt organiza el almacenamiento en pools, que abstraen dónde viven los discos:

Un pool puede ser un directorio, un grupo de volúmenes LVM, un dispositivo iSCSI, NFS o Ceph. El de tipo logical sobre LVM es interesante aquí: vg-datos ya existe desde 05-04 y usar volúmenes lógicos directos como discos evita la capa de fichero.

Y la advertencia, con el mismo peso que la de 05-04 sobre RAID:

Un snapshot no es una copia de seguridad. Vive en el mismo fichero (o junto a él), en el mismo disco, en la misma máquina. Si el disco falla, si el fichero se corrompe o si alguien borra el directorio, se van el snapshot y el original juntos. No cumple ninguno de los tres requisitos de la regla 3-2-1 de 05-08.

Lo que un snapshot es: un punto de retorno rápido para una operación arriesgada. Exactamente lo que necesitas antes de probar un cambio de kernel. Y tiene dos costes que hay que conocer: cada snapshot activo degrada el rendimiento de escritura, porque cada bloque modificado exige copiar el original primero; y acumular decenas de snapshots encadenados puede hacer el disco inmanejable.

Los snapshots con la máquina en marcha (--live) capturan también la memoria y son mucho más delicados: si la aplicación tiene datos a medio escribir, el estado restaurado puede ser inconsistente. La opción --quiesce pide al agente del huésped que vacíe los sistemas de ficheros antes, y requiere qemu-guest-agent instalado dentro. Para un entorno de pruebas, apagar la máquina y hacer el snapshot en frío es más simple y más fiable.

Los tres modos, y cuándo cada uno:

En NAT, libvirt monta un puente (virbr0), un servidor DHCP y DNS (dnsmasq) y las reglas de traducción de direcciones. La VM sale a Internet con la IP del anfitrión, y desde la red nadie puede iniciar una conexión hacia ella. Para un entorno de pruebas es lo correcto: aislamiento por defecto sin configurar nada.

Y aquí conviene cerrar el asunto de virbr0 y el arranque, porque ahora se ve el mecanismo completo: la interfaz existe desde que libvirt arranca, pero no tiene enlace hasta que una VM se conecta a ella. systemd-networkd-wait-online, en su configuración por defecto, esperaba a que todas las interfaces gestionadas estuvieran en línea, y esa nunca lo estaría con las máquinas apagadas. De ahí los 35 segundos.

Sin elemento <forward>, la red no tiene salida: las máquinas se ven entre sí y con el anfitrión, y nada más. Es lo que se usa para probar una configuración de firewall o analizar algo sospechoso.

El puente es el modo que hace falta cuando la VM debe ser un servidor accesible. Requiere reconfigurar la red del anfitrión con netplan, aplicando 06-01 — y con el mismo cuidado, porque te puede dejar sin acceso a la máquina:

Ese netplan try no es opcional. Configurar un puente por SSH es exactamente el caso para el que existe: si el puente sale mal, pierdes la sesión, y la reversión automática a los 120 segundos te devuelve la máquina.

Y una advertencia específica: el puente reasigna la IP de la interfaz física al puente. Durante la transición hay un corte de red de unos segundos, y si la configuración es incorrecta el corte es permanente. En un servidor remoto sin consola, esto se hace con muchísimo cuidado.

Los dispositivos que QEMU presenta al huésped pueden ser emulados (imita un dispositivo real, como una tarjeta Intel e1000) o paravirtualizados (virtio: un dispositivo que no existe en el mundo real, diseñado para hablar directamente con el hipervisor).

La diferencia es grande y merece verse medida:

Las pistas de que virtio está activo: el disco se llama vda (no sda) y el bus es virtio. Si ves sda con bus sata, estás usando emulación y perdiendo más de la mitad del rendimiento de disco.

Los tres atributos del <driver> también importan:

discard=unmap es el que evita que un disco qcow2 crezca indefinidamente: sin él, borrar datos dentro del huésped no libera espacio en el anfitrión.

Los tres modos:

Y aquí se resuelve el pendiente de 07-03, el de AES-NI:

4,4 GB/s de cifrado AES: eso solo es posible con aceleración por hardware. Con host-model en lugar de host-passthrough, o con una CPU virtual genérica, el mismo openssl speed daría entre 200 y 600 MB/s, y ahí está el factor de cinco a diez que se planteaba como hipótesis en el último ejercicio de 07-03 para la lentitud de la copia cifrada.

La contrapartida de host-passthrough es la migración en vivo: una máquina que ve las extensiones exactas de un procesador no puede migrarse a otro anfitrión que no las tenga, porque el huésped las está usando. Para un entorno de pruebas en un único anfitrión, host-passthrough es la elección correcta.

Dos ajustes más de memoria, mencionados por completitud:

El ballooning permite al anfitrión recuperar memoria de un huésped que no la está usando, mediante un driver dentro del huésped que la «infla». Es útil para densidad, y contraproducente para una base de datos, que reserva memoria compartida y no espera perderla. Las hugepages (<memoryBacking><hugepages/></memoryBacking>) reducen los fallos de TLB del huésped, con la misma lógica que las THP de 07-03, y son habituales en máquinas grandes de base de datos.

La máquina de cloud-init es limpia y reproducible, pero para reproducir un problema de producción a veces hace falta una copia del estado real. virt-clone la hace:

virt-clone copia los discos y genera direcciones MAC y UUID nuevos, que es lo que evita el conflicto que produce copiar el fichero a mano. Pero deja intacto el interior del huésped: mismo nombre de máquina, mismas claves de host de SSH, mismo machine-id. Y eso da problemas reales:

virt-sysprep limpia lo que hace única a una máquina: machine-id —que systemd y el journal usan como identificador—, claves de host de SSH, registros, historial de shell, y configuración de red asociada a la MAC anterior. Sin este paso, dos máquinas con el mismo machine-id producen entradas de journal mezcladas si se centralizan, y dos con las mismas claves de host provocan el aviso de huella cambiada de 06-02.

Y libguestfs permite además trabajar con el disco de una máquina apagada sin arrancarla, lo que resuelve el escenario de 07-01 sin necesidad de un medio de rescate:

Eso es lo que convierte la recuperación de 07-01 en una operación de dos minutos cuando la máquina es virtual: en lugar de arrancar desde un ISO, montar y hacer chroot, se edita el fichero directamente en el disco apagado.

Con srv-tramontana-pruebas en marcha, las cuatro deudas del principio de la lección se pueden liquidar:

Sobre la migración en vivo, para cerrar: libvirt permite mover una máquina en ejecución de un anfitrión a otro sin interrumpirla, copiando la memoria en varias pasadas hasta que queda tan poco por transferir que se puede pausar unos milisegundos y completar el cambio.

Requiere almacenamiento compartido (o --copy-storage-all, mucho más lento) y CPU compatibles —de ahí la contrapartida de host-passthrough—. Es la base del mantenimiento sin cortes: se vacían los anfitriones uno a uno para actualizarlos. Y es un adelanto de 07-07: mover una máquina no es lo mismo que tener alta disponibilidad, porque la migración requiere que el anfitrión origen siga funcionando. Frente a un fallo repentino, no sirve.

Herramientas gráficas y de más alto nivel, mencionadas: virt-manager es la interfaz gráfica de libvirt, cómoda para explorar y para acceder a la consola de una máquina con entorno gráfico; Vagrant define máquinas de desarrollo en un Vagrantfile versionable y funciona sobre libvirt, VirtualBox o VMware, y es la herramienta indicada cuando un equipo entero necesita entornos idénticos; y Terraform y OpenStack operan a escala de infraestructura, hablando también con libvirt por debajo.

• No activar la virtualización anidada. kvm-ok dice KVM is disabled by your BIOS y todo funciona por emulación, diez veces más lento. En VirtualBox, VBoxManage modifyvm <vm> --nested-hw-virt on con la máquina apagada.
• Olvidar console=ttyS0 en la línea de comandos del kernel. virsh console muestra una pantalla en blanco y parece que la máquina no arranca. Va emparejado con --console pty,target_type=serial.
• Usar dispositivos emulados en vez de virtio. Si el disco del huésped se llama sda y no vda, estás perdiendo más de la mitad del rendimiento de disco. Comprueba bus='virtio' en el XML.
• Confundir destroy con borrar. virsh destroy es tirar del cable: no borra nada, pero puede dejar el sistema de ficheros del huésped inconsistente. Usa shutdown y espera.
• Modificar una imagen base que tiene discos respaldándose en ella. Corrompe todos los discos derivados. La base es de solo lectura en la práctica; usa qemu-img rebase si necesitas independizar uno.
• Confiar en un snapshot como copia de seguridad. Vive en el mismo disco y en la misma máquina. No cumple ninguno de los tres requisitos de la regla 3-2-1.
• Acumular snapshots encadenados. Cada uno activo degrada la escritura, y una cadena larga hace el disco inmanejable. Consolida o borra.
• Clonar sin virt-sysprep. Dos máquinas con el mismo machine-id y las mismas claves de host de SSH provocan journals mezclados y avisos de huella cambiada.
• Configurar un puente por SSH sin netplan try. Un puente mal definido te deja fuera de la máquina de forma permanente. La reversión automática a los 120 segundos existe exactamente para esto.
• Omitir discard=unmap. El fichero qcow2 crece indefinidamente porque borrar dentro del huésped no libera espacio en el anfitrión.
• Activar ballooning en una máquina de base de datos. La base de datos reserva memoria compartida y no espera que se la quiten. Provoca degradación difícil de diagnosticar.
• Consejo de método. Versiona el user-data de cloud-init en git junto a los scripts. Una máquina de pruebas que se recrea con un comando en dos minutos se usa; una que hay que reinstalar a mano se abandona en cuanto se desconfigura.

Diseña el user-data de cloud-init para una máquina srv-tramontana-pruebas que reproduzca la configuración de seguridad de producción lo más fielmente posible, y explica qué no se puede reproducir y por qué. Justifica cada decisión.

El release 3.3.0 no arranca. Diseña el procedimiento completo para diagnosticarlo en el entorno de pruebas, usando lo aprendido en 07-01, 07-02 y esta lección, de forma que puedas repetir el intento tantas veces como haga falta.

Marta pregunta si conviene mover Tramontana Reservas a máquinas virtuales gestionadas por KVM en un servidor propio, en lugar del VPS actual. Redacta el análisis: qué se gana, qué se pierde, y qué recomiendas.

Solución 1

Qué NO se puede reproducir, y por qué. Esta es la parte importante del ejercicio, porque determina qué pruebas son válidas:

Y las tres decisiones que conviene justificar porque son contraintuitivas:

1. Mantener ptrace_scope = 1 en pruebas. La tentación es relajarlo para diagnosticar cómodamente. Sería un error: entonces no reproduciríamos el Operation not permitted de 07-02 y las pruebas de diagnóstico no valdrían. Un entorno de pruebas que difiere en seguridad no prueba la seguridad.
2. Mismos UID y GID numéricos. Es fácil dejar que cloud-init asigne los que quiera, y entonces el 2770 sobre el grupo tramontana no se comporta igual, y las pruebas de permisos son inválidas. Los identificadores numéricos son parte de la configuración.
3. log_nivel=debug como única diferencia intencionada, más las herramientas de diagnóstico. Ambas cosas son más de lo que hay en producción, no menos, así que no invalidan nada — y hay que anotarlas, porque el volumen de logs sí difiere.

La última advertencia va al runbook: este user-data contiene la clave pública de SSH y los identificadores de la organización, así que se versiona en el repositorio interno, no en uno público. Y nunca debe contener un secreto real: para eso está pass y el aprovisionamiento posterior.

Solución 2

La clave del diseño es que el diagnóstico debe ser repetible: cada intento parte del mismo estado, para que las diferencias observadas se deban al cambio y no a residuos del intento anterior.

El snapshot en frío es deliberado: un --live capturaría la memoria y, sin --quiesce, podría dejar PostgreSQL inconsistente. Para un punto de retorno, apagado es más simple y más fiable.

Sin esta verificación, un fallo de 3.3.0 podría confundirse con un entorno de pruebas que ya estaba roto.

execsnoop-bpfcc es la elección informada aquí: si el binario arranca y muere en 200 ms, ps no lo verá nunca, y esta herramienta captura cada execve con su código de salida. Es exactamente el caso de uso de la tabla de 07-02.

Y aquí está el árbol de decisión que hace útil este procedimiento, porque cada síntoma tiene una herramienta distinta:

El paso 4e es el que más rendimiento da y el que suele olvidarse: comparar la versión que funciona con la que no. Si la única diferencia es una biblioteca nueva, ya tienes la respuesta sin trazar nada.

Tres decisiones de diseño que justifican el procedimiento:

1. Los observadores se lanzan antes del intento. Un binario que muere en 200 ms no se puede observar a posteriori. Es la diferencia entre tener la evidencia y tener que repetir.
2. El árbol de decisión está escrito antes de empezar. Bajo presión, la tentación es lanzar strace a todo y ahogarse en salida. Con la tabla delante, cada síntoma lleva a una herramienta concreta.
3. El snapshot permite intentos ilimitados. Y esa es la razón de ser de la lección: este diagnóstico no se puede hacer en producción. Cada intento fallido deja un release a medio desplegar, un servicio caído y un rollback. En pruebas, snapshot-revert y otra vez.

Nota final: cuando se encuentre la causa, la corrección se aplica y se prueba en pruebas hasta que revision_salud.sh devuelva 0, y solo entonces se despliega en producción. Que desplegar.sh tuviera rollback automático desde 04-07 evitó el desastre en su momento; tener dónde diagnosticar es lo que permite arreglarlo.

Solución 3

Análisis: migrar Tramontana Reservas a virtualización propia con KVM Para: Marta Vidal · De: Operaciones de sistemas · 18 de agosto de 2026

Recomendación breve: no ahora. Mantener el VPS y usar KVM únicamente para el entorno de pruebas, que es donde el beneficio es inmediato y el riesgo nulo. Detallo el razonamiento.

---

Qué ganaríamos

1. Control completo de la pila. Podríamos ajustar la CPU de la máquina (host-passthrough), la configuración de discos y el planificador de E/S. Recuerda que en las pruebas de rendimiento de esta semana no pudimos determinar si el cifrado de las copias iba acelerado por hardware, precisamente porque no controlamos esa capa.
2. Aislamiento fuerte entre servicios. Podríamos separar la base de datos de la aplicación en máquinas distintas, con una frontera de seguridad real entre ellas. Hoy comparten sistema operativo: un compromiso de la aplicación alcanza directamente a la base de datos.
3. Snapshots antes de cada cambio. Un punto de retorno de segundos, en lugar de depender de la restauración de copias con su RTO de 8 horas.
4. Coste predecible a partir de cierto volumen. Un servidor propio con capacidad para varias máquinas puede salir más barato que cuatro o cinco VPS.
5. Sin dependencia del proveedor en cuanto a versiones de kernel, características disponibles o cambios de precio.

Qué perderíamos, y esto es lo determinante

1. El hardware pasa a ser nuestro problema. Discos, fuentes, memoria, ventiladores. Un disco que falla a las tres de la madrugada hoy lo resuelve el proveedor; con servidor propio lo resolvemos nosotros, y necesitaríamos discos en RAID —recordando que RAID no es una copia de seguridad— y repuestos.
2. La energía, la refrigeración y la red dejan de estar garantizadas. Un servidor en una oficina depende de un solo circuito eléctrico y de una sola línea de datos. Un corte de luz de dos horas es una caída de dos horas. Un alojamiento con SAI redundante y doble acometida cuesta dinero.
3. Un único punto de fallo, y uno nuevo: el anfitrión. Hoy tenemos un servidor que puede fallar. Con virtualización propia tendríamos las máquinas virtuales más el anfitrión, y si el anfitrión cae, caen todas a la vez. Esto es importante: la virtualización no da alta disponibilidad, y creer lo contrario es el error de diseño más común del área. Con un solo anfitrión, el riesgo de caída total aumenta.
4. Aumenta la carga de trabajo, no disminuye. Hoy administramos un sistema operativo. Con virtualización propia administraríamos el anfitrión, el hipervisor, la red virtual, el almacenamiento y cada máquina huésped. Con la plantilla actual, eso es tiempo que sale de otro sitio.
5. Coste inicial real. Servidor con capacidad y redundancia de discos, más alojamiento adecuado, más los repuestos. No es despreciable, y hay que compararlo con el coste anual del VPS a varios años, no a uno.
6. Implicaciones de cumplimiento. Tratamos datos personales de huéspedes. Un servidor propio nos convierte en responsables de la seguridad física del equipo, que hoy es del proveedor y que en nuestro modelo de amenazas figura explícitamente como fuera de alcance. Eso habría que revisarlo con el responsable de protección de datos, y probablemente exigiría cifrado completo del disco raíz y control de acceso al espacio físico.

---

Lo que sí propongo, y ya está en marcha

Usar KVM para el entorno de pruebas, en la propia máquina de administración o en el VPS actual. El beneficio es inmediato y el riesgo, ninguno:

• Esta semana ha permitido, por primera vez, poder diagnosticar el release 3.3.0 que falló en julio y que quedó sin explicación.
• Permite probar cambios de configuración y actualizaciones de kernel antes de aplicarlos en producción.
• Permite ensayar el procedimiento de recuperación del runbook sin tocar el servidor real.
• Se recrea desde cero en dos minutos con un fichero de configuración versionado en git.

Cuándo reconsiderarlo. El análisis cambia si se dan al menos dos de estas condiciones:

Condición	Por qué cambia la decisión
Necesitamos cuatro o más servidores	El coste por máquina del servidor propio baja mucho
Hay presupuesto para dos anfitriones	Solo entonces la virtualización aporta disponibilidad, no la resta
Hay alojamiento profesional disponible	Resuelve energía, refrigeración y red
Hay una persona dedicada a infraestructura	La carga de trabajo deja de salir de otro sitio
El coste del VPS supera claramente la alternativa a tres años	Es cuando la inversión se amortiza de verdad

Y una alternativa intermedia que merece considerarse antes. Si el objetivo real es separar la base de datos de la aplicación por seguridad, o tener un entorno de preproducción permanente, contratar un segundo VPS consigue eso mismo por una fracción del coste y sin asumir la responsabilidad del hardware. Es un paso reversible; comprar un servidor no lo es.

Resumen para decidir. La virtualización propia es la respuesta correcta cuando el problema es escala y hay recursos para hacerla bien. Nuestro problema hoy no es la escala: es que no teníamos entorno de pruebas —resuelto— y que tenemos un único punto de fallo, que es un problema de redundancia y no de virtualización. Ese segundo asunto lo estoy estudiando y te traeré una propuesta con números.

Ya tienes el entorno de pruebas que el curso llevaba cuatro módulos echando en falta, y entiendes la pila que lo sostiene. Sabes qué virtualiza cada pieza: KVM da acceso a las extensiones de la CPU, QEMU emula los dispositivos, libvirt gestiona el conjunto con una API estable, y virsh es la herramienta del día a día. Sabes que destroy es tirar del cable y no borrar, que virsh console es la vía para recuperar un arranque roto sin interfaz gráfica, y que virtio en el disco y en la red es la diferencia entre una máquina lenta y una rápida. Aprovisionas sin intervención con cloud-init a partir de un fichero versionado en git, eliges qcow2 por sus snapshots y sus discos de respaldo sabiendo lo que cuesta ese 2-5 % de rendimiento, y tienes claro que un snapshot no es una copia de seguridad.

Y de paso has cerrado tres asuntos pendientes. El virbr0 que costaba 35 segundos de arranque en 07-01 tiene ahora una explicación completa: una interfaz que existe pero no tiene enlace hasta que arranca una máquina. La duda de 07-03 sobre AES-NI está resuelta: con host-passthrough, el huésped ve las extensiones de la CPU y cifra a 4,4 GB/s, lo que confirma el factor de cinco a diez que se planteaba como hipótesis. Y el release 3.3.0 que falló en el Módulo 4 tiene por fin un sitio donde reproducirse tantas veces como haga falta, con un snapshot como punto de retorno y un árbol de decisión escrito antes de empezar.

Fíjate ahora en el precio que has pagado por el aislamiento fuerte de las máquinas virtuales. Cada VM lleva su propio kernel, tarda medio minuto en arrancar, ocupa gigabytes en disco y reserva cientos de megabytes de memoria solo por existir. Para un entorno de pruebas eso es perfectamente razonable. Para desplegar una aplicación y su base de datos, y poder recrearlas en segundos, es carísimo. Y en el diagrama del tercer apartado ya viste la alternativa: compartir el kernel del anfitrión y aislar solo lo necesario.

En la lección 07-05: Contenedores de Linux y Docker se construye eso, y empieza por la idea que hay que tener clara antes de escribir el primer docker run: un contenedor no es una máquina pequeña, es un proceso aislado. Verás las tres primitivas del kernel que lo hacen posible —los namespaces, que aíslan lo que un proceso ve; los cgroups v2, que son literalmente la misma tecnología del MemoryMax=512M que pusiste en 05-05; y las capabilities de 05-02—, y reconocerás en los namespaces de montaje al chroot con el que reparaste GRUB en 07-01. Después llega Docker: imágenes y capas, un Dockerfile con construcción en varias etapas para no enviar el compilador a producción, volúmenes frente a bind mounts, redes con resolución por nombre, y un compose.yaml que levanta la aplicación y PostgreSQL juntos con comprobaciones de salud. Con dos avisos que la lección se toma en serio: pertenecer al grupo docker equivale en la práctica a tener root, y aquel kernel.unprivileged_userns_clone que dejaste comentado en 06-06 con una nota explicando por qué — ha llegado el momento de entenderla del todo.