Windows Server 2022 en KVM: controladores VirtIO, RDP y licencia

Qué configuramos y por qué

La tarea consiste en desplegar Windows Server 2022 en una máquina virtual KVM/QEMU en un VPS o servidor dedicado propio con Linux. Este escenario se utiliza para ejecutar aplicaciones de Windows, Active Directory para una infraestructura pequeña, software de contabilidad, un host RDS, entornos de pruebas, agentes de CI, servidores de juegos y escritorios remotos.

KVM es un hipervisor integrado en el kernel de Linux. En combinación con QEMU, permite ejecutar Windows casi con rendimiento nativo si el procesador admite virtualización por hardware Intel VT-x o AMD-V. Libvirt añade una gestión cómoda de máquinas virtuales mediante los comandos virsh, configuraciones XML y perfiles de red.

Como resultado, tendrá un host Linux con una VM de Windows Server 2022 que:

• se inicia en modo UEFI con un disco virtual QCOW2 o RAW;
• utiliza controladores virtio para el disco, la red, la memoria y el dispositivo balloon;
• recibe una dirección IP independiente o funciona detrás de NAT;
• es accesible mediante RDP con Network Level Authentication activada;
• está protegida por reglas de firewall y registro de inicios de sesión;
• puede respaldarse en un servidor externo o almacenamiento compatible con S3.

Por qué virtio es importante

Sin virtio, Windows puede funcionar con dispositivos emulados: un disco IDE/SATA y un adaptador Intel e1000. Esto resulta práctico para el primer arranque, pero genera una carga adicional en la CPU del host y limita la velocidad de entrada/salida. Virtio es una interfaz paravirtualizada entre el sistema invitado y KVM. Reduce la sobrecarga y, por lo general, proporciona un rendimiento de disco y red considerablemente mayor.

Para Windows Server 2022 en una configuración típica se necesitan los siguientes controladores: viostor o vioscsi para el disco del sistema, NetKVM para la red, Balloon para la gestión de memoria, viorng para el generador de números aleatorios y QEMU Guest Agent para obtener correctamente la IP, apagar la VM y trabajar con orquestación.

KVM autogestionado y cloud gestionado: qué elegir

KVM autogestionado está justificado cuando se requiere control total, un esquema de red no estándar, varias VM Windows, acceso a ISO propias, laboratorios aislados o copias de seguridad independientes. Si necesita una sola máquina Windows temporal sin administrar el hipervisor, el cloud gestionado suele ser más sencillo.

Qué no se incluye en este escenario

Esta guía está diseñada para un servidor con acceso a KVM. Un VPS convencional que se ejecuta dentro de la máquina virtual de otra persona no siempre puede ejecutar virtualización anidada. Antes de comenzar, compruebe que el proveedor admita explícitamente nested virtualization o proporcione un servidor físico. Si no hay acceso a /dev/kvm, QEMU pasará a la emulación por software y Windows Server funcionará extremadamente lento.

Qué configuración de VPS se necesita para esta tarea

Los recursos deben calcularse no solo para Windows Server 2022, sino también para el host Linux, la caché del sistema de archivos, QEMU y la reserva para picos de carga. No asigne al invitado toda la memoria RAM ni todos los vCPU: el host necesita recursos para el kernel, libvirt, el subsistema de disco, las copias de seguridad y la monitorización.

La configuración mínima práctica para una VM de Windows Server 2022 es de 4 vCPU dedicados, 8 GB de RAM, 100 GB NVMe y un puerto de al menos 100 Mbit/s. Para trabajar cómodamente de forma remota, es mejor contar con 16 GB de RAM en el host: se asignan 8–10 GB a Windows y el resto queda para Linux y la caché de disco.

Como opción básica, puede elegir un VPS con las características indicadas, pero antes de realizar el pedido asegúrese de confirmar la disponibilidad de nested virtualization y de /dev/kvm. Si no está garantizado, elija un servidor dedicado.

Cuándo un VPS no es suficiente

Se necesita un servidor dedicado cuando se planean varias VM Windows, una carga elevada en SQL Server, agentes de compilación, RDS para muchos usuarios, aplicaciones CAD/ERP exigentes o entrada/salida intensiva de disco. También es preferible si se requiere un rendimiento predecible de CPU e IOPS, VLAN, varias IP públicas o la ausencia de limitaciones de nested virtualization.

Para Windows Server con carga gráfica, KVM sin GPU passthrough no sustituye a una estación de trabajo completa. RDP convencional es adecuado para administración, tareas de oficina y aplicaciones de servidor, pero no para visualización 3D, renderizado moderno o cálculos de GPU.

Cómo elegir la ubicación

La ubicación afecta a la latencia de RDP, los requisitos de almacenamiento de datos y la velocidad de restauración desde una copia de seguridad. Para el trabajo interactivo, intente mantener el RTT al servidor por debajo de 50–70 ms. Para una oficina remota, elija una región cercana a los usuarios. Si la VM Windows procesa datos personales, compruebe con antelación los requisitos legales del país de alojamiento y de la transferencia transfronteriza de datos.

