Virtualization

Problema En entornos Proxmox con ZFS como pool de almacenamiento, es frecuente observar picos de consumo de RAM que superan la capacidad física disponible. Cuando el sistema simultáneamente utiliza swap (ya sea una partición o un volumen ZFS), la presión de memoria puede desencadenar cuelgues del host, reinicios inesperados o mensajes de error como “Purging GPU Memory”. El patrón típico es: Un workload intensivo (por ejemplo, una copia de seguridad nocturna) dispara la expansión del ARC de ZFS. El ARC crece sin límite, ocupando la mayor parte de la RAM. El kernel empieza a paginar hacia swap, que a su vez consume I/O del mismo pool ZFS. La combinación de alta latencia de swap y falta de RAM libre lleva al host a un estado inestable. Este comportamiento no es exclusivo de una configuración concreta; cualquier nodo Proxmox que use ZFS sin restricciones de ARC y que tenga swap habilitado puede experimentar los mismos síntomas. ...

Problema En entornos con varios controladores de dominio (DC) virtualizados, es frecuente que algunos residan en almacenamiento local mientras otros están en un cluster de alta disponibilidad. Cuando se migra una infraestructura de VMware a Hyper‑V, aparecen preguntas recurrentes: ¿Es seguro mover los DC que están en discos locales a los discos del cluster? ¿Debe el nuevo host Hyper‑V formar parte del dominio antes de alojar un DC? ¿Se pueden migrar los DC en vivo sin interrumpir la replicación? ¿Dónde es más apropiado colocar los roles FSMO al añadir un nuevo DC? El problema central es garantizar que la disponibilidad del directorio activo no se vea comprometida mientras se consolida la infraestructura en un cluster Hyper‑V. ...

Problema En entornos con Proxmox VE es habitual crear contenedores LXC a partir de plantillas de Debian bookworm y, posteriormente, ejecutar scripts de ayuda que automatizan tareas de mantenimiento. Cuando el host se actualiza o cuando el propio script se vuelve dependiente de una versión distinta (por ejemplo, Debian trixie), el contenedor sigue reportando su codename original. El script detecta “unsupported version 12” y aborta, dejando al contenedor inoperativo después de un intento de “apt full‑upgrade”. El resultado típico es un contenedor que no arranca, pérdida de la URL de acceso y la necesidad de restaurar una copia de seguridad. ...

Problema En entornos de producción que usan Azure, los cambios de configuración predeterminada y la retirada de SKUs de máquinas virtuales pueden romper pipelines de CI/CD, scripts de aprovisionamiento y políticas de seguridad. Cuando Microsoft anuncia que Trusted Launch será el modo por defecto para cualquier VM Gen2, o que los SKUs cc_v5 de máquinas confidenciales se retirarán, los equipos se ven obligados a revisar plantillas Bicep/Terraform, scripts de PowerShell y procesos de despliegue. Además, la llegada de funcionalidades como Azure Virtual Network Routing Appliance (VNRA), Azure Firewall explicit proxy, Route Server route maps y IPv6 Private Link implica que los diseños de red que antes funcionaban sin esas opciones pueden quedar desalineados con las mejores prácticas actuales. El patrón típico es: una actualización de plataforma introduce un nuevo comportamiento por defecto o elimina recursos, y el código de infraestructura existente no se adapta, generando fallos en despliegues, errores de compatibilidad o brechas de seguridad. ...

Problema En entornos de virtualización con Proxmox VE es frecuente montar directorios NFS desde un NAS para backups, medios o almacenamiento de contenedores. Cuando el cliente NFS deja de responder, el daemon pvestatd entra en bucle de reintentos y el propio host pierde conectividad de la GUI/API. El síntoma típico es un nodo Proxmox “colgado”: no se pueden crear ni migrar máquinas, los servicios web de la interfaz desaparecen y la única salida es un reinicio forzado. El problema no siempre se refleja en los logs del NAS; a veces sólo aparecen mensajes de timeout en el cliente. ...

Problema En entornos donde Veeam Backup & Replication se ejecuta como appliance y los workers son VMs en Proxmox, es frecuente que, tras una actualización o una recreación de workers, los backups fallen porque los workers no pueden comunicarse con el servidor de backup. El síntoma típico es: El test de conectividad del worker devuelve “OK”, pero la descarga del bundle local falla. Los logs indican pérdida de la etiqueta VLAN configurada en la NIC del worker. En algunos casos el worker se elimina automáticamente después de intentar descargar el bundle. Este patrón se repite tanto después de actualizaciones de Veeam (por ejemplo, de 13 a 13.1) como al crear workers nuevos mediante el wizard de Veeam. El problema no está limitado a una versión concreta; cualquier combinación de Veeam appliance + Proxmox + NIC virtio puede presentar el mismo comportamiento. ...

Problema Al restaurar un controlador de dominio (Domain Controller) de Windows Server 2022 mediante una copia Bare Metal de Veeam, el sistema arranca una o varias veces con BSOD (CRITICAL_SERVICE_FAILED). Después de iniciar Windows RE y ejecutar CHKDSK, el equipo vuelve a iniciar sin problemas y los servicios de AD DS, DNS y Netlogon aparecen sanos. El patrón que se repite en varios entornos es: Una restauración Bare Metal (física o como VM) de un DC. El primer arranque muestra una pantalla azul con el código de error. El volumen del sistema está marcado como dirty (fsutil dirty query devuelve “Dirty”). CHKDSK corrige la corrupción y el arranque vuelve a la normalidad. Los síntomas no son exclusivos de Veeam; cualquier proceso que copie bloques de disco sin validar la integridad del sistema de archivos puede dejar el flag dirty y provocar fallos críticos de servicio al iniciar. ...

Problema Implementar un clúster Kubernetes totalmente declarativo en un entorno on‑premise suele chocar con dos limitaciones típicas de los hipervisores tradicionales: la ausencia de un balanceador de carga gestionado y la falta de volúmenes de bloque “cloud‑ready”. Cuando se intenta replicar la experiencia de los módulos de Terraform diseñados para proveedores de nube (por ejemplo, Hetzner o AWS), la infraestructura subyacente de Proxmox no ofrece directamente esas piezas. El resultado es que, aunque la creación de VMs y la instalación de Talos pueden automatizarse, la exposición del API de Kubernetes y la persistencia de datos requieren soluciones manuales o hacks que rompen la promesa de “apply‑only”. ...

Problema En entornos de VDI o laboratorios de pruebas, crear cientos de máquinas Windows a partir de una plantilla implica repetir los mismos pasos: cambiar el nombre del host, asignar IP, unir al dominio y, en algunos casos, añadir discos de datos. Hacerlo manualmente o mediante scripts ad‑hoc genera inconsistencias, errores de sincronización y una carga operativa que no escala. El patrón que se repite es la necesidad de personalizar automáticamente una plantilla Windows después del clonado, de forma que cada instancia quede lista para producción sin intervención humana. ...

Problema En entornos donde Proxmox VE sirve como hipervisor y Rancher gestiona clústeres Kubernetes, la creación manual de máquinas virtuales para cada nodo se vuelve una tarea repetitiva y propensa a errores. Cada vez que se necesita añadir un control‑plane o un worker, el administrador debe clonar una plantilla, ajustar CPU, RAM, discos y ejecutar cloud‑init. Cuando el número de nodos crece o se requiere escalar rápidamente, este proceso se vuelve un cuello de botella. La falta de una integración nativa entre Rancher y Proxmox impide que Rancher realice el aprovisionamiento automático, el escalado dinámico y la limpieza de recursos al destruir un clúster. ...