Комментарии 38
Все отлично, но оригинальная статья, похоже, 2014 года (ну, если верить ссылке на гуглодокс). С тех пор многое могло и поменяться (врядли сильно, но...).
Невооружённым глазом заметно, что Xen на данном наборе тестов проиграл во всех, поэтому с выводом малость промахнулись.
Да, я тоже не совсем понял. Здесь сказано, что Xen медленнее:
но в заключение он почему-то становится быстрее
В трех тестах Xen отличался на 2,5% от скорости «железа», в остальных тестах он оказался еще медленнее.
но в заключение он почему-то становится быстрее
Xen оказался на 2,5% медленнее всего в трех тестах из десяти, а в остальных был выше на 5–7%.
Перевод неправильный.
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%.
Как же я отстал от жизни, все еще закладывал 30% потерь ресурсов при использовании виртуализации, а тут получается что потери на уровне погрешности…
А вы можете методику тестов описать? Вы пишете что тестировали голое железо, т.е. без ОС, как можно прогнать тесты openssl или 7-zip без использования гостевой ОС?
А вы можете методику тестов описать? Вы пишете что тестировали голое железо, т.е. без ОС, как можно прогнать тесты openssl или 7-zip без использования гостевой ОС?
А вы можете методику тестов описать?
Вот эти тесты.
Тестировали на PVHVM (Xen 4.3)
Под Bare Metal здесь имеется в виду одноимённый тип гипервизора.
То есть Xen работал не в родном для себя режиме полной паравиртуализации (PV), а был притянут за уши к общему с KVM знаменателю — виртуализация аппаратуры с частично паравиртуальными драйверами (HVM+pv)? Такой изврат ещё можно понять, если хочется запустить Windows или FreeBSD x86-64, но не когда дело касается Linux. А если Fedora из коробки не хочет дружить с Xen — так не надо давиться кактусом, когда есть CentOS.
Чтобы довести идею до полного абсурда, авторам следовало бы запустить QEMU-KVM ещё и без KVM вовсе, а ещё лучше — в режиме эмуляции SPARC, скажем. Тогда можно было бы выдать шокирующий пост про то, как виртуализация съедает 90 % быстродействия CPU.
Чтобы довести идею до полного абсурда, авторам следовало бы запустить QEMU-KVM ещё и без KVM вовсе, а ещё лучше — в режиме эмуляции SPARC, скажем. Тогда можно было бы выдать шокирующий пост про то, как виртуализация съедает 90 % быстродействия CPU.
Ага. Да еще VGA passthrough появился.
Спасибо за статью, интересно было взглянуть на результаты. (Я последнее время слежу за открытыми гипервизорами — по моим постам это заметно ;-) ). Единственное замечание — в 2007 Citrix выкупила не исходный код Xen, а компанию XenSource, которая была основана разработчиками Xen и занималась коммерческим развитием этого открытого проекта.
В состав комплекса включено основное ядро — 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 и т.п.
Ах да, совсем забыл сказать по поводу того, что PostMark работает под гипервизором быстрее, чем на голом железе — этого не может быть (с), ребята явно забыли выключить где-то кэш.
В домене работает только гостевая ОС, а эмуляция оборудования средствами qemu-dm происходит в юзерспейсе хоста. Есть, правда еще и stub domains, но их вроде до продакшена не допилили.
Если бы так всё было просто. Проблема в том, что xen — «над» операционной системой dom0. Таким образом, получается следующее:
драйвер в domU. Протокол для работы оборудования с dom0, реализованный как драйвер в dom0 плюс userspace демон. Само оборудование — драйвер в dom0, который создаёт «реверсное» устройство (для сети — патч-интерфейс, для блочных устройств — идиотское «реверсное» блочное устройство, куда надо писать то, что гость читает и читать то, что тот пишет), плюс userspace, который его обслуживает в dom0. Оно шаткое и уродливое. Жить с этим можно, но не нужно.
«Сейчас паравиртуализация работает медленнее аппаратной виртуализации, потому что управление памятью происходит без аппаратной поддержки со стороны 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.
Это потому что сама идея паравиртуализации в принципе ущербна, или всё же потому, что в 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.
Xen как серверный гипервизор — мёртв. Остаётся как карманная игрушка цитрикса и всякая экзотика, типа виртуальных десктопов, сотовых телефонов и т.д. Плюс легаси инсталляции. Плюс 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 — ужасен и местами имел дыры в проприетарные системы (цитрикса). Самому цитриксу оно особо не нужно и его интересуют маржинальные продукты (читай, виртуализация десктопов), а серверный рынок — только как часть портфолио и только в контексте энтерпайза.
Поясняю:
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 — ужасен и местами имел дыры в проприетарные системы (цитрикса). Самому цитриксу оно особо не нужно и его интересуют маржинальные продукты (читай, виртуализация десктопов), а серверный рынок — только как часть портфолио и только в контексте энтерпайза.
По Xen согласны, сейчас если планировать с нуля то KVM однозначьно лучше по всем параметрам.
По паралельной обработке при большом кол-ве машин и интенсивном IO, Xen показывал себя лучше. По крайней мере это наш опыт.
Мы ловили много проблем с Xen за конкуренцию по IO, есть к примеру сеть iSCSI и приходит большой трафик по пакетем по сети Network LAN (iSCSI и Network физически разные адаптеры), очередь IO оказывалась очень сильно зависима и происходили проблемы c iSCSI.
В VMware таких проблем не происходит, по этому мы её применяем для коммерческой экспуатации, дороже но стабильнее.
По паралельной обработке при большом кол-ве машин и интенсивном IO, Xen показывал себя лучше. По крайней мере это наш опыт.
Мы ловили много проблем с Xen за конкуренцию по IO, есть к примеру сеть iSCSI и приходит большой трафик по пакетем по сети Network LAN (iSCSI и Network физически разные адаптеры), очередь IO оказывалась очень сильно зависима и происходили проблемы c iSCSI.
В VMware таких проблем не происходит, по этому мы её применяем для коммерческой экспуатации, дороже но стабильнее.
На "любительском" уровне (пока виртуализация не является источником дохода) XEN привлекает легкостью установки и поддержки. Установил из образа на голую машину, подцепился через XenCenter или другой xapi-клиент, и оно работает. Достаточно понятный GUI, все вопросы/проблемы легко гуглятся и решаются через консоль (xe).
Есть ли подобрное, относительно user-friendly, решение для KVM? Из разряда поставил-настроил-пользуешься через GUI.
Поправка: речь о XenServer
Думаю что proxmox можно более-менее назвать таким решением. Для «любительского» уровня все достаточно user-friendly
На любительском уровне я поставил KVM с VGA passthrough и прочими плюшками за один вечер.
При том что до этого пользовался исключительно VBox под виндой и слабо представлял что и как делать.
При том что до этого пользовался исключительно VBox под виндой и слабо представлял что и как делать.
virt-manager вроде, всё то же умеет.
Много лет уже используем ProxmoxVE — Debian (KVM) + веб-интерфейс. Если сделано общее хранилище, то есть Live Migration.
Большое спасибо всем оветившим, есть поле для исследования и, возможно, переезда.
У Ubuntu в репе есть пакеты ubuntu-virt-server и ubuntu-virt-mgmt. Если ставите средства управления на Kubuntu, то добавьте ещё пакет ksshaskpass, но вообще проще использовать ssh-авторизацию по ключам.
С kvm+libvirt все сводится вообще к 2-3 шагам.
На сервере:
yum install qemu-kvm libvirt
reboot
на локальной машине:
yum install virt-manager
GUI готов, можно запускать виртуалки.
На сервере:
yum install qemu-kvm libvirt
reboot
на локальной машине:
yum install virt-manager
GUI готов, можно запускать виртуалки.
Xen — чужеродная среда с кучей проблем (nvidia не поддерживает линукс и xen, grub+uefi+xen не работают вместе, etc), kvm — родное, нативное в ядре, qemu — всего лишь userspace приложение без каких-либо выкрутасов.
это красиво звучит, но так ли это на самом деле
насколько мне известно qemu — не смотря на то что это «простое приложение» оно еще и достаточно тормознутое.
так что не факт что «чужеродная среда xen» это плохо.
соответственно если у вас «среднестатистическая» виртуалка с LAMP, то XEN будет выглядеть более привлекательно из-за более быстрой обработки IO.
более того давайте вспомним что у Xen есть PVH режим
который исключает все недостатки чистого HVM от XEN
И если уж мы говорим о «серверных гипервизорах» — то корректнее сравнивать их с сильных сторон,
а не просто говорить о недостатках.
это красиво звучит, но так ли это на самом деле
насколько мне известно qemu — не смотря на то что это «простое приложение» оно еще и достаточно тормознутое.
так что не факт что «чужеродная среда xen» это плохо.
соответственно если у вас «среднестатистическая» виртуалка с LAMP, то XEN будет выглядеть более привлекательно из-за более быстрой обработки IO.
более того давайте вспомним что у Xen есть PVH режим
который исключает все недостатки чистого HVM от XEN
И если уж мы говорим о «серверных гипервизорах» — то корректнее сравнивать их с сильных сторон,
а не просто говорить о недостатках.
Что оптимально использовать KVM или Xen для гостевой машины windows server 2012?
Я бы взял KVM, на этапе установки подпихнул VirtIO драйвера и использовал дисковую и сетевую подсистемы через них, так самая приятная производительность выходила лично у меня.
Даже если поставить терминальный сервер на винде, и пару linux/unix систем? Можете объяснить, чем лучше более детально. Щас выбор между ними, что будет эффективнее, сложность настройки не важна. Да и как автор говорил все отзывы годов 2009-2012 часто попадаются.
Если сравнивать с XEN, то в KVM у меня получалась лучше производительность, на дисковой разница была почти в 20% на остальном 3-5%. Для linux я бы вообще советовал использовать не полную виртуализацию, а контейнеры, оверхеда почти нет, дисковая работает со скоростью хостовой системы, бэкапы меньше весят, проще управлять занятым местом, для unix. смотря какой unix, если та же FreeBSD неплохо себя чувствует на KVM, то вот солярис работал лучше в XEN, правда крайний раз я его тестировал года 4 назад, может теперь и в KVM работать будет неплохо. Основная проблема XEN — это хренова абстракция dom0, выше было расписано почему это плохо. По сложности установки, ну как по мне монопенисуально, что на то что на то доков валом, хотите все из коробки с KVM — ставьте готовую сборку типа ProxMox или Virtuozzo7 и сразу начинайте делать виртуалки, о всей внутренней кухне уже позаботились авторы сборок.
Я правильно понял, что тестировали только потерю производительности для одного гостя?
В тестах вертуализации хотелось бы сравнить работу нескольких конкурирующих гостей на одном железе.
В тестах вертуализации хотелось бы сравнить работу нескольких конкурирующих гостей на одном железе.
А Hyper-v за что проигнорировали?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Показатели эффективности: KVM vs. Xen