Comprobación de la compatibilidad con virtualización

Tras recibir el servidor Linux, ejecute los siguientes comandos. Un valor distinto de cero en el primer comando y la presencia de /dev/kvm indican que se puede utilizar KVM.

# Comprobamos las flags de virtualización por hardware del procesador.
egrep -c '(vmx|svm)' /proc/cpuinfo

# Comprobamos si el dispositivo KVM del kernel de Linux está disponible.
ls -l /dev/kvm

# Comprobamos si la virtualización no está habilitada solo en modo software.
sudo apt update
sudo apt install -y cpu-checker
kvm-ok

El resultado esperado de kvm-ok: KVM acceleration can be used. Si la salida indica que la aceleración no está disponible, no continúe con la instalación hasta resolver el problema con la plataforma: la emulación TCG no es adecuada para el funcionamiento permanente de Windows Server.

Preparación del servidor

Como host se utiliza a continuación Ubuntu Server 24.04 LTS con las actualizaciones vigentes de 2026. El enfoque se mantiene para Debian 12/13 y otras distribuciones Linux, pero los nombres de los paquetes pueden variar. Realice todas las acciones con un usuario independiente que tenga permisos sudo, y no desde una sesión root permanente.

Creación del administrador y las claves SSH

Primero cree un usuario para administrar KVM. Si el servidor ya se proporciona con un usuario normal, este paso puede adaptarse. La clave SSH pública debe añadirse antes de desactivar el inicio de sesión con contraseña.

# Создаём отдельного пользователя для администрирования хоста.
sudo adduser admin

# Добавляем пользователя в группу sudo.
sudo usermod -aG sudo admin

# Создаём каталог для SSH-ключей и задаём безопасные права.
sudo install -d -m 700 -o admin -g admin /home/admin/.ssh

# Добавляем ваш публичный ключ; замените строку на содержимое собственного ключа.
echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExample your-key' | sudo tee /home/admin/.ssh/authorized_keys > /dev/null
sudo chown admin:admin /home/admin/.ssh/authorized_keys
sudo chmod 600 /home/admin/.ssh/authorized_keys

Abra una segunda sesión SSH y compruebe el inicio de sesión mediante clave con el usuario admin. Cambie la configuración de SSH solo después de una comprobación satisfactoria. No cierre la sesión root actual hasta asegurarse de que el nuevo acceso funciona.

# Создаём отдельный файл с безопасными настройками OpenSSH.
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
AllowUsers admin
EOF

# Проверяем синтаксис и перезапускаем SSH только при отсутствии ошибок.
sudo sshd -t && sudo systemctl restart ssh

Actualizaciones y herramientas básicas

Antes de instalar KVM, actualice el sistema. El reinicio es obligatorio si se actualizan el kernel, el microcódigo de la CPU o bibliotecas críticas de virtualización. Planifique esta ventana antes de alojar datos de producción en la VM de Windows.

# Обновляем пакеты Ubuntu до актуальных исправлений безопасности.
sudo apt update && sudo DEBIAN_FRONTEND=noninteractive apt full-upgrade -y

# Устанавливаем полезные утилиты диагностики и управления.
sudo apt install -y curl wget ca-certificates gnupg lsb-release \
  htop jq vim-tiny tmux unzip qemu-utils

# Перезагружаем сервер, если обновлялось ядро или требуется новая версия KVM-модулей.
sudo reboot

Firewall y protección contra intentos de contraseñas

No es necesario abrir el puerto RDP 3389 en el host si la VM de Windows utiliza NAT y se accede a RDP mediante VPN. Si el invitado tiene una IP pública directa, el firewall debe configurarse por separado tanto en el host Linux como en Windows Defender Firewall. A continuación, SSH se deja accesible únicamente desde su IP administrativa. Sustituya la dirección de ejemplo por la suya.

# Устанавливаем UFW и Fail2ban для защиты SSH-хоста.
sudo apt install -y ufw fail2ban

# Запрещаем входящие соединения по умолчанию и разрешаем исходящие.
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Разрешаем SSH только с доверенного внешнего адреса.
sudo ufw allow from 203.0.113.25 to any port 22 proto tcp

# Включаем firewall и проверяем итоговые правила.
sudo ufw enable
sudo ufw status verbose

# Запускаем Fail2ban для блокировки перебора SSH-учётных данных.
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Si tiene una IP dinámica, no restrinja SSH a una sola dirección hasta configurar una VPN o acceso a consola mediante el panel del proveedor. Una alternativa puede ser permitir SSH desde una subred VPN independiente. No abra 3389/tcp a todo Internet «durante las pruebas»: los escáneres y bots encuentran rápidamente estos nodos.

Estructura de directorios

