В данной статье я опишу свой опыт миграции домашнего сервера на гипервизоре Hyper-V, установленного на Windows Server 2012 R2, на гипервизор Xen Project 4.14, установленного на Debian 11. Я ни в коем случае не являюсь экспертом в Linux, всю свою карьеру в основном использовал операционные системы Microsoft, но времена и технологии меняются, и нужно соответствовать.

Зачем мне нужен домашний сервер? Для меня — это во многом песочница, где я могу исследовать и пробовать технологии, которые не могу потестировать на десктопе. Помимо этого, конечно, он несёт и утилитарные функции: контроллер домена, файловый сервер, хостинг для сайта моей жены, TFS-сервер (да, до сих пор, но собираюсь поменять на GitLab) и др. Всё это разложено по виртуалкам для более эффективного управления и использования ресурсов. Разворачивал я Hyper-V версию лет 7 назад, с тех пор существенных изменений не производил, однако, какое-то время назад, решил мигрировать его на Linux. Наконец-то у меня дошли руки до этого. В этой статье собран мой опыт «не совсем новичка» в Linux (ранее опыт ограничивался в основном использованием Ubuntu в WSL) и платформах виртуализации (Hyper-V, VMWare).

Во-первых, я хочу перенести то, что есть: несколько Windows-виртуалок. Во-вторых, перенести хостинг сайта с IIS в Kubernetes (да, это overkill, но Куб я нежно люблю и хочу иметь платформу для экспериментов), заменить старую реализацию сайта на уже написанную новую (Angular + ASP.NET Core + .NET Core). В-третьих, заменить TFS на GitLab. В этой статье изложу только непосредственно установку и настройку Xen и миграцию старых виртуалок, с описанием проблем, с которыми столкнулся в процессе, и тем, как я их решил. Знатоки Linux, не кидайте в меня помидорами, если я что-то, по вашему мнению, сделал не правильно, не эффективно или совсем «не так». Делайте скидку на то, что я делал это впервые. Лучше напишите свои советы в комментариях. Для меня всё, описанное в данной статье, — прежде всего, мой практический опыт, без которого любая теория — ничто. Для новичков, думаю, подробность повествования даст хорошее понимание принципов работы с Linux.

Конфигурация сети

В составе моей сети следующие компоненты:

1. Домашний роутер, предоставляющий сервисы NAT, firewall, DHCP, DNS.

2. Сервер с гипервизором и 4 виртуалками на нём, а также виртуальный роутер Hyper-V для этих виртуалок.

3. VLAN 44 для «внутренних» серверов, недоступных извне, и десктопов.

4. VLAN 55 для машины в DMZ, на которой расположен web-сервер.

5. Несколько десктопов.

Подготовка Windows-сервера и виртуалок

Прежде всего, я удалил весь лишний софт с хоста виртуализации и самих виртуалок, чтобы «облегчить» их и не тащить лишнего, избавился от ненужных виртуалок, которые уже давно не запускал. Проверил и исправил проблемы с файловой системой, вызванных сбоями работы UPS, почистил от лишних файлов (использовал Wise Disk Cleaner, бесплатный и без лишних возможностей «растолстевшего» за годы CCleaner), накопившихся за эти годы. Встроенная в Windows программа Clean Disk оставляет массу «хвостов», к тому же, с некоторых пор, она перестала или, по крайней мере, она так считает, перестала чистить Windows Update files. Какие бы «приседания» я не делал, ничто не помогало. После этого тем же Wise Disk Cleaner, я дефрагментировал виртуальные диски так, чтобы незанятое место на дисках осталось в конце разделов, после чего в оснастке Disk Manager, уменьшил разделы виртуальных дисков до минимума.

После того, как с «чистками» и оптимизациями было покончено, выгрузил виртуалки (Export в локальном меню виртуалки в оснастке Hyper-V) и сконвертировал их в формат vmdk с помощью StarWind V2V Converter. Однако, как в последствии оказалось, это было лишним.

Установка Xen Project

Разумеется, я не хотел «сносить» Windows до тех пор, пока не удостоверюсь, что мой новый сервер на основе Debian и Xen со всеми старыми виртуалками работают, как надо. Поэтому «поджал» место на физических дисках и установил Debian side-by-side с Windows, благо это не так трудно.

Подготовка загрузочной флешки с Debian

