Windows 2003 под KVM на Ubuntu Server

32-разрядная редакция Windows Server 2003 R2 — хороший вариант Windows сервера для запуска в виртуальной машине под KVM

Система сама по себе занимает мало памяти и стабильно работает.

Приступим к установке!

Содержание

Подготовка к установке Windows 2003 Server под KVM

Самым оптимальным вариантом с точки зрения скорости работы будет выделить раздел жесткого диска KVM сервера в качестве диска виртуальной машины, а также использовать Virtio драйвера для сети и диска.

Если на сервере будет запущено несколько виртуальных машин, удобно добавить дисковый раздел в группу томов LVM, чтобы иметь возможность выделить для каждой виртуалки столько места, сколько ей нужно, не меняя каждый раз таблицу разделов.

Создание диска LVM

Создание виртуальной машины

Первый запуск и virtio драйвера

#!/bin/sh
VM_ID="10"

MACBASE="00:16:3e:ff:ff"

HDA="vm_${VM_ID}.img"
HDB="temp.img"
HDC="w2k3_r2_ent_rus_x86/ru_win_srv_2003_r2_enterprise_with_sp2_vl_cd1_X13-46484.iso"
HDD="virtio-win-0.1-52.iso"

sudo kvm \
-enable-kvm \
-boot "menu=on,order=d" \
-m 1024M \
-balloon virtio \
-name "kvm_${VM_ID}" \
-drive "file=$HDA,index=0,media=disk,cache=writeback" \
-drive "file=$HDB,index=1,media=disk,cache=writeback,if=virtio" \
-drive "file=$HDC,index=2,media=cdrom,cache=writeback,readonly" \
-drive "file=$HDD,index=3,media=cdrom,cache=writeback,readonly" \
-net "nic,model=virtio,macaddr=${MACBASE}:${VM_ID}" \
-net "tap,ifname=tap${VM_ID},script=no,downscript=no" \
-vnc "0.0.0.0:${VM_ID}"

Параметр «-vnc …» имеет смысл только на сервере без GUI. По умолчанию KVM откроет окно через SDL. В обоих случаях Ctrl+Alt+Shift+1 и Ctrl+Alt+Shift+2 служат для переключения внутри окна между гостевой и управляющей консолью.

Параметр «-net nic,model=virtio,...» создаст внутри ВМ сетевую карту неизвестного Windows типа, для которого мастер настройки оборудования предложит выбрать драйвер. Парный ему параметр «-net tap,...» создаст в хост-ОС сетевой интерфейс для связи с ВМ. Назначение IP-адресов, настройка DHCP и выхода во внешний мир через ProxyARP, NAT или Bridge не имеют прямого отношения к Windows, поэтому здесь не рассматриваются.

Теперь про самое важное на данном этапе, т.е. про диски.

HDC — это ISO-образ с дистрибутивом Windows. Имя файла взято из торрента в предыдущем разделе. С него внутри ВМ произойдет первая загрузка системы («-boot order=d«).

HDD — это ISO-образ с драйверами virtio. Скачивается с alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

HDA — это пустой образ диска, на который будет устанавливаться система. Создан командой «kvm-img create -f qcow2 vm_10.img 50G«.

HDB — это пустой образ диска, созданный через «kvm-img create -f qcow2 temp.img 1G» с единственной целью — показать Windows устройство незнакомого типа, чтобы она затребовала драйвер для него. Установка в систему драйвера virtio для временного диска позволит переключить затем с IDE на virtio системный диск.

После того, как установка системы и драйверов будет полностью завершена, в команде запуска следует убрать «-boot» и все строки «-drive», кроме первой, т.к. временный диск и ISO-образы станут не нужны (обратите внимание на добавленный «if=virtio«!):

kvm ...  -drive "file=$HDA,index=0,media=disk,cache=writeback,if=virtio" ...

Memory Ballooning

Традиционный подход — сразу при запуске виртуальной машины (ВМ) выделять ей блок ОЗУ заданного размера, например, 512 мегабайт. Его недостаток — в те моменты, когда в памяти ВМ есть неиспользуемое пространство, в других ВМ и хост-системе её может не хватать.