Almacene por separado los ISO, los discos de máquinas virtuales, las exportaciones XML y las copias de seguridad. Esto simplifica el control de permisos, la limpieza de ISO antiguos y la migración de VM. En el ejemplo, los discos virtuales permanecen en el directorio estándar de libvirt y las imágenes de origen se almacenan en /srv/iso.

# Создаём каталоги для ISO, экспортов конфигурации и резервных копий.
sudo install -d -m 0750 /srv/iso
sudo install -d -m 0750 /srv/libvirt-export
sudo install -d -m 0700 /srv/backup

# Проверяем свободное пространство до загрузки ISO и создания дисков.
df -h /srv /var/lib/libvirt/images

Instalación del software — paso a paso

En Ubuntu 24.04 LTS, los paquetes QEMU, libvirt y OVMF se suministran desde el repositorio oficial de Ubuntu. En 2026 no es necesario añadir PPA de terceros para ejecutar Windows Server 2022 de forma básica. Utilice los paquetes estándar: reciben actualizaciones de seguridad mediante el mecanismo habitual de apt.

Instalación de KVM, QEMU y libvirt

# Устанавливаем KVM/QEMU, libvirt, UEFI-прошивки OVMF и virt-install.
sudo apt install -y qemu-kvm qemu-system-x86 libvirt-daemon-system \
  libvirt-clients virtinst ovmf bridge-utils dnsmasq-base

# Запускаем сервис управления виртуальными машинами.
sudo systemctl enable --now libvirtd

# Добавляем администратора в группы управления libvirt и KVM.
sudo usermod -aG libvirt,kvm admin

# Проверяем подключение к локальному гипервизору.
sudo virsh -c qemu:///system list --all

Después de añadir el usuario a los grupos, cierre la sesión SSH y vuelva a iniciarla. Puede comprobar los grupos con el comando id. Para un escenario de servidor no es necesario instalar el gestor gráfico virt-manager en el host: virsh y virt-install son suficientes.

Descarga de ISO de Windows Server y virtio

Descargue el ISO de evaluación de Windows Server 2022 Datacenter o Standard únicamente desde el centro de descargas oficial de Microsoft. Para uso permanente, utilice una imagen que corresponda a su modelo de licenciamiento. Obtenga el ISO de virtio-win desde el proyecto oficial Fedora virtio-win; en 2026, elija una versión estable reciente compatible con Windows Server 2022.

# Перейдите в каталог хранения образов.
cd /srv/iso

# Скопируйте сюда вручную официальный ISO Windows Server 2022.
# Пример ожидаемого имени файла после загрузки:
sudo ls -lh /srv/iso/Windows_Server_2022.iso

# Скачайте ISO с актуальными драйверами virtio-win из официального зеркала проекта.
sudo wget -O /srv/iso/virtio-win.iso \
  https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso

# Проверяем размер и тип загруженных ISO.
file /srv/iso/Windows_Server_2022.iso /srv/iso/virtio-win.iso
sudo ls -lh /srv/iso

Antes de la instalación, compare el SHA-256 del ISO de Windows con el valor publicado por la fuente de descarga. También es útil comprobar la suma de verificación de virtio-win, especialmente si el servidor se encuentra en un entorno con requisitos de seguridad elevados.

# Вычисляем SHA-256 для локальных образов и сверяем с опубликованными значениями.
sha256sum /srv/iso/Windows_Server_2022.iso
sha256sum /srv/iso/virtio-win.iso

Creación del disco virtual

QCOW2 admite snapshots y asignación fina de espacio: el archivo crece a medida que se escriben datos. RAW suele ser más rápido y sencillo para sistemas de almacenamiento externos, pero reserva de inmediato todo el volumen. Para una sola VM de Windows en un NVMe local, resulta conveniente empezar con QCOW2. No mantenga snapshots innecesarios durante meses: degradan el rendimiento y complican la recuperación.

# Создаём QCOW2-диск ёмкостью 120 ГБ для Windows Server.
sudo qemu-img create -f qcow2 \
  /var/lib/libvirt/images/ws2022.qcow2 120G

# Проверяем параметры виртуального диска.
sudo qemu-img info /var/lib/libvirt/images/ws2022.qcow2

Primer inicio del instalador de Windows

El comando siguiente crea una VM con UEFI, 4 vCPU, 8 GB de RAM, controlador SCSI virtio y adaptador de red virtual virtio. El disco será invisible para Windows hasta cargar el controlador vioscsi o viostor desde el segundo ISO. Para un servidor se recomienda virtio-scsi, ya que es más adecuado para varios discos, trim y colas de entrada/salida.