Использовал инструкцию Install Debian Linux by creating Flash Drive on Windows. Использовал образ Debian 11.3.0.

Если кратко, всё очень просто: качаем ISO-образ Debian и заливаем его на флешку с помощью Rufus.

Установка Debian

Использовал инструкцию Xen Project Beginners Guide. Правда, оказалось, что она несколько устаревшая, что можно понять по рекомендации использовать для раздела /boot ext2, а для раздела / — ext3. Текущими рекомендациями является использование ext4 без журналирования для /boot и ext4 с журналированием для /.

Размер /boot выбрал 512МБ. Как я понял, должно хватить с запасом. Как отключить журналирование ext4 в инсталляторе, я так и не понял, пришлось его оставить.

Тема /swap весьма холиварная, решил остановиться на 8ГБ (ОЗУ 32ГБ). Для понимания принципов работы swap в Linux воспользовался статьёй An introduction to swap space on Linux systems Будет надо, позже изменю.

Первичная настройка Debian

Важное замечание. На протяжение всей статьи я работаю из под учётки root, поэтому избавлен от необходимости использовать sudo. После первичной установки, конечно, лучше переключиться на учётку, которая была создана в процессе установки Debian.

Поскольку не маркированные тегом VLAN соединения в моей сети запрещены, в процессе установки ОС соединения с Сетью у меня не было. Для дальнейших шагов потребовалось настроить сеть в Debian. Много намаялся на данном этапе в силу моего незнания принципов настройки сетей в Linux (здравствуй Опыт!). В итоге настроил первичный доступ выполнив следующее.

Загрузить модуль 8021q, отвечающий за работу VLAN:

modprobe 8021q

Настроить VLAN в файле /etc/network/interfaces:

# Source custom network configuration files
source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

iface enp3s0 inet manual

auto enp3s0.44
iface enp3s0.44 inet static
    address 10.44.44.9/24
    gateway 10.44.44.1
    dns-nameservers 10.44.44.1

Здесь enp3s0 — имя «железного» сетевого адаптера в моей системе. Debian теперь использует предсказуемые имена для этих интерфейсов, а не «старые добрые» eth0 и им подобные. Посмотреть как называется ваши адаптеры можно с помощью команды ip link show. enp3s0.44 — имя VLAN-адаптера. Debian понимает, что это VLAN адаптер по использованному синтаксису .vlan-tag. Раньше это делалось с помощью параметра vlan-raw-device, но этот синтаксис теперь признан устаревшим.

Также обратите внимание, что интерфейс enp3s0 объявлен, как manual. Это означает, что ему не будет назначаться адрес, и напрямую его использовать нельзя. Также для него не указано, что он должен подняться автоматически (нет инструкции auto enp3s0). Его поднимут зависимые от него интерфейсы (в моём случае enp3s0.44).

Интерфейс enp3s0.44 имеет статический адрес, так как это сервер и нужна некоторая предсказуемость в адресации. Gateway и DNS-сервер настроены на домашнем роутере отдельно для VLAN 44.

Loopback-интерфейс можно не объявлять и не описывать, система и так про него знает. Далее я избавлюсь от этого объявления. Люблю удалять лишнее.

Перезагрузить систему:

reboot

После перезагрузки настроил источники пакетов в файле /etc/apt/sources.list:

deb http://deb.debian.org/debian bullseye main contrib non-free
deb-src http://deb.debian.org/debian bullseye main contrib non-free

deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free

deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free

deb http://deb.debian.org/debian bullseye-backports main contrib non-free
deb-src http://deb.debian.org/debian bullseye-backports main contrib non-free

Для редактирования файлов я использовал редактор Nano, предустановленный в Debian. В дальнейшем я отвяжусь и от него. Извините, олдфаги, я привык к роскоши современных редакторов под Windows и, самое главное, к их клавиатурным сочетаниям.

Обновить пакеты Debian и установить драйверы для нестандартного оборудования:

apt update
apt upgrade
apt install linux-firmware-nonfree

Установка Xen Project

Сама установка весьма проста и не вызвала вопросов:

apt install xen-system-amd64
reboot

Перенос конфигурации виртуального роутера Hyper-V

Установил инструменты, необходимые для настройки VLAN (да, я уже использовал VLAN до установки этого пакета, так как необходимые сетевые компоненты уже встроены в ядро ОС):

