Windows Server 2022 в KVM: virtio-драйверы, RDP и лицензия

Что мы настраиваем и зачем

Задача — развернуть Windows Server 2022 в виртуальной машине KVM/QEMU на собственном VPS или dedicated-сервере с Linux. Такой сценарий используют для запуска Windows-приложений, Active Directory для небольшой инфраструктуры, бухгалтерского ПО, RDS-хоста, тестовых стендов, CI-агентов, игровых серверов и удалённых рабочих столов.

KVM — гипервизор, встроенный в ядро Linux. В сочетании с QEMU он позволяет запускать Windows почти с нативной производительностью, если процессор поддерживает аппаратную виртуализацию Intel VT-x или AMD-V. Libvirt добавляет удобное управление виртуальными машинами через команды virsh, XML-конфигурации и сетевые профили.

В результате у вас будет Linux-хост с одной Windows Server 2022 VM, которая:

• загружается в режиме UEFI с виртуальным диском QCOW2 или RAW;
• использует virtio-драйверы для диска, сети, памяти и balloon-устройства;
• получает отдельный IP-адрес либо работает за NAT;
• доступна по RDP с включённым Network Level Authentication;
• защищена правилами firewall и журналированием входов;
• может резервироваться на внешний сервер или S3-совместимое хранилище.

Почему virtio важно

Без virtio Windows может работать с эмулируемыми устройствами: IDE/SATA-диском и адаптером Intel e1000. Это удобно для первой загрузки, но создаёт лишнюю нагрузку на CPU хоста и ограничивает скорость ввода-вывода. Virtio — паравиртуализированный интерфейс между гостевой системой и KVM. Он уменьшает накладные расходы и обычно обеспечивает существенно более высокую производительность диска и сети.

Для Windows Server 2022 в типовой конфигурации нужны следующие драйверы: viostor или vioscsi для системного диска, NetKVM для сети, Balloon для управления памятью, viorng для генератора случайных чисел и QEMU Guest Agent для корректного получения IP, выключения VM и работы с оркестрацией.

Self-hosted KVM и managed cloud: что выбрать

Self-hosted KVM оправдан, когда требуется полный контроль, нестандартная сетевая схема, несколько Windows VM, доступ к собственным ISO, изолированные лаборатории или независимые бэкапы. Если нужна одна краткосрочная Windows-машина без администрирования гипервизора, managed cloud обычно проще.

Что не входит в этот сценарий

Этот гайд рассчитан на сервер с доступом к KVM. Обычный VPS, работающий внутри чужой виртуальной машины, не всегда может запускать вложенную виртуализацию. Перед началом проверьте, что провайдер явно поддерживает nested virtualization либо выдаёт физический сервер. Если доступа к /dev/kvm нет, QEMU перейдёт в программную эмуляцию, а Windows Server будет работать крайне медленно.

Какой VPS-конфиг нужен под эту задачу

Ресурсы нужно считать не только для Windows Server 2022, но и для Linux-хоста, кеша файловой системы, QEMU и резерва на пики нагрузки. Не выделяйте гостю всю оперативную память и все vCPU: хосту нужны ресурсы для ядра, libvirt, дисковой подсистемы, бэкапов и мониторинга.

Минимально практичная конфигурация для одной Windows Server 2022 VM — 4 выделенных vCPU, 8 ГБ RAM, 100 ГБ NVMe и порт от 100 Мбит/с. Для комфортной удалённой работы лучше 16 ГБ RAM на хосте: 8–10 ГБ выделяется Windows, остальное остаётся Linux и дисковому кешу.

В качестве базового варианта можно взять VPS с указанными характеристиками, но перед заказом обязательно уточните наличие nested virtualization и доступность /dev/kvm. Если это не гарантируется, выбирайте dedicated-сервер.

Когда VPS недостаточно

Dedicated-сервер нужен, когда планируются несколько Windows VM, высокая нагрузка на SQL Server, сборочные агенты, RDS для многих пользователей, тяжёлые приложения CAD/ERP или интенсивный дисковый ввод-вывод. Он также предпочтителен, если требуется предсказуемая производительность CPU и IOPS, VLAN, несколько публичных IP или отсутствие ограничений nested virtualization.