# Создаём и запускаем Windows Server 2022 VM с UEFI и virtio-устройствами.
sudo virt-install \
  --name ws2022 \
  --memory 8192 \
  --vcpus 4 \
  --cpu host-passthrough \
  --os-variant win2k22 \
  --machine q35 \
  --boot uefi \
  --disk path=/var/lib/libvirt/images/ws2022.qcow2,format=qcow2,bus=scsi,discard=unmap \
  --controller type=scsi,model=virtio-scsi \
  --disk path=/srv/iso/Windows_Server_2022.iso,device=cdrom \
  --disk path=/srv/iso/virtio-win.iso,device=cdrom \
  --network network=default,model=virtio \
  --graphics vnc,listen=127.0.0.1 \
  --video virtio \
  --channel spicevmc \
  --channel unix,target_type=virtio,target_name=org.qemu.guest_agent.0 \
  --rng /dev/urandom,model=virtio \
  --noautoconsole

El parámetro --graphics vnc,listen=127.0.0.1 no publica VNC en Internet. Para acceder al instalador, cree un túnel SSH desde su equipo y después conéctese con un cliente VNC a localhost:5900. Compruebe el número de puerto mediante virsh vncdisplay.

# Узнаём номер локального VNC-дисплея созданной VM.
sudo virsh vncdisplay ws2022

# На локальном компьютере создаём защищённый SSH-туннель к VNC.
ssh -L 5900:127.0.0.1:5900 admin@SERVER_IP

# На хосте проверяем, что VM действительно запущена.
sudo virsh list --all

Si vncdisplay devuelve :1, utilice el puerto 5901 en lugar de 5900. En el cliente VNC, indique la dirección 127.0.0.1:5901. Tras configurar RDP, puede mantener VNC como consola de emergencia, pero el acceso debe seguir siendo únicamente mediante túnel SSH.

Instalación del controlador de disco virtio

En la interfaz de instalación de Windows, seleccione la edición, acepte los términos de licencia y en la pantalla de selección de disco haga clic en Load driver. Abra la segunda unidad de CD-ROM con el ISO virtio-win. Para la configuración de esta guía, cargue el controlador desde el directorio vioscsi\2k22\amd64. Tras cargar el controlador, aparecerá el disco virtual de 120 GB.

1. Haga clic en Load driver.
2. Seleccione el dispositivo con el ISO virtio-win.
3. Abra vioscsi, luego 2k22 y amd64.
4. Confirme la instalación del controlador Red Hat VirtIO SCSI.
5. Seleccione el disco que aparece, cree las particiones automáticamente y continúe con la instalación.

Si eligió el bus virtio en lugar de scsi, necesitará el controlador viostor\2k22\amd64. No cargue controladores aleatorios para otra versión de Windows: el instalador puede aceptarlos, pero el sistema tendrá una configuración inestable.

Instalación del conjunto completo de controladores en Windows

Después del primer inicio de sesión en Windows, abra la segunda unidad de CD-ROM y ejecute virtio-win-guest-tools.exe. Este instalador añadirá el controlador de red, Balloon, QEMU Guest Agent, RNG y los demás componentes. Realice la instalación como administrador local y reinicie la VM.

# На Linux-хосте проверяем статус гостевого агента после установки в Windows.
sudo virsh dominfo ws2022

# После установки QEMU Guest Agent в Windows эта команда покажет IP гостя.
sudo virsh domifaddr ws2022 --source agent

# Сохраняем XML-конфигурацию VM до дальнейших изменений.
sudo virsh dumpxml ws2022 | sudo tee /srv/libvirt-export/ws2022.xml > /dev/null

Para comprobar los controladores en Windows, abra Device Manager. No debe haber dispositivos con un icono amarillo en la lista. En la sección de adaptadores de red debe mostrarse Red Hat VirtIO Ethernet Adapter y, en dispositivos del sistema, VirtIO Balloon Driver y VirtIO RNG Device.

Configuración

Después de instalar Windows, configure la red, RDP, las actualizaciones, las cuentas y las licencias. El principio principal: no exponga el escritorio remoto directamente a Internet sin restricciones. La opción más segura es acceder a RDP mediante WireGuard o una VPN corporativa. Si todavía no dispone de VPN, restrinja el puerto 3389 a IP externas específicas en Windows Firewall y el firewall de red.

Esquema de red: NAT o una IP pública independiente

De forma predeterminada, libvirt utiliza la red NAT default, normalmente con la subred 192.168.122.0/24. Windows recibe una IP privada y accede a Internet a través del host Linux. Esta es una buena opción inicial: el sistema invitado no es visible desde el exterior y la administración puede realizarse mediante VPN o un túnel SSH.

# Проверяем сеть libvirt и список DHCP-арендованных адресов.
sudo virsh net-list --all
sudo virsh net-dhcp-leases default

# Проверяем IP Windows VM через QEMU Guest Agent.
sudo virsh domifaddr ws2022 --source agent

# Проверяем доступность RDP-порта внутри приватной сети после его включения.
nc -vz 192.168.122.100 3389

Sustituya 192.168.122.100 por la IP real de Windows. Para acceder desde el equipo de trabajo, puede crear un túnel SSH a través del host Linux. Esto no requiere abrir el puerto 3389 en la red pública.