apt install vlan

На этом этапе пришлось погрузиться в настройку Linux-сетей ещё глубже. Статья Xen on Debian Stretch (with VLAN networking) увела меня не туда. Автор, с моей точки зрения, делает какую-то экзотику, толком не объясняя что для чего нужно (уровень статьи для уже достаточно опытных в данном вопросе), хотя комментариев достаточно много. Разобраться помогли статьи How To Configure VLAN Interface on Debian 10/11 и Create Linux Bridge on VLAN Interface in Debian 11/10. Главный принцип оказался прост: все промежуточные сетевые интерфейсы (физический и VLAN) должны быть настроены как manual (они работают на 1-ом и 2-ом уровне сетевого стека), и только интерфейс моста содержит конфигурацию IP (в моём случае статическую). Сеть в виртуалках Xen может быть настроена по-разному, но самое простое — это мост. Мой случай несколько сложнее, чем в большинстве статей по данному вопросу, я использую VLAN. Вот что у меня получилось в конечном итоге (файл /etc/network/interfaces):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*

# The primary network interface.
iface enp3s0 inet manual

# Local network VLAN and bridge.
iface enp3s0.44 inet manual

auto xenlan44
iface xenlan44 inet static
	bridge_ports enp3s0.44
	address 10.44.44.9
	netmask 255.255.255.0
	gateway 10.44.44.1
	dns-nameservers 10.44.44.1
	bridge_stp on
	bridge_waitport 0
	bridge_fd 0
	bridge_maxwait 0

# DMZ VLAN 55 and bridge.
iface enp3s0.55 inet manual
	pre-up ip link set dev $IFACE up
	post-down ip link set dev $IFACE down

auto xendmz55
iface xendmz55 inet manual
	bridge_ports enp3s0.55
	bridge_stp on
	bridge_waitport 0
	bridge_fd 0
	bridge_maxwait 0

# DomU local communication interface and bridge.
iface dummy0 inet manual
	pre-up ip link set dev $IFACE up
	post-down ip link set dev $IFACE down

auto xenlocal
iface xenlocal inet static
	bridge_ports dummy0
	address 192.168.127.1
	netmask 255.255.255.0
	bridge_stp off

xenlan44 — это мост, используемый для «внутренней» сети с тегом VLAN 44. Он будет использован для «внутренних» виртуалок, вроде контроллера домена и самим Xen-хостом (dom0). bridge_ports enp3s0.44 говорит о том, что мост будет маршрутизировать свой трафик в VLAN 44. IP-адрес ему назначен статический (address 10.44.44.9). Все параметры, начинающиеся с bridge_, являются дополнительными настройками моста, и я не стану их описывать. В принципе, можно обойтись и без них.

Интерфейс для VLAN 55 enp3s0.55 и мост xendmz55 настроены несколько специфично, с использованием событий pre-up и post-down и без настройки адресации. Вызвано это тем, что, во-первых, Xen-хост не нуждается в этом интерфейсе, его используют только виртуалки, находящиеся в DMZ, а во-вторых, когда я настраивал мост аналогично xenlan44 при старте ОС в логах была ошибка настройки сети (что-то про File exists). Судя по отзывам специалистов, сообщение это не говорит об истинной причине проблемы. Короче, я решил не копать глубже и остановился на этом, тем более, что смотре «во-первых».

xenlocal создан по следам статьи, которую я упомянул в начале данного раздела, на будущее. Он может пригодиться для общения виртуалок между собой без обращения к роутеру. Подробно на нём я останавливаться не стану, так как в данной статье он использоваться не будет. В вашей конфигурации сети его можно не использовать.

Настройки сети, необходимые для гипервизора

Честно скажу, я не стал детально разбираться для чего они нужны, но встретил их в нескольких статьях, поэтому принял на веру и сделал:

echo "net.ipv4.ip_forward=1" | tee -a /etc/sysctl.conf
echo "net.ipv4.conf.all.arp_filter=0" | tee -a /etc/sysctl.conf
echo "net.ipv4.conf.all.rp_filter=2" | tee -a /etc/sysctl.conf

Перезагрузить ОС. Проверить настройки:

brctl show
ip link show
ip route show
ping ya.ru

Настройка рекомендованных параметров загрузки Xen