Memory ballooning — это механизм динамического (а) выделения хост-ОЗУ для ВМ по мере необходимости и (б) возвращения неиспользуемых блоков по мере освобождения. Благодаря ему становится возможным одновременно запускать множество ВМ, суммарный объём виртуального ОЗУ в которых больше объёма физического ОЗУ в хост-системе, при условии, что они не станут использовать максимально разрешённый объём все сразу. Благодаря этому память хост-системы распределяется между ВМ так же гибко, как между обычными процессами.

Создание виртуальных ресурсов, превышающих физические по объёму, обозначается любимыми для многих хостеров терминами «overcommit» и «overselling».

Для работы баллонинга требуется согласованная работа двух программных компонентов:

MOM (memory overcommitment manager) в хост-системе, меняющего объём ОЗУ для ВМ на основании запросов из неё,
VMM (менеджера виртуальной памяти) в гостевой ОС, взаимодействующего с MOM через виртуальный PCI-контроллер.

MOM в последних версиях KVM включается автоматически, старые требовали включать его с помощью «kvm… -balloon virtio» в командной строке.

Гостевое устройство для связи с MOM диспетчер оборудования (devmgmt.msc) Windows увидит как «PCI standard RAM controller» неизвестного типа. В отличие от virt-stor и virt-net, драйвер к нему не будет предложено установить автоматически. Вместо этого, следует зайти в свойства устройства, на вкладке «Драйвер» выбрать обновление и вручную указать путь к balloon.inf на VirtIO CD (пруф). После этого устройство переименуется в «VirtIO Balloon Driver».

ACPI выключение виртуальной машины Windows

По умолчанию Windows 2003 разрешает выключать себя единственным способом — ввести логин-пароль, выбрать Пуск => «Завершение работы», ввести примечание, нажать «OK». Разумеется, на VDS-ферме такой подход неприемлем. KVM (и QEMU) умеет эмулировать ACPI. Команда «system_powerdown» аналогична нажатию кнопки питания на физическом компьютере, но Windows её проигнорирует. Лечится следующим REG-файлом:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system]
"ShutdownWithoutLogon"=dword:00000001
"DisableCAD"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
"ShutdownWarningDialogTimeout"=dword:00000003

Кэширование

Если образ гостевого диска хранится на VDS-ферме в виде файла, кэширование гостевых файлов может оказаться двойным — сначала их кэширует гостевая ОС при обращениях к виртуальному диску, затем ОС фермы при обращениях к физическому.

Всего возможны 3 основных режима:

none — хост-система не кэширует файл-образ ни на чтение, ни на запись
writeback — запись выполняется немедленно, чтение кэшируется
writethrough — чтение и запись кэшируются

В разных версиях qemu/kvm и в разных ОС по умолчанию могут использоваться разные режимы. Например, Qemu до версии 1.2 использует writethrough, 1.2 перешёл на writeback, в Proxmox выбран cache=none.

Все без исключения источники в Сети советуют не использовать writethrough как наиболее медленный. По субъективной оценке, для ВМ с Windows оптимален writeback, для ВМ с Linux и FreeBSD — none.

Зависания сети

Единственной серьёзной проблемой, которую однозначно вызывает ошибка в KVM, являются подвисания гостевой сети при интенсивном трафике.

Рекомендации, предлагаемые участниками обсуждений (обновление qemu-kvm и ядра, изменение параметров командной строки, использование vhost-net), к сожалению, пока не сумели её решить.

При каждом подвисании приходится заходить на консоль ВМ по VNC и выполнять сброс сетевого интерфейса, после чего трафик снова начинает ходить нормально.

Автоматизировать данное действие в Windows можно с помощью AutoIt, если создать файл PingFailed_ResetNic.au3 и вызывать его Диспетчером заданий каждые несколько минут:

#include «EventLog.au3»

Local $PingHost = "192.168.0.1"
Local $Interface = "LAN"

Ping($PingHost, 250)
If @error = 0 Then Exit

Local $hEventLog = _EventLog__Open("", "RestartNicOnPingFailure")
Local $aEmpty[1] = [0]
_EventLog__Report($hEventLog, 2, 0, 1, "", "Restart NIC " & Interface & " on failed ping to " & PingHost, $aEmpty)
_EventLog__Close($hEventLog)

RunWait("netsh interface set interface " & $Interface & " DISABLED", "", @SW_HIDE)
RunWait("netsh interface set interface " & $Interface &  " ENABLED", "", @SW_HIDE)

Вариант для CMD.EXE: rickosborne.org/blog/2007/02/stupid-windows-tricks-restart-network-adapter-when-it-hangs/