# На рабочем компьютере пробрасываем локальный RDP-порт к Windows через SSH-хост.
ssh -N -L 13389:192.168.122.100:3389 admin@SERVER_IP

# Затем подключайтесь RDP-клиентом к адресу 127.0.0.1:13389.

Para el acceso permanente de varios empleados, es mejor utilizar WireGuard. En este caso, RDP se permite únicamente desde la subred VPN, por ejemplo 10.66.0.0/24. La publicación de un reenvío NAT SERVER_IP:3389 solo es aceptable con una lista blanca de IP estricta y protección adicional, pero la VPN sigue siendo la opción preferible.

Habilitación de RDP mediante PowerShell

Abra PowerShell como administrador en la consola de Windows o mediante VNC y ejecute los comandos siguientes. Habilitan Remote Desktop, activan la regla de Windows Firewall, requieren Network Level Authentication y permiten conexiones únicamente a los miembros del grupo Remote Desktop Users.

# Включаем Remote Desktop в системных настройках.
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' 
  -Name 'fDenyTSConnections' -Value 0

# Включаем правило firewall для входящего RDP.
Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'

# Требуем Network Level Authentication для RDP-клиентов.
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' 
  -Name 'UserAuthentication' -Value 1

# Перезапускаем службу удалённых рабочих столов.
Restart-Service TermService

Cree una cuenta independiente para RDP en lugar de iniciar sesión permanentemente con el Administrator integrado. Utilice una contraseña larga y única o una cuenta de dominio si la VM posteriormente formará parte de Active Directory. Es preferible renombrar el administrador local integrado y utilizarlo únicamente para acceso de emergencia mediante VNC.

# Создаём отдельного локального пользователя для администрирования по RDP.
$password = Read-Host -AsSecureString 'Введите сложный пароль'
New-LocalUser -Name 'rdpadmin' -Password $password -FullName 'RDP Administrator'

# Разрешаем созданному пользователю вход через Remote Desktop.
Add-LocalGroupMember -Group 'Remote Desktop Users' -Member 'rdpadmin'

# Проверяем, кто имеет доступ к RDP.
Get-LocalGroupMember -Group 'Remote Desktop Users'

Restricción de RDP por IP

Si RDP está disponible directamente mediante reenvío de puertos o una IP independiente, restrinja el origen del lado de Windows. A continuación se muestra un ejemplo de regla que permite RDP únicamente desde una oficina y una subred VPN. Después de añadirla, asegúrese de que su conexión actual no quede bloqueada.

# Создаём более строгое RDP-правило для доверенных источников.
New-NetFirewallRule -DisplayName 'RDP only from trusted networks' 
  -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow 
  -RemoteAddress '203.0.113.25','10.66.0.0/24'

# Отключаем широкое встроенное правило после проверки нового правила.
Disable-NetFirewallRule -DisplayGroup 'Remote Desktop'

# Проверяем активные правила, затрагивающие RDP.
Get-NetFirewallRule | Get-NetFirewallPortFilter |
  Where-Object { $_.LocalPort -eq '3389' }

El comando que deshabilita el grupo integrado puede desactivar RDP si la nueva regla se configura con un error. Ejecútelo únicamente desde la consola VNC o teniendo un segundo canal de acceso. En un entorno con VPN, es mejor permitir únicamente la subred VPN y no añadir IP domésticas dinámicas.

Licencia y activación de Windows Server 2022

Windows Server 2022 no puede utilizarse legalmente de forma permanente sin los derechos de virtualización adecuados. KVM no verifica técnicamente la licencia, pero la responsabilidad del cumplimiento de las condiciones recae en el propietario de la instalación. No utilice activadores KMS públicos, claves piratas ni scripts de terceros: infringen los términos de licencia y a menudo contienen código malicioso.

En la práctica, se encuentran los siguientes modelos:

• Retail/FPP. Normalmente es adecuado para una instalación, pero las condiciones de transferencia y virtualización deben verificarse para la edición y el contrato específicos.
• OEM. A menudo está vinculada al hardware original y normalmente no es adecuada para transferirla a un servidor alquilado.
• Volume Licensing. Claves MAK o KMS corporativas con derechos definidos por el acuerdo de la organización.
• SPLA/CSP-hosted. Licenciamiento a través de un proveedor de servicios, utilizado frecuentemente para infraestructura alquilada.
• Evaluation. Edición de evaluación temporal para pruebas; no debe considerarse una licencia permanente.

Windows Server Standard normalmente proporciona derechos para un número limitado de instancias virtuales al licenciar todos los núcleos físicos del servidor conforme a las reglas de Microsoft. Datacenter está diseñado para una virtualización intensiva. En un servidor dedicated o VPS alquilado, las licencias son especialmente sensibles: los derechos de BYOL, mobility y alquiler dependen del contrato y del tipo de infraestructura. Si tiene dudas, solicite una confirmación por escrito al socio de licencias o a un asesor jurídico especializado en software corporativo.