Большинство статей (включая Xen Project Best Practices) рекомендуют настраивать загрузку Xen, изменяя переменные в файле /etc/default/grub. В частности, GRUB_CMDLINE_XEN или GRUB_CMDLINE_XEN_DEFAULT. Я нашёл, как я думаю, более правильный конфигурационный файл Xen: /etc/default/grub.d/xen.cfg.

Закрепление фиксированного количества памяти и процессорных ядер за dom0:

GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1G,max:2G dom0_max_vcpus=1-2"

Переменная с DEFAULT применяется только для нормального режима загрузки, в то время как без DEFAULT к нормальному режиму и режиму восстановления.

Для предотвращения вывода предупреждения во время обновления конфигурации GRUB с помощью update-grub:

WARNING: GRUB_DEFAULT changed to boot into Xen by default!
         Edit /etc/default/grub.d/xen.cfg to avoid this warning.

…и запуска Xen по умолчанию (а не голого Debian) в том же файле поменял:

XEN_OVERRIDE_GRUB_DEFAULT=1

Обновить конфигурацию GRUB и перезапустить систему:

update-grub
reboot

Более подробно о всех параметрах командной строки Xen: Xen Hypervisor Command Line Options.

Восстановление загрузки Windows Server 2012 R2

После установки Debian выяснилось, что есть две проблемы. Во-первых, пункт меню в GRUB назван некорректно Windows Recovery Mode, но с этим можно жить, а вот вторая проблема более существенная: Windows не загружается. Симптом — при выборе этого пункта меню загрузка останавливается на чёрном экране. Каким-то образом Windows попала в режим гибернации. Решение следующее. Во-первых, необходимо установить необходимые пакеты для работы с NTFS из Debian (они, кстати, пригодились мне и на последующих этапах):

apt install ntfs-3g fuse

Во-вторых, собственно, восстановить состояние Windows с помощью команды:

ntfsfix /dev/sdc2

Здесь /dev/sdc2 — это раздел, упомянутый в пункте меню GRUB Windows Recovery Mode.

Решение взято из статьи Fix Unable to mount Windows (NTFS) filesystem due to hibernation on Linux.

Также стоит проверить настройки Windows касательно гибернации: How to Turn On or Off Fast Startup in Windows 10.

Перенос Windows-виртуалок с Hyper-V на Xen

Подготовка дисков виртуалок

Во-первых, нужно решить, как будут храниться диски виртуалок. Есть два варианта: в виде блочного устройства (например, обычный диск или LVM-раздел) или в виде файла, аналогично Hyper-V. Оба способа имеют свои достоинства и недостатки. С файловыми дисками работать проще, их легче перенести, они эффективнее используют дисковое пространство. LVM-диски быстрее и моднее, но работать с ними несколько сложнее, это решение ближе к промышленному использованию. На одной из виртуалок я попробовал оба варианта и решил пойти во все тяжкие и остановиться на LVM варианте. Но есть проблема…

В Hyper-V я использую динамически расширяемые диски. Пока данных на виртуальном диске мало, динамически расширяемый vhdx-файл занимает мало места на физическом диске, однако, в самой ОС виртуалки такой диск может имеет полный назначенный ему размер. Размечал я их когда-то с запасом. Во время преобразования виртуального диска в LVM-раздел размер диска становится равен размеру виртуального «физического» диска. Например, один из моих «физических» виртуальных дисков был 200ГБ, в то время как данных на нём было едва ли на 10ГБ. Файл этого виртуального диска занимал на физическом диске Hyper-V сервера около 10ГБ, но для того, чтобы он поместился в LVM-раздел, размер раздела должен быть 200ГБ.

Что с этим можно сделать? Либо использовать файловые «физические» диски, либо ужать их перед переносом в LVM-раздел. В любом случае перед преобразованием диска нужно сделать то, что я описал в разделе «Подготовка Windows-сервера и виртуалок», то есть: удалить всё лишнее на дисках, дефрагметировать, «поджать» логические диск, освободив незанятое место в конце «физического» диска, экспортировать диски выключенной виртуалки.

Сжать «физический» виртуальный диск

После сжатия раздела на виртуальном диске, в его конце остаётся незанятое место. Его нужно удалить. На Hyper-V хосте открываем PowerShell и выполняем следующую команды:

Resize-VHD B:\vhdx\dmz01-system.vhdx -ToMinimumSize

