Problema

En muchos homelabs el hipervisor y el sistema operativo base son piezas separadas que requieren mantenimiento manual: actualizaciones de kernel, configuración de Secure Boot, cifrado de disco y gestión de paquetes. Esa complejidad genera dos patrones de falla recurrentes. Primero, la exposición accidental de datos por configuraciones de seguridad incompletas (TPM sin LUKS, Secure Boot desactivado). Segundo, la pérdida de disponibilidad tras una actualización del host que rompe módulos críticos (por ejemplo, ZFS o drivers) y no hay forma rápida de volver al estado anterior. Cuando se añaden más de veinte servicios, la probabilidad de que alguna de esas piezas falle aumenta exponencialmente, y el tiempo dedicado a “mantener el host” compite con el tiempo dedicado a los propios servicios.

Causa

  1. Separación de capas – Proxmox, Debian y LXC/QEMU se gestionan con herramientas distintas. Cada capa tiene su propio ciclo de vida y su propio mecanismo de actualización, lo que genera drift entre lo que está instalado y lo que está corriendo.
  2. Seguridad opcional – En instalaciones tradicionales el cifrado LUKS y Secure Boot son opcionales; muchos administradores los omiten por conveniencia, dejando el disco sin protección y la cadena de arranque vulnerable a manipulaciones.
  3. Actualizaciones sin rollback – Los sistemas basados en paquetes sobrescriben archivos críticos en el mismo árbol de archivos. Si la actualización introduce incompatibilidades, el host queda inoperativo y la única salida es restaurar desde backup, proceso que a menudo no está automatizado.
  4. Herramientas de backup acopladas al hipervisor – Soluciones como Proxmox Backup Server están diseñadas para el propio hipervisor. Cuando se cambia a otro stack, la falta de una alternativa integrada obliga a crear pipelines ad‑hoc que rara vez alcanzan el mismo nivel de deduplicación y verificación.

Solución

Adoptar un hipervisor immutable que integre seguridad de hardware y un modelo de actualización A/B elimina la mayor parte del drift y reduce la superficie de ataque. La solución se compone de tres bloques:

  1. Plataforma immutable con seguridad forzada

    • Instalar IncusOS (o cualquier distribución que combine hipervisor y OS en una sola imagen inmutable).
    • Verificar que el firmware del servidor tenga Secure Boot habilitado y que el módulo TPM 2.0 esté activo. IncusOS exige al menos uno de esos mecanismos; la combinación de ambos brinda la mayor garantía.
    • El disco se cifra automáticamente con LUKS atado al TPM, por lo que no es necesario crear claves manualmente.

  2. Modelo de actualización A/B

    • IncusOS mantiene dos particiones (slot A y slot B). Cada actualización escribe en la partición inactiva, se valida y, al reiniciar, el gestor de arranque cambia de slot. Si la nueva versión falla, el bootloader revierte al slot anterior sin intervención.
    • Configurar la política de rotación de claves (anual por defecto) y habilitar notificaciones de fallo para que el equipo de operaciones reciba alertas antes de que una actualización cause downtime.

  3. Gestión de workloads con API unificada

    • Utilizar la CLI incus o la API REST para crear tanto contenedores como VMs. La configuración de recursos (CPU pinning, límites de memoria, dispositivos PCI) se declara en un único archivo YAML, lo que simplifica la migración de stacks Docker‑Compose o de máquinas virtuales tradicionales.
    • Para imágenes OCI, usar incus image import y referenciarlas en los perfiles de instancia. La diferencia con Proxmox es que no hay que decidir entre LXC y QEMU; la misma definición se aplica a ambos tipos de workload.

Pasos de migración práctica

  1. Inventario de servicios – Exportar la lista de contenedores y VMs desde el hipervisor actual (pct list, qm list).
  2. Exportar imágenes – Para contenedores LXC, usar pct export <id> <file>.tar.gz. Para VMs, crear snapshots y exportar a formato QCOW2 o RAW.
  3. Convertir a OCI – Si el stack original usa Docker‑Compose, generar imágenes OCI con docker build y subirlas a un registro interno.
  4. Definir perfiles Incus – Crear un perfil base que incluya políticas de red, límites de recursos y dispositivos comunes.
  5. Instanciar workloads – Ejecutar incus launch <image> <name> -p default para cada servicio, ajustando variables de entorno y volúmenes según sea necesario.
  6. Validar conectividad – Probar que los puertos y rutas de red coinciden con la configuración anterior.