# Проверяем установленную редакцию Windows и статус лицензирования.
DISM /online /Get-CurrentEdition
slmgr /dli
slmgr /xpr

# Устанавливаем собственный легальный ключ продукта.
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

# Запускаем активацию через разрешённый канал Microsoft.
slmgr /ato

El comando slmgr /xpr mostrará si el sistema está activado de forma permanente, temporal o se encuentra en período de evaluación. Para Volume Licensing, utilice únicamente la clave corporativa y el método de activación aprobado por su organización. No guarde la clave en el XML de la VM, el historial de shell, un repositorio público de Git ni un script de copia de seguridad.

Configuración de actualizaciones y del agente invitado

En Windows Server 2022, habilite las actualizaciones automáticas mediante Windows Update o un sistema centralizado de gestión de actualizaciones. Para una VM individual, resulta óptima una ventana de mantenimiento mensual: actualización, reinicio, comprobación de RDP y del estado de los servicios. No deshabilite las actualizaciones en nombre de la «estabilidad»: RDP y los servicios de Windows reciben regularmente correcciones críticas.

# Проверяем, что QEMU Guest Agent установлен и запущен.
Get-Service -Name QEMU-GA -ErrorAction SilentlyContinue

# Настраиваем автоматический запуск агента.
Set-Service -Name QEMU-GA -StartupType Automatic
Start-Service -Name QEMU-GA

# Проверяем состояние RDP-службы.
Get-Service -Name TermService

TLS/HTTPS mediante Caddy o certbot no es necesario en este escenario: RDP utiliza su propio cifrado TLS y no se despliega ningún servicio web en el host Linux. No intente usar un proxy de RDP mediante un reverse proxy HTTP convencional. Si necesita acceso remoto desde un navegador, implemente una puerta de enlace independiente como Apache Guacamole detrás de HTTPS, pero se trata de una arquitectura diferente con requisitos adicionales de autenticación y seguridad.

Comprobación de funcionamiento

La comprobación debe confirmar el funcionamiento de todos los niveles: host KVM, VM, red, RDP y licencia. Ejecute los comandos en el host Linux y en Windows. Después de cada reinicio de Windows, compruebe que la máquina vuelva automáticamente a un estado operativo.

# Проверяем автозапуск VM после перезагрузки Linux-хоста.
sudo virsh autostart ws2022
sudo virsh dominfo ws2022

# Проверяем гостевой агент и IP-адрес Windows.
sudo virsh domifaddr ws2022 --source agent

# Проверяем открытый RDP-порт из Linux-хоста.
nc -vz 192.168.122.100 3389

# Проверяем, что виртуальный диск не содержит ошибок формата.
sudo qemu-img check /var/lib/libvirt/images/ws2022.qcow2

Para la conexión RDP, utilice un cliente moderno: Microsoft Remote Desktop, mstsc.exe, FreeRDP o Remmina. Conéctese mediante un túnel SSH o VPN. En la primera conexión, compruebe la huella del certificado RDP y no ignore la advertencia sobre un cambio repentino de certificado en un servidor ya conocido.

Copias de seguridad y mantenimiento

Un snapshot no es una copia de seguridad. Un snapshot se encuentra en el mismo servidor y no protege contra la eliminación de la VM, el fallo del SSD, la vulneración del host o un error del administrador. Para Windows Server en KVM, utilice la regla 3-2-1: al menos tres copias de los datos, en dos tipos de medios, con una copia fuera del servidor principal.

Qué se debe guardar

• el disco virtual ws2022.qcow2 o una imagen RAW;
• la configuración XML de la VM desde virsh dumpxml;
• los parámetros de red de libvirt, si se utilizan bridge/VLAN personalizados;
• Windows System State para Active Directory, certificados y roles del sistema;
• bases de datos de aplicaciones, exportadas mediante las herramientas de los propios SGBD;
• claves de BitLocker e información de licencias, almacenadas en un gestor de secretos seguro;
• documentación: direcciones IP, VLAN, reglas de firewall y procedimiento de recuperación.

Para obtener una copia coherente de una VM en funcionamiento, utilice QEMU Guest Agent y snapshots externos, o planifique una breve ventana de apagado. La opción más sencilla y fiable para una VM Windows pequeña es apagar el invitado normalmente, copiar la imagen y luego iniciar la VM. Esto genera varios minutos de inactividad, pero hace que la copia sea predecible.

Copia de seguridad con restic

Restic cifra las copias de seguridad en el lado del cliente y admite almacenamientos compatibles con S3, SFTP y servidores independientes. No guarde la contraseña del repositorio dentro del script ni en el directorio personal del usuario sin permisos restringidos. En el ejemplo, los secretos se encuentran en un archivo accesible solo para root.

# Устанавливаем restic из официального репозитория Ubuntu.
sudo apt install -y restic