Диск B: — это обычный HDD «железного» сервера Windows, размеченный NTFS, это не floppy disk. Просто с какого-то момента я понял, что первые две буквы перестали использоваться, и я начал их использовать для обычных дисков. Папка B:\vhdx\ — это место, куда я скопировал все VHDX-файлы всех экспортированных виртуалок.

Я очень долго искал, как обрезать «физический» виртуальный диск правильно. Вначале пошёл неправильным путём и обрезал уже RAW-диск с помощью qemu shrink, чем привёл GPT раздел в частичную негодность. Но наконец-то случайно наткнулся на Resize-VHD, чему несказанно рад.

Создать LVM volume group и необходимые logical volumes

Тема LVM весьма обширна и я в неё не стал сильно углубляться. Можно рассматривать LVM, как инструменты управления разделами на жёстком диске. Считаю, что для начала достаточно и этого.

Во-первых, ставим необходимый пакет:

apt install lvm2

Во-вторых, создаём virtual group в свободном разделе диска, где будут храниться данные виртуалок. Желательно выбирать SSD, так как использоваться этот диск будет в несколько раз интенсивнее, чем даже диск основной операционной системы (domain 0, dom0 в терминах Xen):

vgcreate vg0 /dev/sbc

Обратите внимание, диск не должен быть размечен никакой файловой системой. Это должен быть «сырой» диск.

В-третьих, создать необходимые разделы (logical volume) в созданной ранее группе (volume group):

lvcreate --size 200g --name vms --activate y vg0

Здесь стоит обратить внимание на активацию раздела. Была у меня «затыка» с этим.

Преобразовать VHDX-файлы дисков в нужный формат

Дальнейшее зависит от того, как будут хранится диски виртуалок. В случае, если будут использоваться диски как файлы, нужно разметить один LVM logical volume (или просто ext4-раздел на свободном диске в Debian) и преобразовать vhdx-файлы, экспортированные из Hyper-V, в qcow2-формат (именно он поддерживается Xen и является наиболее «продвинутым» среди прочих). Если принято решение хранить данные виртуалок в LVM-разделах, преобразуем в raw-файлы.

Смонтировать NTFS-диск в Debian

Если вы ранее не установили пакеты ntfs-3g и fuse, установите их:

apt install ntfs-3g fuse

Узнать путь к диску с образами дисков виртуалок:

fdisk -l

В моём случае часть вывода, описывающая NTFS-диск, выглядит следующим образом:

Disk /dev/sda: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFAX-68J
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 15606F18-9C74-456A-9177-517B27130215

Device      Start        End    Sectors  Size Type
/dev/sda1      34     262177     262144  128M Microsoft reserved
/dev/sda2  264192 7814035455 7813771264  3.6T Microsoft basic data

То есть путь к диску, который доступен на Windows-хосте, как B: в моей Debian доступен как /dev/sda2.

Создать папку для монтирования диска и, собственно, смонтировать его:

mkdir /mnt/win-vms
mount --types ntfs /dev/sda2 /mnt/win-vms

Проверяем по содержимому, что всё сделали правильно:

ls -lh /mnt/win-vms

Диски виртуалок в виде файлов

Преобразуем диски командой:

qemu-img convert /mnt/win-vms/vhdx/dmz01-system.vhdx -p -O qcow2 /data/vms/dmz01-system.qcow2

Здесь /mnt/win-vms/vhdx/dmz01-system.vhdx путь к ранее экспортированному файлу диска виртуалки. -p указывает на то, что мы хотим видеть прогресс операции. -O qcow2 /data/vms/dmz01-system.qcow2 — тип конечного файла и путь к нему. /data/vms/ путь к папке, где будут храниться файлы виртуальных дисков виртуалок.

Диски виртуалок в виде разделов LVM

Тут немного сложнее. Во-первых, как и в случае QCOW2 конвертируем исходные VHDX-файлы, но, на этот раз, в RAW-формат:

qemu-img convert /mnt/win-vms/vhdx/dmz01-system.vhdx -p -O raw /mnt/win-vms/raw/dmz01-system.raw

Определяем размер получившегося raw-файла:

ls -lh /mnt/win-vms/raw/dmz01-system.raw

Далее необходимо создать LVM logical volume размером, равным размеру raw-файла или чуть больше.

lvcreate --size 22g --name dmz01-system --activate y vg0

