Провел небольшое тестирование двух технологий виртуализации — KVM и Xen в сравнении с реальным железом. Подопытные кролики:
* Реальное железо: AMD Athlon x2 3800+ 2 Gb RAM одиночный диск с LVM. Ядро 2.6.34.1
* KVM: гипервизор — та же система, что и на реальном железе, домен — самосборное безмодульное ядро 2.6.34.1 со включенной оптимизацией для использования в качестве KVM-домена. 1,1 Гб ОЗУ, 2 ядра
* Xen: гипервизор 4.0.1-rc3, dom0 — ядро 2.6.32.16 (самосбор из git’a проекта), domU — самосборное безмодульное ванильное 2.6.34.1, паравиртуальные драйверы сети и диска. 1,1 Гб ОЗУ, 2 ядра
Для дерева исходного кода ядра выделен отдельный логический раздел в LVM’e, который использовался во всех трех случаях. Производилась сборка ванильного ядра 2.6.34.1 стандартными Debian’овскими средствами (time make-kpkg kernel_image –initrd), для второго теста делалась зачистка командой make clean mrproper, после чего заново копировался конфиг. Сборка делалась в 3 потока (так что 1 Гб памяти вполне хватит и для компиляции, и для кэширования). В случае с виртуальными машинами использовался один и тот же корневой раздел.
*** KVM test 1 ***
real 20m3.221s
user 30m31.751s
sys 7m12.433s
*** KVM test 2 ***
real 19m44.205s
user 30m6.624s
sys 7m7.920s
*** Xen test 1 ***
real 14m45.813s
user 22m37.477s
sys 5m13.125s
*** Xen test 2 ***
В пределах погрешности
*** Реальное железо ***
real 12m53.008s
user 21m24.158s
sys 2m26.534s
*** Реальное железо 2 ***
real 12m37.855s
user 21m24.213s
sys 2m23.840s
В общем, впечатления какие:
KVM:
+ Работает все то, что и в обычной системе — энергосбережение, например, управление частотой процессора.
+ Работает стабильно
+ Весь необходимый для работы код есть в ядре
+ Для запуска не требуется почти никаких телодвижений — виртуальная машина работает как еще один процесс (или несколько процессов) в хост-системе
— Как выяснилось — повышенный расход ресурсов процессора.
— Нет всяких удобных плюшек типа Xen console
Xen:
+ Производительность близка к той, что у реального железа — нет лишней прослойки в виде еще одной системы
+ Нет необходимости точно эмулировать реальное железо — есть паравиртуальные драйверы для сети и диска (для KVM тоже пилится подобное, но пока оно носит экспериментальный статус)
+ Можно работать в системе полностью без графики — подключение и отключение от консоли делается стандартными средствами (в KVM приходилось делать вывод через эмуляцию последовательного порта и держать сессию с терминалом в скрине либо лепить vnc)
— Стабильная версия основана на устаревшем ядре 2.6.18, то, что используется в более новых версиях активно пилится, однако сделав собственную сборку ядра на базе 2.6.32.16 словил кучу kernel oops’ов из-за глюков бэкэнда сетевого драйвера (например, при последовательном запуске десятка машин первые несколько штук запустились нормально, потом словил один oops, другой и в итоге вся подсистема обеспечения сети завалилась — сети не было в том числе и в уже запустившихся машинах). Чего, однако, не было на дистровом ядре той же версии — возможно там был более удачный срез из git’a. В общем, лотерея.
— В dom0 не работают некоторые фичи, работающие в обычной системе — например, у меня не работала регулировка частоты процессора, из-за чего тот постоянно молотил на максимальной мощности. Как выяснилось на официальной вики, именно моя cpu family (15) не поддерживается
А, да, к глюкам Xen’а… Тест собирался выложить еще вчера, однако провести финальное тестирование не получилось — компилятор сегфолтился на ровном месте. Пробовал как дистровое ядро для dom0, так и самосбор. Сегодня уже хотел подбирать конфиг ядра для domU, чтобы найти ту волшебную формулу, при которой оно у меня собиралось раньше… Но все не менее волшебным образом заработало.
Дополнение по мотивам linux.org.ru:
*** KVM (как и в прошлом тесте) ***
real 24m35.649s
user 33m21.312s
sys 11m53.370s
*** KVM (для раздела с исходниками cache=none) ***
real 23m23.782s
user 32m49.541s
sys 10m55.605s
*** KVM (virtio-драйвера для сети и диска, cache=none для обеих дисков) ***
real 23m10.719s
user 32m30.124s
sys 10m23.757s
Первый тест был сделан заново, так как была снижена частота проца с 2,5 ГГц до 2 ГГц (был разгон по шине, сменил память, старая пошла в сервер, а новая не держала такую частоту — отсюда и сегфолты на ровном месте в Xen’e при компиляции)
Сделал еще новый тест для реальной системы:
real 15m51.075s
user 26m17.395s
sys 3m12.601s