Для Windows Server с графической нагрузкой KVM без GPU passthrough не заменяет полноценную рабочую станцию. Обычный RDP подходит для администрирования, офисных задач и серверных приложений, но не для 3D-визуализации, современного рендеринга или GPU-вычислений.

Как выбрать локацию

Локация влияет на задержку RDP, требования к хранению данных и скорость восстановления из резервной копии. Для интерактивной работы старайтесь держать RTT до сервера ниже 50–70 мс. Для удалённого офиса выбирайте регион рядом с пользователями. Если Windows VM обрабатывает персональные данные, заранее проверьте юридические требования к стране размещения и трансграничной передаче данных.

Проверка поддержки виртуализации

После выдачи Linux-сервера выполните следующие команды. Ненулевое значение в первой команде и наличие /dev/kvm означают, что KVM можно использовать.

# Проверяем флаги аппаратной виртуализации процессора.
egrep -c '(vmx|svm)' /proc/cpuinfo

# Проверяем, доступно ли устройство KVM ядра Linux.
ls -l /dev/kvm

# Проверяем, не включена ли виртуализация только в программном режиме.
sudo apt update
sudo apt install -y cpu-checker
kvm-ok

Ожидаемый результат kvm-ok: KVM acceleration can be used. Если вывод говорит, что ускорение недоступно, не продолжайте установку до решения вопроса с платформой: эмуляция TCG не подходит для постоянной эксплуатации Windows Server.

Подготовка сервера

В качестве хоста далее используется Ubuntu Server 24.04 LTS с актуальными обновлениями 2026 года. Подход сохраняется для Debian 12/13 и других Linux-дистрибутивов, но названия пакетов могут отличаться. Все действия выполняйте под отдельным пользователем с правами sudo, а не под постоянной root-сессией.

Создание администратора и SSH-ключей

Сначала создайте пользователя для администрирования KVM. Если сервер уже выдан с обычным пользователем, этот шаг можно адаптировать. Публичный SSH-ключ необходимо добавить до отключения парольного входа.

# Создаём отдельного пользователя для администрирования хоста.
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

Откройте вторую SSH-сессию и проверьте вход под пользователем admin по ключу. Только после успешной проверки меняйте настройки SSH. Не закрывайте текущую root-сессию, пока не убедитесь, что новый вход работает.

# Создаём отдельный файл с безопасными настройками 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

Обновления и базовые инструменты

Перед установкой KVM обновите систему. Перезагрузка обязательна, если обновились ядро, микрокод CPU или критические библиотеки виртуализации. Планируйте это окно до размещения рабочих данных в Windows VM.

# Обновляем пакеты 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 и защита от перебора паролей

На хосте не нужно открывать RDP-порт 3389, если Windows VM использует NAT и RDP доступен через VPN. При прямом публичном IP для гостя firewall должен быть настроен отдельно и на Linux-хосте, и в Windows Defender Firewall. Ниже оставлен SSH только с вашего административного IP. Замените пример адреса на свой.

# Устанавливаем 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

Если у вас динамический IP, не ограничивайте SSH одним адресом до настройки VPN или консольного доступа через панель провайдера. Альтернативой может быть разрешение SSH из отдельной VPN-подсети. Не открывайте 3389/tcp всему интернету «на время теста»: такие узлы быстро находят сканеры и боты.

Структура каталогов

Храните ISO, диски виртуальных машин, XML-экспорт и бэкапы раздельно. Это упрощает контроль прав, очистку старых ISO и перенос VM. В примере виртуальные диски остаются в стандартном каталоге libvirt, а исходные образы хранятся в /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

Установка ПО — пошагово

На Ubuntu 24.04 LTS пакеты QEMU, libvirt и OVMF поставляются из официального репозитория Ubuntu. В 2026 году не требуется подключать сторонние PPA для базового запуска Windows Server 2022. Используйте стандартные пакеты: они получают обновления безопасности через обычный механизм apt.

Установка KVM, QEMU и 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

После добавления в группы выйдите из SSH-сессии и войдите заново. Проверить группы можно командой id. Для серверного сценария графический менеджер virt-manager на хост ставить не нужно: достаточно virsh и virt-install.

Загрузка ISO Windows Server и virtio