# Создаём защищённый файл окружения для S3-совместимого удалённого хранилища.
sudo tee /root/.restic-ws2022.env > /dev/null <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.net/windows-kvm-backup"
export RESTIC_PASSWORD="REPLACE_WITH_LONG_UNIQUE_REPOSITORY_PASSWORD"
export AWS_ACCESS_KEY_ID="REPLACE_WITH_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="REPLACE_WITH_SECRET_KEY"
EOF

# Ограничиваем чтение файла только пользователем root.
sudo chmod 600 /root/.restic-ws2022.env

# Инициализируем пустой зашифрованный репозиторий.
sudo bash -c 'source /root/.restic-ws2022.env && restic init'

Sustituya los valores en el archivo de entorno antes de ejecutar restic init. En producción, es mejor transmitir los secretos mediante almacenamiento seguro, systemd credentials o secretos de CI/CD. Guarde la contraseña del repositorio por separado del propio bucket de S3: sin ella, no será posible restaurar la copia de seguridad cifrada.

# Создаём скрипт: выключает VM, экспортирует XML, сохраняет данные и запускает VM обратно.
sudo tee /usr/local/sbin/backup-ws2022.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

VM="ws2022"
DISK="/var/lib/libvirt/images/ws2022.qcow2"
EXPORT_DIR="/srv/libvirt-export"
ENV_FILE="/root/.restic-ws2022.env"

source "$ENV_FILE"

mkdir -p "$EXPORT_DIR"
virsh dumpxml "$VM" > "$EXPORT_DIR/${VM}.xml"

STATE="$(virsh domstate "$VM")"
if [ "$STATE" = "running" ]; then
  virsh shutdown "$VM"
  for _ in $(seq 1 60); do
    sleep 5
    [ "$(virsh domstate "$VM")" = "shut off" ] && break
  done
fi

if [ "$(virsh domstate "$VM")" != "shut off" ]; then
  echo "VM did not shut down safely" >&2
  exit 1
fi

restic backup "$DISK" "$EXPORT_DIR" \
  --tag windows-server-2022 \
  --exclude '.tmp'

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

virsh start "$VM"
EOF

# Делаем скрипт исполняемым и запускаем первый тестовый бэкап вручную.
sudo chmod 700 /usr/local/sbin/backup-ws2022.sh
sudo /usr/local/sbin/backup-ws2022.sh

# Запускаем резервное копирование ежедневно в 03:30 через root cron.
sudo crontab -e

# Добавьте следующую строку в crontab:
30 3    /usr/local/sbin/backup-ws2022.sh >> /var/log/backup-ws2022.log 2>&1

# Проверяем список созданных snapshot в restic.
sudo bash -c 'source /root/.restic-ws2022.env && restic snapshots'

Verificación de la restauración

Una copia de seguridad se considera operativa solo después de una restauración de prueba. Una vez por trimestre, restaure una copia en un disco de prueba independiente, importe el XML con un nuevo nombre de VM, iníciela en una red aislada y compruebe que Windows se inicia. No encienda la copia restaurada simultáneamente con el controlador de dominio original en la misma red: esto puede provocar un conflicto de AD y DNS.

# Восстанавливаем последний snapshot в отдельный каталог для теста.
sudo install -d -m 0700 /srv/restore-test
sudo bash -c 'source /root/.restic-ws2022.env && restic restore latest --target /srv/restore-test'

# Проверяем восстановленный QCOW2-образ до импорта.
sudo qemu-img check /srv/restore-test/var/lib/libvirt/images/ws2022.qcow2

Actualizaciones y ventana de mantenimiento

Para una sola VM, utilice una ventana de mantenimiento una vez al mes: actualice el host Linux, haga una copia de seguridad, actualice Windows, reinicie la VM y compruebe RDP. Las actualizaciones rolling solo son aplicables si hay varias réplicas de la aplicación o un clúster; una VM Windows única no puede actualizarse sin una posible interrupción.

Antes de actualizar virtio-win, cree un snapshot o una copia de seguridad completa. Los nuevos controladores suelen ser compatibles, pero el controlador de red o de disco son componentes críticos. Mantenga disponible la consola VNC mediante un túnel SSH para restaurar la red de Windows si NetKVM cambia la interfaz o el perfil de firewall después de la actualización.

Solución de problemas + FAQ

¿Por qué Windows Server 2022 no ve el disco en el instalador?

Con mayor frecuencia, no se ha cargado el controlador virtio para el tipo correcto de controlador. Si la VM se creó con virtio-scsi, en la ventana Load driver se necesita la ruta vioscsi\2k22\amd64. Para un bus virtio normal se necesita viostor\2k22\amd64. Compruebe también que la ISO de virtio-win está conectada como segundo CD-ROM y que el archivo ISO no está dañado. No cambie el tipo de controlador después de instalar Windows sin haber instalado previamente el controlador necesario.