«22g» — размер raw-файла. «dmz01-system» — называние нового раздела. «vg0» — название LVM volume group, созданной ранее.

И, наконец, последний штрих — копирование содержимого raw-файла в новый раздел:

dd if=/mnt/win-vms/raw/dmz01-system.raw of=/dev/vg0/dmz01-system bs=4M status=progress

На этом работа с дисками закончена. vhdx- и raw-файлы можно удалить. Советую, на всякий случай, сделать резервную копию vhdx-файлов.

Создание гостевых доменов

Гостевыми доменами (domU) в Xen называются виртуалки. Всё, что нужно для их создания — это создать файл конфигурации для каждого из доменов.

Файл конфигурации домена

В файле конфигурации домена собраны все настройки виртуалки. Местом по умолчанию для этих файлов является папка /etc/xen. Имена и расширения их, как я понял, могут быть произвольными. В данном случае я создал файл /etc/xen/dmz01.hvm. Вот мой минимальный шаблон этого файла для Windows-виртуалки:

name = "dmz01"
uuid = "755d7dd8-c96c-4cdc-a947-f95dc344fd2a"
type = "hvm"
firmware="uefi"
viridian = [ 'all' ]

memory = 2048
vcpus = 2

vif = [ 'bridge=xendmz55' ]
disk = [ '/dev/vg0/dmz01-system,raw,hda,rw' ]

localtime = 1

vnc = 1
vnclisten = "10.44.44.9:3"
vncpassword = ""

Разберём эти параметры по порядку.

• name — имя виртуалки, которое будет использоваться в командах xl. Например, xl destroy.

• type — тип виртуализации. Для Windows всегда hvm.

• firmware — как виртуалка будет запускаться. Для Windows есть два варианта: bios — используется MBR, uefi — используется UEFI. Если указать неподходящий тип, виртуалка не запустится.

• uuid — уникальный идентификатор данной виртуалки. Можно сгенерировать разнообразными инструментами, например Online UUID Generator. У каждой виртуалки, понятное дело, должен быть свой, уникальный.

• viridian — включает поддержку Hyper-V оптимизаций. Для Windows, конечно, имеет смысл использовать.

• memory — начальное количество памяти, которое будет отдано виртуалке. Есть ещё один параметр maxmemory использовать не рекомендую, так как виртуалки, даже с установленными PV-драйверами крашаться.

• vcpus — начальное количество виртуальных ядер процессора, которое будет отдано виртуалке. Парный ему параметр maxvcpus использовать не рекомендую, так как виртуалки, даже с установленными PV-драйверами крашаться.

• vif — перечень виртуальных сетевых интерфейсов. XL Network Configuration Syntax.

• disk — перечень блочных устройств, подключаемых к виртуалке. XL Disk Configuration Syntax.

• localtime — важный момент, если ваша виртуалка находится в Windows-домене. По умолчанию этот параметр равен 0, то есть виртуалка будет получать время во временной зоне с нулевым смещением. Для синхронизации с контроллером домена время локальной машины и контроллера домена не должно различаться более чем на несколько минут (точных цифр сейчас уже не помню). Мы все живём в часовых поясах, которые отличаются от Гринвича на несколько часов. То есть синхронизация будет «обламываться». Сказав, что часы виртуалки работают в локальном часовом поясе (например, для Москвы +3 часа), вероятность первоначальной синхронизации с контроллером домена, а значит и получения его актуального времени от контроллера домена, повышается.

Также стоит добавить в файл конфигурации следующий текст для ещё большей оптимизации её работы:

ms_vm_genid = "generate"
xen_platform_pci = 1
hdtype = "ahci"

Параметров значительно больше, но этих достаточно для начала. Все параметры и их синтаксис можно посмотреть в xl.cfg - xl domain configuration file syntax.

VNC

Особняком стоят параметры, относящиеся к настройке графической консоли управления. Для первичного запуска виртуалки VNC-консоль обязательна. В дальнейшем я предпочитаю перейти на RDP, как более адекватный протокол для удалённого управления Windows. После доведения виртуалки до ума, их лучше удалить или закомментировать.

• vnc — включает или выключает VNC Server для виртуалки.