Скачайте оценочный ISO Windows Server 2022 Datacenter или Standard только из официального центра загрузок Microsoft. Для постоянной эксплуатации используйте образ, соответствующий вашей модели лицензирования. ISO virtio-win берите из официального проекта Fedora virtio-win; в 2026 году выбирайте свежую стабильную версию, совместимую с 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

Перед установкой сверяйте SHA-256 Windows ISO со значением, опубликованным источником загрузки. Проверять контрольную сумму virtio-win также полезно, особенно если сервер находится в среде с повышенными требованиями к безопасности.

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

Создание виртуального диска

QCOW2 поддерживает snapshots и тонкое выделение пространства: файл растёт по мере записи данных. RAW обычно быстрее и проще для внешних систем хранения, но сразу резервирует весь объём. Для одной Windows VM на локальном NVMe удобно начать с QCOW2. Не включайте бессмысленные snapshots на месяцы: они ухудшают производительность и усложняют восстановление.

# Создаём 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

Первый запуск установщика Windows

Команда ниже создаёт VM с UEFI, 4 vCPU, 8 ГБ RAM, SCSI-контроллером virtio и виртуальным сетевым адаптером virtio. Диск будет невидим Windows до загрузки драйвера vioscsi или viostor из второго ISO. Для сервера рекомендуется virtio-scsi, так как он лучше подходит для нескольких дисков, trim и очередей ввода-вывода.

# Создаём и запускаем 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

Параметр --graphics vnc,listen=127.0.0.1 не публикует VNC в интернет. Для доступа к установщику создайте SSH-туннель со своего компьютера, затем подключитесь VNC-клиентом к localhost:5900. Номер порта уточняйте через 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

Если vncdisplay вернул :1, используйте порт 5901, а не 5900. В VNC-клиенте указывайте адрес 127.0.0.1:5901. После настройки RDP VNC можно оставить как аварийную консоль, но доступ к нему должен остаться только через SSH-туннель.

Установка virtio-драйвера диска

В интерфейсе установки Windows выберите редакцию, примите условия лицензии и на экране выбора диска нажмите Load driver. Откройте второй CD-ROM с virtio-win ISO. Для конфигурации из этого гайда загрузите драйвер из каталога vioscsi\2k22\amd64. После загрузки драйвера появится виртуальный диск на 120 ГБ.

1. Нажмите Load driver.
2. Выберите устройство с virtio-win ISO.
3. Откройте vioscsi, затем 2k22 и amd64.
4. Подтвердите установку драйвера Red Hat VirtIO SCSI.
5. Выберите появившийся диск, создайте разделы автоматически и продолжите установку.

Если вы выбрали шину virtio вместо scsi, нужен драйвер viostor\2k22\amd64. Не загружайте случайные драйверы для другой версии Windows: установщик может принять их, но система получит нестабильную конфигурацию.

Установка полного набора драйверов в Windows

После первого входа в Windows откройте второй CD-ROM и запустите virtio-win-guest-tools.exe. Этот установщик добавит сетевой драйвер, Balloon, QEMU Guest Agent, RNG и остальные компоненты. Выполняйте установку от имени локального администратора и перезагрузите 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

Для проверки драйверов в Windows откройте Device Manager. В списке не должно быть устройств с жёлтым значком. В разделе сетевых адаптеров должен отображаться Red Hat VirtIO Ethernet Adapter, а в системных устройствах — VirtIO Balloon Driver и VirtIO RNG Device.

Конфигурация

После установки Windows настройте сеть, RDP, обновления, учётные записи и лицензирование. Главный принцип: не выставляйте удалённый рабочий стол напрямую в интернет без ограничений. Самый безопасный вариант — доступ к RDP через WireGuard или корпоративный VPN. Если VPN пока нет, ограничьте порт 3389 конкретными внешними IP на Windows Firewall и сетевом firewall.

Сетевая схема: NAT или отдельный публичный IP

По умолчанию libvirt использует NAT-сеть default, обычно с подсетью 192.168.122.0/24. Windows получает приватный IP и выходит в интернет через Linux-хост. Это хороший стартовый вариант: гостевая система не видна извне, а администрирование можно выполнять через VPN или 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