Cuándo aplicar esta solución

  • Entornos con más de 10 servicios críticos donde el tiempo de inactividad de la capa de host es inaceptable.
  • Infraestructura que maneja datos sensibles (contraseñas, fotos personales, métricas de salud) y necesita cifrado de disco y arranque verificado por hardware.
  • Equipos que prefieren “set‑and‑forget” para el host, dejando la mayor parte del trabajo a la gestión de contenedores/VMs.
  • Escenarios donde el backup del hipervisor es secundario y la prioridad es la integridad del host; en esos casos se complementa IncusOS con una solución de backup a nivel de workload (por ejemplo, Restic o BorgBackup dentro de cada contenedor).

No es recomendable cuando:

  • Se depende de funcionalidades exclusivas de Proxmox (datacenter‑wide firewall, SDN, HA groups).
  • El hardware no soporta TPM 2.0 o Secure Boot y no se puede habilitar sin reemplazar la placa base.
  • Se necesita una solución de backup incremental a nivel de bloque que sólo ofrece Proxmox Backup Server.

Código

# Verificar que TPM está activo
tpm2_getrandom 8

# Comprobar estado de Secure Boot
mokutil --sb-state

# Listar perfiles Incus existentes
incus profile list

# Crear perfil base con límites de recursos
incus profile create base
incus profile edit base <<EOF
config:
  limits.cpu: "2"
  limits.memory: 2GB
description: Perfil base para workloads ligeros
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: br0
    type: nic
EOF

# Lanzar una instancia OCI a partir de una imagen registrada
incus launch images:myregistry/myapp:latest myapp-instance -p base

Verificación

  1. Arranque seguro – Después de cada actualización, revisar que el mensaje de Secure Boot indica “Verified”.
  2. Cifrado activo – Ejecutar cryptsetup status <mapper> y confirmar que el dispositivo está mapeado con tpm2 como key source.
  3. Rollback automático – Simular una actualización fallida copiando una versión corrupta a la partición inactiva y reiniciar; el sistema debe volver al slot anterior y registrar el evento en journalctl -u incus-updater.
  4. Integridad de workloads – Para cada instancia, ejecutar incus exec <name> -- systemctl status y validar que los servicios críticos están activos.
  5. Backup de datos – Dentro de una instancia, crear un snapshot con Restic y restaurarlo en una máquina de prueba; confirmar que los archivos coinciden byte‑a‑byte.

Notas adicionales

  • Persistencia de datos – IncusOS no permite montar discos directamente en el host; la única forma de persistir datos es a través de volúmenes declarados en la configuración de la instancia. Planificar volúmenes externos (NFS, Ceph) antes de la migración.
  • Monitorización – La API de Incus expone métricas de uso por instancia; integrarlas con Prometheus evita la necesidad de agentes dentro de cada contenedor.
  • Limitaciones de backup – Hasta la fecha, IncusOS no incluye un servidor de backup nativo. La estrategia más sencilla es ejecutar agentes de backup dentro de los contenedores o VMs y almacenar los repositorios en un nodo dedicado.
  • Actualizaciones de firmware – El modelo A/B solo cubre el sistema operativo; el firmware del servidor sigue necesitando actualizaciones manuales. Mantener el BIOS/UEFI actualizado reduce la probabilidad de incompatibilidades con Secure Boot.
  • Depuración de fallos de arranque – Si el host entra en modo de recuperación, usar la consola de la consola de gestión (IPMI/iLO) para inspeccionar los logs de systemd-boot y incus-updater.

Adoptar un hipervisor immutable como IncusOS no elimina la necesidad de buenas prácticas operativas, pero reduce drásticamente los puntos de falla más comunes en homelabs con múltiples workloads. Con la seguridad forzada por TPM y LUKS, el modelo A/B de actualizaciones y una API unificada, la gestión pasa a centrarse en los servicios que realmente importan.