Virtualization

Problema En entornos homelab es frecuente combinar Proxmox como hipervisor, máquinas virtuales (VM) para aislar servicios y Docker para empaquetar aplicaciones como Jellyfin. Cuando se dispone de un disco HDD de varios terabytes con datos ya existentes, surge la necesidad de que esos datos estén disponibles dentro de un contenedor Docker que se ejecuta en una VM. La cuestión central es decidir la mejor forma de exponer el disco sin reformatearlo ni perder información, y garantizar que la solución sea estable tras reinicios tanto del host como de la VM. ...

Problema En entornos de homelab o pequeñas infraestructuras, es frecuente que el mismo servidor aloje varios servicios críticos: asignación de direcciones IP (DHCP), resolución de nombres (DNS), directorio de usuarios (LDAP) y autenticación de red (RADIUS). Cuando se intenta consolidar todo en un nodo Proxmox, aparecen síntomas como: Clientes que no reciben dirección IP o la reciben con parámetros incorrectos. Resolución de nombres que falla intermitentemente. Fallos de autenticación en Wi‑Fi o VPN porque el servidor RADIUS no puede consultar LDAP. Contenedores que pierden conectividad tras reinicios del host. El patrón es claro: varios servicios comparten puertos, dependencias de red y archivos de configuración que pueden colisionar si no se aislan correctamente. El reto es montar cada servicio de forma que sea fácil de mantener, escalar y, sobre todo, que no interfiera con el resto. ...

Problema Muchas organizaciones intentan sustituir hipervisores tradicionales por Proxmox VE para aprovechar hardware reutilizado y reducir costes. El salto a producción suele tropezar con tres grupos de síntomas recurrentes: Almacenamiento mixto – se combina Ceph, ZFS y arrays externos (iSCSI/NFS/FC) sin una estrategia clara, lo que genera cuellos de botella y pérdida de rendimiento. Corosync inestable – enlaces dedicados con latencia variable, configuraciones de dos nodos sin quorum y dispositivos Q que provocan split‑brain. Migración de VMs – importaciones desde ESXi, controladores VirtIO para Windows y snapshots QCOW2 que no se comportan como se espera. En entornos donde la disponibilidad es crítica, cualquiera de estos puntos puede desencadenar caídas inesperadas, pérdida de datos o migraciones fallidas que obligan a volver al hipervisor anterior. ...

Problema Los entusiastas de homelab suelen iniciar con un único nodo físico y, con el tiempo, añaden más servicios hasta que el hardware original se queda corto. Cuando el crecimiento implica múltiples ubicaciones físicas (por ejemplo, una laptop en casa y varios PCs en otro país), aparecen tres retos recurrentes: Gestión centralizada: Necesidad de controlar VMs/LXCs desde una única consola sin saltar de red en red. Resolución de nombres: Mantener subdomains coherentes (p.ej. nextcloud.home.example.com) cuando los servicios se despliegan en diferentes rangos de IP. Seguridad y conectividad: Garantizar que el tráfico entre sitios sea privado, fiable y que el acceso remoto siga siendo sencillo. Si se ignoran, el homelab se vuelve una colección de máquinas aisladas, difícil de monitorizar y propensa a fallos de DNS o de acceso. ...

Problema En muchos homelabs la tentación de añadir varios dispositivos (NAS, servidores, Raspberry Pi, APs) lleva a una red plana donde todos los equipos comparten el mismo broadcast. Esa arquitectura simplifica la configuración inicial, pero rápidamente se vuelve un riesgo: dispositivos IoT pueden comprometerse y, sin aislamiento, pueden atacar máquinas de gestión o servidores críticos. El patrón recurrente es la necesidad de segmentar la red en zonas lógicas (trusted, internal, iot, guest, servers) y, al mismo tiempo, ofrecer a los usuarios finales una forma sencilla de acceder a servicios internos mediante nombres de dominio amigables y certificados válidos. Cuando la segmentación se combina con un proxy inverso como Nginx Proxy Manager (NPM) y una autoridad de certificación externa (Let’s Encrypt vía DNS‑01), la complejidad de la configuración aumenta y los errores de enrutamiento, firewall o resolución DNS son comunes. ...

Problema En muchos homelabs el punto crítico es garantizar copias de seguridad consistentes de máquinas virtuales (VMs) que pueden superar el terabyte de tamaño. El escenario típico incluye un nodo Proxmox (PVE) que ejecuta varias VMs y un servidor de almacenamiento separado, como Unraid, que expone sus discos mediante NFS o SMB. El objetivo es que los backups se guarden automáticamente en el almacenamiento externo sin interrumpir la operación de las VMs. ...

Problema En entornos de homelab o producción ligera es frecuente ejecutar máquinas virtuales dentro de otras máquinas virtuales (nested virtualization) para probar hipervisores, CI/CD o laboratorios de seguridad. Cuando KVM está habilitado con la opción nested=1, el código de shadow paging del kernel se vuelve un punto crítico: una vulnerabilidad en esa ruta puede provocar un host crash sin necesidad de privilegios de root dentro del guest. La vulnerabilidad CVE‑2026‑53359, conocida como “Januscape”, es un ejemplo reciente que permite a un atacante dentro de una VM anidada ejecutar código que corrompe la tabla de páginas del host y lo reinicia. ...

Problema En muchos homelabs y entornos de pruebas se combina KVM con Proxmox y se habilita nested virtualization para ejecutar máquinas virtuales dentro de otras máquinas virtuales. Esta configuración abre la puerta a vulnerabilidades específicas del hipervisor. La reciente CVE‑2026‑53359, conocida como “Januscape”, afecta al código de shadow paging de KVM cuando la anidación está activada. Un exploit público puede forzar un panic del kernel y derribar el host sin necesidad de privilegios dentro de la VM invitada. El patrón que se repite en varios entornos es: kernel vulnerable + nested = posible caída del host. Cuando el parche aún no está disponible o la actualización es imposible por restricciones de versión, la única defensa práctica es desactivar la anidación para las VMs que no son de confianza. ...

Problema En entornos de virtualización basados en KVM es posible que un proceso dentro de la máquina virtual (guest) ejecute código que comprometa directamente el hipervisor (host). El patrón típico es un use‑after‑free en la gestión interna de la shadow MMU del kernel. Cuando el guest manipula estructuras de página que el hipervisor ya liberó, el hipervisor vuelve a utilizarlas sin validar, lo que permite ejecutar código arbitrario en modo kernel del host. ...

Problema En entornos con Proxmox es frecuente crear contenedores LXC con discos más grandes de lo necesario. Cuando la necesidad de espacio disminuye, la única forma de “encoger” el disco es recrear el contenedor o restaurarlo desde una copia de seguridad con un tamaño diferente. La interfaz web de Proxmox no expone una opción para cambiar el tamaño del disco durante la restauración, lo que obliga a recurrir a la línea de comandos. El reto consiste en restaurar el LXC desde Proxmox Backup Server (PBS) sin perder la configuración y, al mismo tiempo, asignarle un disco más pequeño. ...