Замените 192.168.122.100 на фактический IP Windows. Для доступа с рабочего компьютера можно сделать SSH-туннель через Linux-хост. Это не требует открытия 3389 в публичной сети.

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

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

Для постоянного доступа нескольких сотрудников лучше использовать WireGuard. RDP в этом случае разрешается только из VPN-подсети, например 10.66.0.0/24. Публикация NAT-проброса SERVER_IP:3389 допустима только при строгом IP allowlist и дополнительной защите, но VPN остаётся предпочтительным вариантом.

Включение RDP через PowerShell

Откройте PowerShell от имени администратора в консоли Windows или через VNC и выполните команды ниже. Они включают Remote Desktop, активируют правило Windows Firewall, требуют Network Level Authentication и разрешают подключения только членам группы 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

Создайте отдельную учётную запись для RDP вместо постоянного входа встроенным Administrator. Используйте длинный уникальный пароль или доменную учётную запись, если VM позже станет частью Active Directory. Встроенного локального администратора лучше переименовать и использовать только для аварийного доступа через 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'

Ограничение RDP по IP

Если RDP доступен напрямую через проброс порта или отдельный IP, ограничьте источник на стороне Windows. Ниже пример правила, разрешающего RDP только с одного офиса и одной VPN-подсети. После добавления убедитесь, что ваше текущее соединение не будет заблокировано.

# Создаём более строгое 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' }

Команда с отключением встроенной группы может отключить RDP, если новое правило задано с ошибкой. Выполняйте её только из VNC-консоли или имея второй канал доступа. В среде с VPN лучше разрешить только VPN-подсеть и не добавлять домашние динамические IP.

Лицензия и активация Windows Server 2022

Windows Server 2022 нельзя легально использовать на постоянной основе без корректных прав на виртуализацию. KVM технически не проверяет лицензию, но ответственность за соблюдение условий несёт владелец установки. Не используйте публичные KMS-активаторы, пиратские ключи и сторонние скрипты: они нарушают лицензионные условия и часто содержат вредоносный код.

На практике встречаются следующие модели:

• Retail/FPP. Обычно подходит для одной инсталляции, но условия переноса и виртуализации нужно сверять с конкретной редакцией и договором.
• OEM. Часто привязана к первоначальному оборудованию и обычно не подходит для переноса на арендованный сервер.
• Volume Licensing. Корпоративные MAK или KMS-ключи с правами, определяемыми соглашением организации.
• SPLA/CSP-hosted. Лицензирование через поставщика услуг, часто применяемое для арендной инфраструктуры.
• Evaluation. Временная оценочная редакция для тестирования; её нельзя рассматривать как постоянную лицензию.

Windows Server Standard обычно даёт права на ограниченное число виртуальных экземпляров при лицензировании всех физических ядер сервера по правилам Microsoft. Datacenter рассчитан на плотную виртуализацию. На арендованном dedicated или VPS лицензирование особенно чувствительно: права BYOL, mobility и аренды зависят от договора и типа инфраструктуры. Если есть сомнения, запросите письменное подтверждение у лицензирующего партнёра или юриста по корпоративному ПО.

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

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

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

Команда slmgr /xpr покажет, активирована ли система постоянно, временно или находится в оценочном периоде. Для Volume Licensing используйте только корпоративный ключ и утверждённый вашей организацией способ активации. Не записывайте ключ в XML VM, shell history, публичный Git-репозиторий или скрипт резервного копирования.

Настройка обновлений и гостевого агента

В Windows Server 2022 включите автоматические обновления через Windows Update или централизованную систему управления обновлениями. Для одиночной VM оптимален ежемесячный maintenance window: обновление, перезагрузка, проверка RDP и состояния сервисов. Не отключайте обновления ради «стабильности»: RDP и службы Windows регулярно получают критические исправления.

# Проверяем, что 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 через Caddy или certbot в этом сценарии не нужен: RDP использует собственное шифрование TLS, а веб-сервис на Linux-хосте не разворачивается. Не пытайтесь проксировать RDP через обычный HTTP reverse proxy. Если нужен браузерный удалённый доступ, разворачивайте отдельный шлюз вроде Apache Guacamole за HTTPS, но это отдельная архитектура с дополнительными требованиями к аутентификации и безопасности.

Проверка работоспособности