• vnclisten — на каком адресе и «дисплее» сервер будет ожидать подключения. Порт подключения вычисляется так: 5900 + display-number. Если не указать адрес, сервер будет доступен только по адресу 127.0.0.1, что в случае хоста без графического интерфейса смысла не имеет. Если не указать номер дисплея, можно запутаться с портами подключения разных виртуалок, так как они будут назначаться динамечески.

• vncpassword — пароль подключения. Для первичной настройки можно указать пустым.

Я попробовал несколько VNC-клиентов. У меня заработал только TightVNC, остальные на что-то жаловались.

Помимо этого необходимо открыть порты для подключения к VNC-серверу на стороне хоста (dom0) в сетевом экране. Порты 5900-5909. Я не стану рассматривать настройку firewall, порекомендую лишь один из наиболее простых: ufw. Можно ознакомиться, например, в статье Как заблокировать IP адреса через ufw.

Первичный запуск виртуалки

На этом месте у меня начались танцы с бубном. В моём случае виртуалка с MBR запустилась быстро и без каких-либо проблем, а вот UEFI-виртуалки падали на старте несколько раз, пока не доходили до устойчивой работы. В последствие выяснилось, что виной падений было использование параметров maxvcpus и maxmemory, а долгого старта — малое количество памяти, которое я давал виртуалке. Windows-виртуалке стоит выделить от 2 гигабайт памяти и от 2 виртуальных ядра процессора. Уже потом, после установки PV-драйверов, можно скорректировать эти значения под нагрузку машины.

Итак, запускаем виртуалку (создаём домен):

xl create /etc/xen/dmz01.hvm

И сразу подключаемся к VNC-серверу, наблюдаем загрузку виртуалки. Ждём. В случае UEFI-виртуалки процесс этот может занять до нескольких минут.

Настройка виртуалки под новое окружение

Настройка сетевого подключения

После того, как виртуалка наконец-то загрузится, и удастся залогиниться в неё, необходимо первым делом настроить сеть. В моём случае я использую статическую адресацию для своих серверов. Описывать эту настройку не буду, так как она предельно проста и стандартна для Windows-машин.

Единственное замечание, управление мышкой в VNC до установки PV-драйверов «страдает». Амбразурка окна 800 на 600 пикселей, а курсор мышки никак не хочет совмещаться с точкой клиента. Поэтому вспоминаем управление клавиатурой: таб, пробел, ввод…

В моём случае для виртуалок внутренней сети используется шлюз xenlan44 подсеть 10.44.44.0/24, для виртуалок в DMZ xendmz55 подсеть 10.44.55.0/24. Смотрите настройки в файле /etc/network/interfaces

После того, как сеть настроена, можно забыть про VNC, как страшный сон (до следующей виртуалки), и перейти на нормальный RDP (да простят меня апологеты VNC!).

Установить PV-драйверы

Чтобы ускорить виртуалку и сделать её работу более устойчивой, необходимо установить в ней Windows PV драйверы. Я нашёл эти: WINDOWS PV DRIVERS 9.0.0

• WINDOWS PV 9.0.0 KEYBOARD AND MOUSE CLASS DRIVER (XENVKBD.TAR) Репозиторий GitHub.

• WINDOWS PV 9.0.0 HUMAN INTERFACE (KEYBOARD AND MOUSE) DRIVER (XENHID.TAR) Репозиторий GitHub.

• WINDOWS PV 9.0.0 CONSOLE DRIVER (XENCONS.TAR) Репозиторий GitHub.

• WINDOWS PV 9.0.0 STORAGE HOST ADAPTER DRIVER (XENVBD.TAR) Репозиторий GitHub.

• WINDOWS PV 9.0.0 NETWORK DEVICE DRIVER (XENNET.TAR) Репозиторий GitHub.

• WINDOWS PV 9.0.0 NETWORK CLASS DRIVER (XENVIF.TAR) Репозиторий GitHub.

• WINDOWS PV 9.0.0 INTERFACE (XENIFACE.TAR) Репозиторий GitHub.

• WINDOWS PV 9.0.0 BUS DRIVER (XENBUS.TAR) Репозиторий GitHub.

Возможно есть и более свежие и продвинутые, но мне хватило и этих.

В процедуре инсталляции драйверов в их репозиториях сказано, что они не подписаны как надо, поэтому, якобы, нужно устанавливать их в testsigning-режиме. Я так не заморачивался и делал следующее (судя по всему, драйверы в TAR-файлах всё же подписаны):

1. Скачал все tar-файлы.