Error: KVM acceleration can not be used. ¿Qué hacer?

Compruebe la presencia de /dev/kvm, las marcas vmx o svm en /proc/cpuinfo y la salida de kvm-ok. En un VPS, la causa suele ser que el proveedor no ha habilitado la virtualización anidada. Dentro de una VM invitada no es posible habilitar VT-x o AMD-V por cuenta propia. Solicite soporte para KVM anidado o traslade el host Linux a un servidor dedicated. No ejecute un Windows Server de producción mediante emulación de software QEMU: el rendimiento será inadecuado.

¿Qué configuración mínima de VPS es adecuada?

Para una VM Windows Server 2022 ligera, utilizada por uno o dos administradores mediante RDP, son prácticos como mínimo 4 vCPU, 8 GB de RAM y 100 GB de NVMe. Puede asignar a Windows 2 vCPU y 4–6 GB de RAM, dejando margen para el host Linux. La condición obligatoria es más importante que las cifras: el VPS debe proporcionar acceso a KVM o admitir oficialmente la virtualización anidada. Para funcionamiento permanente, es preferible disponer de 16 GB de RAM en el host.

RDP está habilitado, pero no se establece la conexión. ¿Qué comprobar?

Compruebe el servicio TermService en Windows, la regla de Windows Defender Firewall y la disponibilidad del puerto TCP mediante el comando Test-NetConnection o nc -vz desde el host Linux. Si la VM utiliza NAT, asegúrese de conectarse mediante un túnel SSH, VPN o redirección de puertos correcta. Compruebe también la IP del invitado mediante virsh domifaddr ws2022 --source agent. Después de actualizar NetKVM, Windows a veces cambia el perfil de red, por lo que el firewall aplica reglas más estrictas.

¿Qué elegir para esta tarea: VPS o dedicated?

Un VPS es adecuado para una VM Windows pequeña, un entorno de pruebas o varios usuarios ligeros de RDP con virtualización anidada garantizada. Un servidor dedicated es mejor para varias VM, SQL Server, Active Directory con roles críticos, entrada/salida intensiva de disco, RDS para un equipo y requisitos de recursos garantizados. Un servidor dedicated también es más fácil de licenciar en algunos escenarios corporativos, ya que se conocen las características físicas del host. La decisión final depende de la licencia, la carga y los requisitos de aislamiento.

Windows funciona lentamente aunque vCPU y RAM son suficientes. ¿Cuál es la causa?

Compruebe si la VM utiliza disco virtio y NetKVM, en lugar de dispositivos SATA/e1000 emulados. En el host, ejecute iostat, htop y compruebe el espacio libre: un disco QCOW2 lleno y un almacenamiento de red lento empeoran notablemente la respuesta. No mantenga snapshots QCOW2 durante mucho tiempo. Asegúrese también de que la VM no reciba más vCPU de las físicamente disponibles bajo alta carga: el exceso de overcommit de CPU provoca retrasos en RDP.

¿Se puede activar Windows Server 2022 con una clave de Internet?

No, no se pueden utilizar claves aleatorias, servidores KMS públicos, activadores ni scripts de omisión. Además de infringir la licencia, estas herramientas suelen contener código malicioso y hacen que el servidor sea inseguro. Utilice únicamente la clave y el canal de activación sobre los que tenga derechos legales: MAK/KMS corporativo, suscripción, licencia del proveedor de servicios u otra opción confirmada. El estado se comprueba mediante los comandos slmgr /dli y slmgr /xpr.

¿Es necesario abrir el puerto 3389 a Internet para RDP?

No. La opción preferible es WireGuard VPN, tras lo cual RDP queda disponible solo desde la subred VPN. Para un único administrador, es adecuado un túnel SSH desde el host Linux hacia la IP privada de la VM Windows. Abrir directamente el puerto 3389 aumenta el riesgo de ataques de fuerza bruta, explotación de vulnerabilidades y escaneo constante. Si el acceso directo es inevitable, limite los orígenes por IP, utilice NLA, contraseñas complejas, MFA mediante una puerta de enlace adecuada e instale actualizaciones regularmente.

Conclusiones y próximos pasos

Ahora Windows Server 2022 funciona en el host Linux dentro de KVM con UEFI, disco virtio, red virtio, RDP protegido y un modelo de licenciamiento controlado. Esta configuración es adecuada para una pequeña infraestructura Windows de producción y proporciona control total sobre la VM, la red y las copias de seguridad.

1. Configure WireGuard y cierre por completo el acceso directo a RDP desde Internet.
2. Verifique la restauración de una copia de seguridad de restic en una VM de prueba aislada antes de que aparezcan datos críticos.
3. A medida que crezca la carga, traslade los discos a NVMe RAID, añada monitorización de CPU, RAM, IOPS y latencias de RDP, y luego considere un servidor dedicated o VM independientes para los roles de AD, SQL y aplicaciones.