Problema

Muchos entusiastas de homelab instalan Windows Server directamente sobre el hardware para practicar con Active Directory, DNS, IIS y servicios de archivos. A medida que el entorno crece –por ejemplo, al añadir Home Assistant, cientos de dispositivos IoT y contenedores de monitoreo– surge la necesidad de consolidar recursos. La pregunta recurrente es: ¿es conveniente mover Windows Server a una máquina virtual bajo Proxmox o mantenerlo en bare‑metal? La decisión afecta rendimiento, gestión, respaldo y la flexibilidad para escalar otros servicios.

Causa

Los motivos que empujan a considerar la virtualización son varios:

  1. Uso compartido de hardware – Un único servidor que aloje varios sistemas operativos permite aprovechar CPU, RAM y almacenamiento que de otro modo quedarían ociosos.
  2. Facilidad de backup y snapshot – Proxmox ofrece snapshots consistentes y copias de seguridad programadas, algo más complejo de implementar en un host físico.
  3. Aislamiento de fallos – Un problema en Home Assistant o en un contenedor LXC no afecta directamente al controlador de dominio.
  4. Escalabilidad – Añadir nuevas VMs o contenedores es tan sencillo como crear una plantilla; no se necesita re‑instalar otro OS.
  5. Gestión de actualizaciones – Proxmox permite probar actualizaciones de Windows Server en una copia antes de aplicarlas al entorno productivo.

Sin embargo, aparecen riesgos que pueden revertir la decisión:

  • Overhead de virtualización – La capa de hipervisor consume recursos; si el host está justo al límite, el rendimiento de AD, DNS o IIS puede degradarse.
  • Dependencia del hipervisor – Un fallo de Proxmox afecta a todas las VMs, incluida la infraestructura de identidad.
  • Licenciamiento – Ejecutar Windows Server en una VM requiere una licencia que cubra la virtualización; algunos usuarios subestiman este punto.
  • Acceso directo a hardware – Algunas funciones avanzadas (por ejemplo, NICs de alta velocidad o controladores de almacenamiento específicos) pueden no estar disponibles o requerir passthrough, lo que complica la configuración.

Solución

Una estrategia probada consiste en crear una arquitectura híbrida donde Proxmox sea el hipervisor principal y Windows Server se ejecute como una VM con recursos dedicados. Los pasos clave son:

1. Dimensionar la VM

  • CPU: asignar al menos 2 vCPU para un controlador de dominio básico; 4 vCPU si se esperan cargas de IIS intensas.
  • RAM: 8 GB como punto de partida; monitorizar el uso y escalar a 16 GB si el número de objetos de AD supera los 5 000 o si los sitios web consumen mucha memoria.
  • Disco: usar un disco virtual (qcow2 o raw) en un pool de almacenamiento ZFS con deduplicación desactivada para evitar penalizaciones de I/O. Reservar 60 GB para el sistema y datos, ampliando según la cantidad de shares.

2. Configurar passthrough de hardware crítico

Si el entorno requiere alta disponibilidad de red (por ejemplo, controladores de dominio con múltiples NICs), habilitar PCIe passthrough para la tarjeta de red dedicada a la VM:

# Editar /etc/pve/qemu-server/100.conf (asumiendo ID 100)
hostpci0: 0000:03:00.0,pcie=1,rombar=0

Esto permite que Windows Server vea la NIC como física, eliminando la capa de virtual switching para ese tráfico.

3. Implementar discos de arranque separados

Crear una VM para el controlador de dominio y una VM ligera para IIS si la carga web es alta. Mantener los controladores de dominio en un disco de arranque distinto del de los datos (shares) facilita la restauración sin afectar los archivos.

4. Automatizar backups

Proxmox incluye vzdump. Configurar backups diarios incrementales de la VM de Windows Server y almacenar los archivos en un pool de almacenamiento externo (NAS o S3). Un ejemplo de tarea programada:

# /etc/pve/vzdump.cron
0 2 * * * root /usr/bin/vzdump 100 --mode snapshot --compress lzo --mailnotification always

5. Ajustar la red virtual

Crear un bridge (vmbr0) conectado a la NIC física que llevará tráfico de dominio. Asignar una IP estática a la VM y habilitar VLAN tagging si la red doméstica está segmentada.

# /etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
    address 192.168.10.1/24
    bridge_ports enp3s0
    bridge_stp off
    bridge_fd 0

6. Validar la integración de tiempo

AD es sensible a desincronizaciones. Instalar NTP dentro de la VM y asegurarse de que el host Proxmox también sincroniza su reloj con fuentes externas.

w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
w32tm /resync

Cuándo aplicar esta solución

  • Escalabilidad prevista: Si planeas añadir más servicios (Home Assistant, contenedores Docker, máquinas de pruebas) y deseas que coexistan sin re‑instalar hardware.
  • Recursos sobrantes: El servidor físico tiene CPU/RAM suficiente para soportar la carga adicional del hipervisor y la VM de Windows.
  • Necesidad de snapshots: Cuando la capacidad de revertir rápidamente cambios (p.ej., antes de una actualización de AD) es crítica.
  • Entorno de aprendizaje: Si tu objetivo es experimentar con virtualización, clustering o migraciones en un entorno controlado.

No aplicar si:

  • El hardware está al límite de su capacidad y cualquier overhead provocará latencia en AD o IIS.
  • Dependes de dispositivos PCIe que no pueden pasar a la VM (por ejemplo, tarjetas RAID exclusivas).
  • La licencia de Windows Server no cubre virtualización y no puedes adquirir una adecuada.

Código

# Crear una VM en Proxmox con 4 vCPU, 8GB RAM y disco de 60GB en pool 'local-lvm'
qm create 100 --name win2019-dc --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0 --ide2 local:iso/Windows_Server_2019.iso,media=cdrom --scsi0 local-lvm:60
# Iniciar la instalación
qm start 100

Verificación

  1. Conectividad AD: Desde una máquina cliente, ejecutar nltest /dsgetdc:tu-dominio.local. La respuesta debe devolver la IP de la VM.
  2. Resolución DNS: nslookup <nombre_del_controlador> debe resolver a la IP asignada.
  3. Acceso a shares: En Windows, abrir \\<IP_VM>\share y crear un archivo de prueba.
  4. Snapshot funcional: Crear un snapshot en Proxmox, modificar una política de GPO y luego revertir al snapshot; confirmar que la política vuelve a su estado original.
  5. Rendimiento: Medir latencia de autenticación con repadmin /showrepl y comparar con valores esperados (<50 ms en LAN).

Notas adicionales

  • Licenciamiento: Windows Server Standard permite dos máquinas virtuales con una sola licencia. Si necesitas más, considera la edición Datacenter o adquiere licencias adicionales.
  • Passthrough de GPU: No suele ser necesario para AD, pero si planeas ejecutar aplicaciones gráficas en la VM (p.ej., pruebas de Remote Desktop Services), evalúa la compatibilidad del GPU con VFIO.
  • Actualizaciones de Proxmox: Mantén el hipervisor actualizado, pero prueba primero en una VM de pruebas para evitar incompatibilidades con los drivers de la NIC pasante.
  • Monitorización: Usa pveperf y htop dentro del host para observar la carga de CPU y I/O. Si la VM consume >80 % de un recurso, revisa la asignación de vCPU o considera separar roles en VMs diferentes.
  • Redundancia: Si la disponibilidad de AD es crítica, despliega al menos dos controladores de dominio en VMs distintas y replica el SYSVOL. Esto mitiga el riesgo de que un único punto falle dentro de Proxmox.