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 і застосунків.