Проверка должна подтвердить работу всех уровней: KVM-хоста, VM, сети, RDP и лицензии. Выполните команды на Linux-хосте и в Windows. После каждой перезагрузки Windows проверьте, что машина автоматически возвращается в рабочее состояние.

# Проверяем автозапуск 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

Для RDP-подключения используйте современный клиент: Microsoft Remote Desktop, mstsc.exe, FreeRDP или Remmina. Подключайтесь через SSH-туннель либо VPN. При первом подключении проверьте отпечаток сертификата RDP и не игнорируйте предупреждение о внезапной смене сертификата на уже известном сервере.

Бэкапы и обслуживание

Snapshot не является резервной копией. Snapshot находится на том же сервере и не защищает от удаления VM, сбоя SSD, компрометации хоста или ошибки администратора. Для Windows Server в KVM используйте правило 3-2-1: минимум три копии данных, на двух типах носителей, одна копия вне основного сервера.

Что нужно сохранять

• виртуальный диск ws2022.qcow2 или RAW-образ;
• XML-конфигурацию VM из virsh dumpxml;
• параметры сети libvirt, если использованы собственные bridge/VLAN;
• Windows System State для Active Directory, сертификатов и системных ролей;
• прикладные базы данных, выгруженные средствами самих СУБД;
• ключи BitLocker и сведения о лицензировании, хранящиеся в защищённом менеджере секретов;
• документацию: IP-адреса, VLAN, правила firewall, процедуру восстановления.

Для консистентной копии работающей VM используйте QEMU Guest Agent и внешние snapshots либо планируйте короткое окно выключения. Самый простой и надёжный вариант для небольшой Windows VM — штатно выключить гостя, скопировать образ, затем запустить VM. Это создаёт несколько минут простоя, но делает копию предсказуемой.

Резервное копирование с restic

Restic шифрует резервные копии на стороне клиента и поддерживает S3-совместимые хранилища, SFTP и отдельные серверы. Не храните пароль репозитория внутри скрипта или домашнего каталога пользователя без ограниченных прав. В примере секреты находятся в файле, доступном только 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'

Замените значения в файле окружения до запуска restic init. В production лучше передавать секреты через защищённое хранилище, systemd credentials или секреты CI/CD. Пароль репозитория храните отдельно от самого S3-бакета: без него зашифрованный бэкап восстановить нельзя.

# Создаём скрипт: выключает 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'

Проверка восстановления

Бэкап считается рабочим только после тестового восстановления. Раз в квартал восстановите копию на отдельный тестовый диск, импортируйте XML с новым именем VM, запустите её в изолированной сети и убедитесь, что Windows загружается. Не включайте восстановленную копию одновременно с оригинальным контроллером домена в одной сети: это может вызвать конфликт AD и 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

Обновления и maintenance window

Для одной VM используйте maintenance window раз в месяц: обновите Linux-хост, сделайте бэкап, обновите Windows, перезагрузите VM и проверьте RDP. Rolling-обновления применимы только при нескольких репликах приложения или кластере; одиночную Windows VM нельзя обновить без потенциального простоя.

Перед обновлением virtio-win сделайте snapshot или полноценный бэкап. Новые драйверы обычно совместимы, но сетевой драйвер или драйвер диска — критические компоненты. Держите VNC-консоль доступной через SSH-туннель, чтобы восстановить сеть Windows, если после обновления NetKVM изменится интерфейс или профиль firewall.

Troubleshooting + FAQ

Почему Windows Server 2022 не видит диск в установщике?

Чаще всего не загружен драйвер virtio для правильного типа контроллера. Если VM создана с virtio-scsi, в окне Load driver нужен путь vioscsi\2k22\amd64. Для обычной virtio-шины нужен viostor\2k22\amd64. Также проверьте, что virtio-win ISO подключён как второй CD-ROM и файл ISO не повреждён. Не меняйте тип контроллера после установки Windows без заранее установленного нужного драйвера.

Ошибка: KVM acceleration can not be used. Что делать?

Проверьте наличие /dev/kvm, флаги vmx или svm в /proc/cpuinfo и вывод kvm-ok. На VPS причина обычно в том, что провайдер не включил nested virtualization. Внутри гостевой VM нельзя самостоятельно включить VT-x или AMD-V. Запросите поддержку nested KVM либо перенесите Linux-хост на dedicated-сервер. Не запускайте рабочий Windows Server через программную эмуляцию QEMU: производительность будет непригодной.

