Xen 3.0 HVM: запускаем немодифицированную Windows через Intel VT на Linux-хосте

В декабре вышел Xen 3.0.0, и главное в нём - HVM. Hardware Virtual Machine, аппаратная виртуализация через Intel VT-x. Это значит, что гостевой ОС больше не нужно знать, что она под гипервизором, и не нужно патченое ядро. Немодифицированный Windows можно поднять как domU прямо на Linux-хосте.

Мы подождали месяц-другой, пока первая паника в рассылках немного улеглась, и в марте решили попробовать.

Что нужно для HVM

Xen 3.0 с HVM требует процессора с поддержкой Intel VT-x - флаг vmx в /proc/cpuinfo. Не все серверы его имеют даже сейчас: VT-x появился в серверных Xeon относительно недавно, и не каждый BIOS включает его по умолчанию. У нас был подходящий Xeon; первое, что сделали, - зашли в BIOS и убедились, что Virtualization Technology включена. Без этого Xen загрузится, но xm create с HVM-конфигом упадёт с невразумительной ошибкой.

AMD тоже анонсировала свою технологию аппаратной виртуализации - AMD-V (Pacifica), - но серверных AMD-процессоров с ней у нас под рукой не было, так что проверяли только на Intel.

Хост. Debian Sarge, ядро с патчами Xen из xen-source-2.6, загрузчик - GRUB с отдельной записью для Xen:

title Xen 3.0 / Debian
root (hd0,0)
kernel /boot/xen-3.0.gz dom0_mem=256M
module /boot/vmlinuz-2.6.12-xen root=/dev/sda1 ro
module /boot/initrd-2.6.12-xen.img

После перезагрузки xm info показывает гипервизор и наличие флага hvm.

Конфиг гостя

HVM-домен описывается иначе, чем паравиртуальный Linux. Никакого kernel = и ramdisk = - вместо них builder = "hvm" и загрузка с виртуального CDROM или диска. Файл в /etc/xen/winxp.cfg:

builder = "hvm"
name    = "winxp"
memory  = 512
vcpus   = 1
disk    = [ "file:/var/xen/winxp.img,hda,w",
            "file:/path/to/winxp.iso,hdc:cdrom,r" ]
vif     = [ "type=ioemu, mac=00:16:3e:xx:xx:xx" ]
boot    = "d"
sdl     = 0
vnc     = 1
vncunused = 1

Ключевое слово здесь - ioemu. Сетевой интерфейс и диск у HVM-гостя - полная эмуляция через QEMU, встроенный в Xen. Никаких xen-драйверов для Windows под Xen 3.0 нет, Windows ничего не знает про Xen и работает с виртуальным IDE-контроллером и виртуальной сетевой картой Realtek.

xm create /etc/xen/winxp.cfg запускает домен, xm list показывает его. Подключаемся через VNC - и видим стандартный установщик Windows XP.

Где радость и где грабли

Радость. Windows встала. Немодифицированный дистрибутив, без каких-либо патчей под гипервизор. Для нас это был принципиальный момент: у нескольких клиентов есть специфический Windows-софт, который нельзя переехать на Linux. Раньше приходилось держать для него отдельное физическое железо или VMware ESX. Xen HVM открывает третий вариант - поднять рядом с паравиртуальными Linux-гостями на том же железе.

Первые грабли - I/O. Разница между паравиртуальным Linux-гостем и HVM Windows ощутима. PV-гость общается с dom0 через xen-blkfront и xen-netfront - это эффективные каналы с минимальными накладными расходами. HVM-гость гоняет I/O через эмуляцию QEMU: каждая операция чтения-записи проходит через эмулятор, который имитирует IDE-контроллер. На практике это означает, что под нагрузкой дисковый I/O HVM-гостя заметно медленнее, чем у PV-Linux. Для файлового сервера с активной записью - неприятно. Для веб-приложения, которое в основном читает, - терпимо.

Вторые грабли - стабильность. За две недели тестирования домен несколько раз повис без внятного сообщения в логах. Dom0 при этом продолжал работать нормально, другие PV-гости не трогало. Возможно, специфика нашего железа, возможно, сырость HVM в 3.0.0 - исследовать не стали, просто зафиксировали как факт.

Третьи грабли - консоль. У PV-гостя есть xm console, интерактивная текстовая консоль прямо в терминале. У HVM-гостя её нет: управление через VNC, который нужно заранее прописать в конфиге и который требует VNC-клиента. Мелочь, но раздражает в работе.

Паравиртуальный Linux vs HVM Windows: картина в трёх строках

Что в итоге

Для проектов по обслуживанию инфраструктуры HVM в Xen 3.0 - это полезное расширение, но не замена нормальному решению для Windows. Если нужна одна-две Windows-виртуалки рядом с Linux-парком и I/O у них невысокий - уже сейчас можно пробовать. Если на Windows-гость падает серьёзная база данных или файловый сервер с активной записью - стоит подождать, пока или QEMU-эмуляция в Xen не ускорится, или не появятся нативные Xen-драйверы для Windows.

VMware ESX в смешанных Windows/Linux-средах пока убедительнее: зрелый продукт, стабильная работа, понятные инструменты. Но то, что Xen 3.0 вообще может запустить немодифицированный Windows, - это уже другой разговор по сравнению с тем, что было год назад.