Гипервизор KVM
Да простят нас гуру виртуализации, но для начала мы напомним читателям, что такое гипервизор и для чего он нужен. Для выполнения разных по смыслу задач (разработки программного обеспечения, хостинга
KVM — это ПО, позволяющее организовывать виртуализацию на основе ПК под управлением ОС Linux и похожих. С недавнего времени KVM считается составляющей
В процессе работы KVM осуществляет доступ к ядру напрямую посредством
Гипервизор Xen
Изначально студентами Кембриджа был запущен проект, который в итоге стал коммерческой версией Xen. Первый релиз датирован 2003 годом, а в 2007 исходный код выкупила компания Citrix. Xen — это кроссплатформенный гипервизор с большим функционалом и огромными возможностями, что дает возможность применять его в корпоративной сфере. Xen поддерживает паравиртуализацию — особый режим ядра операционной системы, когда ядро настроено на одновременную работу с гипервизором.
В код Xen добавлен только необходимый комплект функций: управление виртуальной памятью и тактовой частотой процессора, работа с DMA, таймером реального времени и прерываниями. Остальной функционал вынесен в домены, то есть в работающие в это время виртуальные машины. Таким образом, Xen — самый легкий гипервизор.
Суть исследования
Тестирование основано на использовании двух серверов SuperMicro, у каждого из которых четырехядерный процессор Intel Xeon
Для хостинга и виртуальных машин мы взяли Fedora 20 (с SELinux). Вот взятые нами версии ПО:
- Kernel: 3.14.8
- Для KVM:
qemu-kvm 1.6.2 - Для Xen: xen 4.3.2
Все корневые файловые системы — XFS с конфигурацией по умолчанию. Виртуальные машины созданы с помощью
Пояснения
Кроме того, конкуренция между гипервизорами жестко контролируется и сведена к минимуму. На большинстве виртуальных серверов у вас будет несколько виртуальных машин, борющихся за время процессора, устройства ввода/вывода и доступ к сети. Наше тестирование не принимает это во внимание. Один гипервизор может иметь низкую производительность при низкой конкуренции за ресурсы, а затем показать куда большую эффективность, чем конкуренты, когда борьба за ресурсы выше.
Исследование проводилось на процессорах Intel, поэтому его результаты могут отличаться для AMD и ARM.
Результаты
Тесты для виртуальных машин, установленных непосредственно на «железо», то есть, без операционной системы (далее — «железо»), послужили основой для тестирования виртуальных машин. Отклонение в производительности между двумя серверами без виртуализации составило 0.51% или менее.
Производительность KVM упала в пределах 1,5% по сравнению с «железом» практически во всех тестах. Только два теста показали иной результат: один из них — тест
В тесте PostMark Xen был медленнее на 14.41%, чем «железо». При перезапуске результаты теста отличались от первоначальных на 2%. Лучший тест для KVM, MAFFT, оказался вторым в списке худших для Xen.
Вот краткий итог тестирования:
| Best Value | Bare Metal | KVM | Xen | |
|---|---|---|---|---|
| Timed MAFFT Alignment | lower | 7.78 | 7.795 | 8.42 |
| Smallpt | lower | 160 | 162 | 167.5 |
| POV-Ray | lower | 230.02 | 232.44 | 235.89 |
| PostMark | higher | 3667 | 3824 | 3205 |
| OpenSSL | higher | 397.68 | 393.95 | 388.25 |
| John the Ripper (MD5) | higher | 49548 | 48899.5 | 46653.5 |
| John the Ripper (DES) | higher | 7374833.5 | 7271833.5 | 6911167 |
| John the Ripper (Blowfish) | higher | 3026 | 2991.5 | 2856 |
| CLOMP | higher | 3.3 | 3.285 | 3.125 |
| C-Ray | lower | 35.35 | 35.66 | 36.13 |
| 7-Zip | higher | 12467.5 | 12129.5 | 11879 |
Если вы хотите увидеть результаты полностью, пройдите по ссылке.
Вместо заключения
В нашем тестировании KVM был почти всегда на 2% медленнее, чем «железо». Xen оказался на 2,5% медленнее в трех тестах из десяти, а в остальных и того хуже: на 5–7%. Хотя KVM показал себя с лучшей стороны в тесте PostMark, следует отметить, что мы провели всего один I/O тест, и для получения более достоверной картины стоит провести еще несколько.
Для выбора правильного гипервизора необходимо правильно оценить характер своих нагрузок. Если ваши нагрузки предполагают меньший объем для процессора и больший для I/O, то можно провести больше I/O тестов. Если же вы работаете, в основном, с аудио и видео, попробуйте тесты x264 или mp3.
[UPD] Как справедливо заметил mister_fog, в 2007 Citrix выкупила не исходный код Xen, а компанию XenSource, которая была основана разработчиками Xen и занималась коммерческим развитием этого открытого проекта. Пруф.
Комментарии (36)
chupasaurus
04.05.2016 13:57+3Невооружённым глазом заметно, что Xen на данном наборе тестов проиграл во всех, поэтому с выводом малость промахнулись.
romantomchak
04.05.2016 14:25Да, я тоже не совсем понял. Здесь сказано, что Xen медленнее:
В трех тестах Xen отличался на 2,5% от скорости «железа», в остальных тестах он оказался еще медленнее.
но в заключение он почему-то становится быстрее
Xen оказался на 2,5% медленнее всего в трех тестах из десяти, а в остальных был выше на 5–7%.
faost
04.05.2016 15:41+2Перевод неправильный.
Xen оказался на 2,5% медленнее всего в трех тестах из десяти, а в остальных был выше на 5–7%
Xen fell within 2.5% of bare metal performance in three out of ten tests but often had a variance of up to 5-7%.
ayurtaykin
04.05.2016 14:02Как же я отстал от жизни, все еще закладывал 30% потерь ресурсов при использовании виртуализации, а тут получается что потери на уровне погрешности…
А вы можете методику тестов описать? Вы пишете что тестировали голое железо, т.е. без ОС, как можно прогнать тесты openssl или 7-zip без использования гостевой ОС?
Cloud4Y
04.05.2016 17:30А вы можете методику тестов описать?
Вот эти тесты.
Тестировали на PVHVM (Xen 4.3)
Под Bare Metal здесь имеется в виду одноимённый тип гипервизора.SamsonovAnton
05.05.2016 23:41То есть Xen работал не в родном для себя режиме полной паравиртуализации (PV), а был притянут за уши к общему с KVM знаменателю — виртуализация аппаратуры с частично паравиртуальными драйверами (HVM+pv)? Такой изврат ещё можно понять, если хочется запустить Windows или FreeBSD x86-64, но не когда дело касается Linux. А если Fedora из коробки не хочет дружить с Xen — так не надо давиться кактусом, когда есть CentOS.
Чтобы довести идею до полного абсурда, авторам следовало бы запустить QEMU-KVM ещё и без KVM вовсе, а ещё лучше — в режиме эмуляции SPARC, скажем. Тогда можно было бы выдать шокирующий пост про то, как виртуализация съедает 90 % быстродействия CPU.
AllexIn
04.05.2016 18:43Ага. Да еще VGA passthrough появился.
loltrol
04.05.2016 21:08И на глаз уже и не заметно что виртуализация, игры пашут на ура.
equand
05.05.2016 13:272-5 процентов потерь виртуализации ~ 5 фреймов на 100, незаметно абсолютно.
loltrol
10.05.2016 16:05Ну даже если там будет 10 процентов, когда у вас монитор 60 герц, а игры выдают минимум 70 кадров — в любом случае будет по максимуму возможностей монитора использоваться. В частности я на глаз в Witcher 3, RotTR разницы не заметил, пашут на ультра настройках, без микро-фризов и просадок.
mister_fog
04.05.2016 14:28Спасибо за статью, интересно было взглянуть на результаты. (Я последнее время слежу за открытыми гипервизорами — по моим постам это заметно ;-) ). Единственное замечание — в 2007 Citrix выкупила не исходный код Xen, а компанию XenSource, которая была основана разработчиками Xen и занималась коммерческим развитием этого открытого проекта.
lovecraft
04.05.2016 15:28+10В состав комплекса включено основное ядро — kvm.ko и элементы UI, включая широко распространенный QEMU.
QEMU — это не «элемент UI», а средство эмуляции оборудования. Точно такой же эмулятор есть в составе Xen (qemu-dm).
Xen поддерживает паравиртуализацию — особый режим ядра операционной системы, когда ядро настроено на одновременную работу с гипервизором.
Это пережиток тех времен, когда процессоры с VT-x/SVM были редкостью. Сейчас она работает медленнее аппаратной виртуализации, потому что управление памятью происходит без аппаратной поддержки со стороны CPU.
В код Xen добавлен только необходимый комплект функций: управление виртуальной памятью и тактовой частотой процессора, работа с DMA, таймером реального времени и прерываниями.
То же самое можно сказать и про модули ядра kvm.ko/kvm_amd.ko/kvm_intel.ko
Остальной функционал вынесен в домены, то есть в работающие в это время виртуальные машины.
В домене работает только гостевая ОС, а эмуляция оборудования средствами qemu-dm происходит в юзерспейсе хоста. Есть, правда еще и stub domains, но их вроде до продакшена не допилили.
Таким образом, Xen — самый легкий гипервизор.
Сравните размер образа мини-ОС гипервизора и размер kvm.ko/kvm_amd.ko/kvm_intel.ko
На самом деле основное отличие Xen от KVM в том, что Xen стартует до запуска Linux, а KVM — после, и Xen запускается в своей собственной mini-OS, а kvm оформлен в виде модуля ядра
и четырьмя драйверами Western Digital RE-3 160GB (RAID 10)
Ай-ай, какими драйверами?
Kernel: 3.14.8
Для KVM: qemu-kvm 1.6.2
Для Xen: xen 4.3.2
Это сильно старый софт, можно сказать, протухший )
Сейчас:
Ядро: 4.6-rc6
QEMU: 2.6.0-rc4
Xen: 4.6.1
У меня есть что сказать по поводу тестов: бессмысленно тестировать производительность CPU — при аппаратной виртуализации она почти не отличается от bare metal, потому что управление памятью и распределение ресурсов CPU происходит на аппаратном уровне. Однако подавляющее большинство тестов в оригинальной статье именно это и делают. Отличия в 2-3% между Xen и KVM можно объяснить чем угодно, даже статистической погрешностью, и в реальных условиях вы эти 3% не заметите. Намного интереснее тестировать I/O, да еще с измерением latency, нагрузки на CPU хоста и гостя из-за эмуляции оборудования, да еще и с гостевой Windows и паравиртуальными драйверами. Вот тут начинается треш и угар — синие экраны при большой нагрузке, system freeze и т.п.lovecraft
04.05.2016 15:30+1Ах да, совсем забыл сказать по поводу того, что PostMark работает под гипервизором быстрее, чем на голом железе — этого не может быть (с), ребята явно забыли выключить где-то кэш.
amarao
04.05.2016 15:36+2Или кто-то лучше использует всякие C-states и скедулинг/numa. Ситуации, когда голая математика на виртуалке работает лучше, чем на baremetall — бывают. Обычно это не заслуга виртуализации, а проблема в неоптимальности работы приложения на заданном конфиге baremetall (smp affinity, numa).
amarao
04.05.2016 15:35+3В домене работает только гостевая ОС, а эмуляция оборудования средствами qemu-dm происходит в юзерспейсе хоста. Есть, правда еще и stub domains, но их вроде до продакшена не допилили.
Если бы так всё было просто. Проблема в том, что xen — «над» операционной системой dom0. Таким образом, получается следующее:
драйвер в domU. Протокол для работы оборудования с dom0, реализованный как драйвер в dom0 плюс userspace демон. Само оборудование — драйвер в dom0, который создаёт «реверсное» устройство (для сети — патч-интерфейс, для блочных устройств — идиотское «реверсное» блочное устройство, куда надо писать то, что гость читает и читать то, что тот пишет), плюс userspace, который его обслуживает в dom0. Оно шаткое и уродливое. Жить с этим можно, но не нужно.
SamsonovAnton
06.05.2016 11:53«Сейчас паравиртуализация работает медленнее аппаратной виртуализации, потому что управление памятью происходит без аппаратной поддержки со стороны CPU».
Это потому что сама идея паравиртуализации в принципе ущербна, или всё же потому, что в AMD64 были убраны «лишние» кольца защиты, заставляя Xen реализовывать программно то, что в i386 обеспечивалось аппаратурой? Если паравиртуализация — это так плохо, то зачем везде, где можно, стараются использовать паравиртуальные драйверы устройств (guest additions)? Как бы то ни было, про PVH тут уже напоминали — без тестирования в этом режиме говорить о какой-либо объективности исследования сейчас трудно.
___
«В домене работает только гостевая ОС, а эмуляция оборудования средствами qemu-dm происходит в юзерспейсе хоста. Есть, правда еще и stub domains, но их вроде до продакшена не допилили».
Dom0 у Xen — это такая же виртуальная машина, пусть и с некоторыми привилегиями. Если не ошибаюсь, у XenServer управляющий домен — 32-битный, что не мешает ему при этом запускать 64-битных гостей в других доменах. Поэтому всё-таки не совсем корректно называть Dom0 «хостом», так как host у Xen — это только сам Xen, а функции высокоуровневого управления машинами и эмуляции устройств для гостей могут быть размазаны между несколькими подчинёнными доменами (Qubes OS наглядный тому пример), при этом привилегированные домены всё равно не имеют прямого доступа к гостевым доменам, в интересах которых они работают.
___
«Сравните размер образа мини-ОС гипервизора и размер kvm.ko / kvm_amd.ko / kvm_intel.ko».
Между 1902 кбайт (885 кбайт gzip) и 852 + 112 / 260 кбайт не такая уж огромная разница. Интересно другое: размер исходников KVM (именно ядерный репозиторий, а не QEMU), даже если выбрать из него только что касается x86, раз эдак в десять-двадцать больше, чем у Xen.
amarao
04.05.2016 15:31+14Xen как серверный гипервизор — мёртв. Остаётся как карманная игрушка цитрикса и всякая экзотика, типа виртуальных десктопов, сотовых телефонов и т.д. Плюс легаси инсталляции. Плюс amazon, который его активно in-house пилит (гипервизор в опенсорсе, userspace — in house).
Поясняю:
Xen родился как развитие идеи binary rewriting. Вместо того, чтобы патчить ОС «на ходу» для перехвата привилегированных инструкций, мы «патчим» её (ОС) при компиляции, за счёт чего имеем огромное ускорение. Это PV-режим работы гипервизора. Он рвал все существующие системы виртуализации на тот момент в клочки.
Потом интел выкатила VT и VT-D, и binary rewriting стал ненужен. Xen сделал морду кирпичом и выкатил HVM-режим, но тут уже начались всякие нюансики в реализации, и он начал гоняться с KVM/VMWare за процентики. Кто-то больше, кто-то меньше. В этот момент он потерял главное рыночное преимущество.
Дальше начались игры «следующего порядка»:
Xen: тяжёлый отвратительный userspace в dom0. xenstore с утечками памяти, залипающие домены, реверсные блочные устройства, шелловые скрипты как часть тулстека по инициализации гостевых устройств. Гигантская куча разрозненных кусков кода, пытающихся подружить разные части линукса с инородной странной сущностью за пределами ОС.
KVM: Виртуалка — это userspace процесс. Легко и просто.
Xen: абстракные computer science исследования — mirage (микроос на окамл для запуска приложений в pv-окружении), stub domains для изоляции «обратной части драйверов», микрочекпоинты (remus), etc.
KVM: то, что нужно индустрии прямо тут и сейчас.
Xen — чужеродная среда с кучей проблем (nvidia не поддерживает линукс и xen, grub+uefi+xen не работают вместе, etc), kvm — родное, нативное в ядре, qemu — всего лишь userspace приложение без каких-либо выкрутасов.
На выходе — на последнем ops-summit на openstack summit 2016-1, на сессии, посвящённой mitaka, в зале не было НИ ОДНОГО человека, кто бы использовал xen как гипервизор. Есть rackspace, который держит клиентские legacy-виртуалки на xenserver'е — но за кулисами их ребята страшно ругались на него, и используют они его не как «систему управления виртуальными машинами», а как прослойку между гипервизором и openstack'ом. Никаких пулов, никаких адских xapi на мастере, отжирающих 300% CPU и тупящих непонятно на чём.
xen всегда имел проблемы с opensource'ом. Адекватной системы сборки не было, и если сам гипервизор был прост и понятен, но его userspace — ужасен и местами имел дыры в проприетарные системы (цитрикса). Самому цитриксу оно особо не нужно и его интересуют маржинальные продукты (читай, виртуализация десктопов), а серверный рынок — только как часть портфолио и только в контексте энтерпайза.Cloud4Y
04.05.2016 17:35По Xen согласны, сейчас если планировать с нуля то KVM однозначьно лучше по всем параметрам.
По паралельной обработке при большом кол-ве машин и интенсивном IO, Xen показывал себя лучше. По крайней мере это наш опыт.
Мы ловили много проблем с Xen за конкуренцию по IO, есть к примеру сеть iSCSI и приходит большой трафик по пакетем по сети Network LAN (iSCSI и Network физически разные адаптеры), очередь IO оказывалась очень сильно зависима и происходили проблемы c iSCSI.
В VMware таких проблем не происходит, по этому мы её применяем для коммерческой экспуатации, дороже но стабильнее.amarao
04.05.2016 20:41iscsi для линукса упирается в тормозной open-iscsi (инициатор). NFS должна дать лучшую производительность.
nitso
04.05.2016 17:46+1На "любительском" уровне (пока виртуализация не является источником дохода) XEN привлекает легкостью установки и поддержки. Установил из образа на голую машину, подцепился через XenCenter или другой xapi-клиент, и оно работает. Достаточно понятный GUI, все вопросы/проблемы легко гуглятся и решаются через консоль (xe).
Есть ли подобрное, относительно user-friendly, решение для KVM? Из разряда поставил-настроил-пользуешься через GUI.
moosy
04.05.2016 18:03+4Думаю что proxmox можно более-менее назвать таким решением. Для «любительского» уровня все достаточно user-friendly
AllexIn
04.05.2016 18:48+1На любительском уровне я поставил KVM с VGA passthrough и прочими плюшками за один вечер.
При том что до этого пользовался исключительно VBox под виндой и слабо представлял что и как делать.
vasilisc
05.05.2016 08:05+2Много лет уже используем ProxmoxVE — Debian (KVM) + веб-интерфейс. Если сделано общее хранилище, то есть Live Migration.
nitso
05.05.2016 15:14Большое спасибо всем оветившим, есть поле для исследования и, возможно, переезда.
magius
05.05.2016 13:58Xen — чужеродная среда с кучей проблем (nvidia не поддерживает линукс и xen, grub+uefi+xen не работают вместе, etc), kvm — родное, нативное в ядре, qemu — всего лишь userspace приложение без каких-либо выкрутасов.
это красиво звучит, но так ли это на самом деле
насколько мне известно qemu — не смотря на то что это «простое приложение» оно еще и достаточно тормознутое.
так что не факт что «чужеродная среда xen» это плохо.
соответственно если у вас «среднестатистическая» виртуалка с LAMP, то XEN будет выглядеть более привлекательно из-за более быстрой обработки IO.
более того давайте вспомним что у Xen есть PVH режим
который исключает все недостатки чистого HVM от XEN
И если уж мы говорим о «серверных гипервизорах» — то корректнее сравнивать их с сильных сторон,
а не просто говорить о недостатках.
rader90
04.05.2016 21:08+1Что оптимально использовать KVM или Xen для гостевой машины windows server 2012?
RicoX
04.05.2016 22:25Я бы взял KVM, на этапе установки подпихнул VirtIO драйвера и использовал дисковую и сетевую подсистемы через них, так самая приятная производительность выходила лично у меня.
rader90
05.05.2016 08:44Даже если поставить терминальный сервер на винде, и пару linux/unix систем? Можете объяснить, чем лучше более детально. Щас выбор между ними, что будет эффективнее, сложность настройки не важна. Да и как автор говорил все отзывы годов 2009-2012 часто попадаются.
RicoX
05.05.2016 09:23Если сравнивать с XEN, то в KVM у меня получалась лучше производительность, на дисковой разница была почти в 20% на остальном 3-5%. Для linux я бы вообще советовал использовать не полную виртуализацию, а контейнеры, оверхеда почти нет, дисковая работает со скоростью хостовой системы, бэкапы меньше весят, проще управлять занятым местом, для unix. смотря какой unix, если та же FreeBSD неплохо себя чувствует на KVM, то вот солярис работал лучше в XEN, правда крайний раз я его тестировал года 4 назад, может теперь и в KVM работать будет неплохо. Основная проблема XEN — это хренова абстракция dom0, выше было расписано почему это плохо. По сложности установки, ну как по мне монопенисуально, что на то что на то доков валом, хотите все из коробки с KVM — ставьте готовую сборку типа ProxMox или Virtuozzo7 и сразу начинайте делать виртуалки, о всей внутренней кухне уже позаботились авторы сборок.
Lelik13a
05.05.2016 05:06Я правильно понял, что тестировали только потерю производительности для одного гостя?
В тестах вертуализации хотелось бы сравнить работу нескольких конкурирующих гостей на одном железе.
Loxmatiymamont
05.05.2016 09:34-1А Hyper-v за что проигнорировали?
RicoX
05.05.2016 10:29Предположу потому, что windows в качестве гипервизора у хостера можно встретить так же часто, как FreeBSD на рабочем компьютере главбуха.
ZlobniyShurik
Все отлично, но оригинальная статья, похоже, 2014 года (ну, если верить ссылке на гуглодокс). С тех пор многое могло и поменяться (врядли сильно, но...).