Какой VPS-конфиг минимально подойдёт?

Для одной лёгкой Windows Server 2022 VM, используемой одним-двумя администраторами по RDP, минимально практичны 4 vCPU, 8 ГБ RAM и 100 ГБ NVMe. Windows можно выделить 2 vCPU и 4–6 ГБ RAM, оставив запас Linux-хосту. Обязательное условие важнее цифр: VPS должен предоставлять доступ к KVM или официально поддерживать nested virtualization. Для постоянной работы лучше 16 ГБ RAM на хосте.

RDP включён, но подключение не устанавливается. Что проверить?

Проверьте службу TermService в Windows, правило Windows Defender Firewall и доступность TCP-порта командой Test-NetConnection или nc -vz с Linux-хоста. Если VM использует NAT, убедитесь, что вы подключаетесь через SSH-туннель, VPN или корректный проброс порта. Также проверьте IP гостя через virsh domifaddr ws2022 --source agent. После обновления NetKVM Windows иногда меняет профиль сети, из-за чего firewall применяет более строгие правила.

Что выбрать — VPS или dedicated для этой задачи?

VPS подходит для одной небольшой Windows VM, тестовой среды или нескольких лёгких пользователей RDP при гарантированной nested virtualization. Dedicated лучше для нескольких VM, SQL Server, Active Directory с критичными ролями, тяжёлого дискового ввода-вывода, RDS для команды и требований к гарантированным ресурсам. Dedicated также проще лицензировать в некоторых корпоративных сценариях, поскольку известны физические характеристики хоста. Окончательное решение зависит от лицензии, нагрузки и требований к изоляции.

Windows работает медленно, хотя vCPU и RAM достаточно. В чём причина?

Проверьте, использует ли VM virtio-диск и NetKVM, а не эмулируемые SATA/e1000-устройства. На хосте выполните iostat, htop и проверьте свободное место: переполненный QCOW2-диск и медленное сетевое хранилище заметно ухудшают отклик. Не делайте долгоживущие snapshots QCOW2. Также убедитесь, что VM не получает больше vCPU, чем физически доступно при высокой нагрузке: excessive CPU overcommit вызывает задержки RDP.

Можно ли активировать Windows Server 2022 ключом из интернета?

Нет, использовать случайные ключи, публичные KMS-серверы, активаторы и обходные скрипты нельзя. Помимо нарушения лицензии, такие инструменты часто содержат вредоносный код и делают сервер небезопасным. Используйте только ключ и канал активации, на которые у вас есть законные права: корпоративный MAK/KMS, подписку, лицензию поставщика услуг или другой подтверждённый вариант. Статус проверяется командами slmgr /dli и slmgr /xpr.

Нужно ли открывать порт 3389 в интернет для RDP?

Нет. Предпочтительный вариант — WireGuard VPN, после которого RDP доступен только из VPN-подсети. Для единственного администратора подойдёт SSH-туннель с Linux-хоста на приватный IP Windows VM. Прямое открытие 3389 увеличивает риск перебора паролей, эксплуатации уязвимостей и постоянного сканирования. Если прямой доступ неизбежен, ограничьте источники по IP, используйте NLA, сложные пароли, MFA через подходящий шлюз и регулярно устанавливайте обновления.

Выводы и следующие шаги

Теперь на Linux-хосте работает Windows Server 2022 в KVM с UEFI, virtio-диском, virtio-сетью, защищённым RDP и контролируемой моделью лицензирования. Такая конфигурация подходит для небольшой рабочей Windows-инфраструктуры и даёт полный контроль над VM, сетью и резервными копиями.

1. Настройте WireGuard и полностью закройте прямой доступ к RDP из интернета.
2. Проверьте восстановление restic-бэкапа на изолированной тестовой VM до появления критичных данных.
3. При росте нагрузки перенесите диски на NVMe RAID, добавьте мониторинг CPU, RAM, IOPS и задержек RDP, затем рассмотрите dedicated-сервер или отдельные VM для ролей AD, SQL и приложений.