2. Разархивировал все tar-файлы в одну папку. Каждый драйвер лёг в свою подпапку.

3. Скопировал с помощью RDP папки с драйверами в виртуалку.

4. Последовательно прошёлся по всем папкам и установил драйверы из папок x64 запуская dpinst.exe.

5. Перезапустил виртуалку.

Удалить сервисы Hyper-V

Гипервизор теперь новый и нужно подчистить следы Hyper-V в системе. Удаляем все сервисы Hyper-V. Команды ниже нужно выполнять именно в консоли cmd, так как в PowerShell эти команды значат совсем другое, а командлет Remove-Service есть не во всех версиях (в PowerShell 4.0, например, его нет).

sc delete vmicguestinterface
sc delete vmicheartbeat
sc delete vmickvpexchange
sc delete vmicrdv
sc delete vmicshutdown
sc delete vmictimesync
sc delete vmicvss

Восстановить связь с контроллером домена

У меня возникла следующая проблема: виртуалки в домене потеряли связь с контроллером домена. То есть команда gpupdate /force выдавала ошибки, которые, как я понял, связаны с ненадёжностью сетевого канала связи. Помогло мне следующее. В PowerShell, запущенном с администраторскими правами необходимо выполнить следующую команду:

Test-ComputerSecureChannel -Credential (Get-Credential) -Verbose -Repair
Restart-Service NLASvc -Force 

Вводим логин и пароль администратора домена и получаем сообщение: VERBOSE: The secure channel between the local computer and the domain home.eshva.ru was successfully repaired.

Однако, после перезапуска подключение к «внутренней» сети так и переключалось с режима domain в режим public. Пробовал фиксировать MAC-адрес адаптера в файле конфигурации адаптера, не помогло. Я пока так и не нашёл решение этой проблемы. Может быть кто-то знает решение?

Автоматизировать запуска виртуалки при старте хоста Xen

При перезапуске Xen виртуальные машины не запускаются автоматически. Добиться этого довольно просто, нужно лишь разместить файлы конфигурации виртуалок или ссылки на них в папке /etc/xen/auto. Папку эту для начала нужно создать.

mkdir /etc/xen/auto
ln -s /etc/xen/dmz01.hvm /etc/xen/auto

Xen может даже делать snapshot’ы виртуальных машин перед собственной перезагрузкой и поднимать виртуалки после старта из них, но, к сожалению, виртуалки после этого остаются в зависшем состоянии. Я попытался поиграться с параметрами виртуалок, но решить эту проблему не смог. Скорее всего, виртуалки нужно уводить в гибернацию перед снятием snapshot, но как это сделать, я пока не разобрался. Стоит отключить эту возможность в файле /etc/default/xendomains установив параметр XENDOMAINS_RESTORE=false.

Вот, собственно, и всё!

Тест производительности работы с дисковой подсистемой

Ради интереса измерил скорость работы с одним и тем же физическим диском (SSD) одной и той же виртуалки в разных гипервизорах, с и без драйверами. Измерял с помощью CrystalDiskMark. Запущена была только одна виртуалка на хосте.

Поверхностные выводы из поверхностных тестов:

1. Xen с драйверами быстрее Hyper-V или сопоставим с ним.

2. Xen с драйверами быстрее Xen без оных.

3. Случайный доступ в Xen на LVM с драйверами в некоторых тестах быстрее Xen с «файловым» диском, в некоторых медленнее.

4. Видимо, я не умею готовить LVM и/или тестировать производительность дисковой подсистемы, так как документация говорит, что LVM должен быть быстрее «файлового» варианта. Собственно, особо и не старался. Меня и так более чем устраивает.

Использование Visual Studio Code для редактирования файлов на хосте Xen и терминала

Как я сказал ранее, я совсем отказался от использования Nano для редактирования файлов хоста Xen. Сделать это достаточно легко. Процедура хорошо описана в статье Remote Development using SSH. Конечно, для этого необходимо настроить SSH-сервер, создать пару ключей и т.д., но это описано множество раз до меня, поэтому и на этом я останавливаться не буду.

Желаю успехов в освоении Linux! Это по истине замечательная операционная система, как минимум для серверов. Надеюсь статья понравится и я опубликую её продолжение про установку Kubernetes и развёртывание в нём достаточно сайта, написанного с использованием .NET Core и Angular.