2011 сравнение производительности xen kvm virtualbox
По какой-то непонятной для меня причине на Хабрахабре сложилось негативное отношение к технологии OpenVZ вообще, и к OpenVZ хостингу в частности. Этот пост попытка развенчать мифы, касающиеся OpenVZ хостинга, Хотя на мой взгляд, OpenVZ так же едва ли не лучшее решение для разделения моногенных (Linux-only сервисов) внутри предприятия на собственных серверах.
Я не являюсь заинтересованным лицом, пишу пост не от имени своего работодателя, а от самой себя.
Итак, тезис: бюджетные Linux VPS на OpenVZ, как правило, работают быстрее и стабильнее, чем бюджетные VPS, использующие гипервизоры. Дорогие VPS на гипервизорах, в «облаках» или с фиксированным тарифным планом, лучше, чем дорогие VPS на OpenVZ.
Так как топик опубликован не только в хабе Виртуализации, прошу не обижаться тех, кто администрирует фермы с большим количеством виртуальных машин и нод: я должна напомнить менее профессиональным читателям, что такое VPS
Так что такое VPS, и какие они бывают? VPS это Виртуальный Выделенный Сервер, который условно можно считать «настоящим» выделенным сервером, при этом администратор VPS имеет полный (в UNIX/Linux root) доступ к VPS-серверу, и может устанавливать любое программное обеспечение, совместимое с выбранной для VPS операционной системой, и используемой технологией виртуализации.
Синонимом термина VPS является VDS. На «буржуйском» VPS расшифровывается как Virtual Private Server, а VDS как Virtual Dedecated Server.
Слово VPS обозначает, скорее, не технологию, а услугу, предоставляемую хостинг-провайдером. При этом технологии для реализации услуги могут применятся принципиально различные.
Разделяют две группы технологий для реализации услуги VPS:
а) Виртуализацию
б) Контейнеры
При виртуализации для клиента создается полноценная виртуальная машина, со своим ядром, возможностью использования VPS на базе большого количества разных операционных систем, при этом изоляция на базе современной реализации технологии виртуализации, на гипервизорах, максимальна.
Наиболее популярные гипервизоры: VmWare ESXi(за пределами мира хостинга лидирующее решение для виртуализации), Xen, KVM, Hyper-V.
Контейнеры не создают, в отличае от виртуализации, для каждого VPS свою полноценную операционную систему, а создают на одном ядре большое количество изолированных окружений(name spaces), что позволяет не тратить хостеру ресурсы сервера впустую, а отдать их непосредственно VPS. Так же плюс контейнеров
заключается в том, что память и другие ресурсы, такие как дисковое пространство, не выделяются гостевой системе целиком (например, размер lun, отданного в распоряжение виртуальной машине в качестве диска, уже нельзя уменьшить).
Наиболее популярными(а так же технологически лидирующими, и лидирующеми по количеству инсталляций) технологиями контейнерных VPS являются Parallels Virtuozzo Containers и OpenVZ.
Главные недостатки заключаются в том, что на базе контейнеров можно предоставлять VPS только на той же системе, что и хост-система (для OpenVZ и Virtuozzo это Linux, в принципе, и так самая популярная ОС для VPS, основанных на любых
технологиях).
В целом, на базе гипервизоров можно построить услугу VPS, более качественную, стабильную и мощную, чем аренду выделенного сервера:
Мощная хост-система с топовыми CPU, поделенная с помощью гипервизора на десяток-полтора частей, с внешними дисками на быстрой дисковой полочке с десятками шпинделей, и High Available решением, перезапускающим VPS на новой ноде в
случае аппаратного сбоя хост-системы, заведомо стабильнее, производительнее, маштабируемее (всегда можно перейти на следующий тарифный план, или заказать новый VPS, который Вам развернут за минуты из шаблона) чем, возможно, любой самый дорогой физический сервер, который можно взять в аренду: крупные операторы вообще предпочитают сдавать в аренду «серверы», собирая их из десктопных комплектующих, даже без поддержки ECC-памяти, и продавая не очень разбирающимся людям мегагерцы десктопных процессоров, таких как Corei7, при этом стабильность работы такого железа в режиме 7/24 это не их проблемы.
При этом, такие VPS часто закономерно, как лучшая услуга, оказываются _дороже_ чем выделенные серверы, да и затраты на оборудование адекватно организованный хостинг на гипервизорной технологии требует очень не маленькие, поэтому такие сервисы как Amazone EC2, или, например, VPS от Leaseweb на VmWare ESXi с дисками на SAN с raid60 и стоят недешево: хостер не может продавать услугу ниже ее себестоимости.
К сожалению, среди пользователей услуги VPS господствует миф, который мы сейчас развенчаем:
«VPS на Xen лучше, чем VPS на OpenVZ/Virtuozzo»
На вопрос «чем лучше» обычно отвечают, что «хостер на OVZ оверселлит, и врет, и продает мои, честно купленные, потребителем услуги ресурсы другим клиентам, поэтому все тормозит! На Xen нельзя оверселлить!»
Обычно люди не понимают, что возможность обмануть клиента по сотне пунктов у хостера есть всегда, и технология тут совсем ни при чем…
Этот миф исскуственно подогревается некоторыми, вероятно, не очень добросовестными компаниями, предоставляющими дешевый Xen-хостинг.
Дело в том, что качественных VPS на гипервизорах, за те же деньги, что продаются VPS на OpenVZ, получить невозможно.
При эксплуатации хостинговых серверов часто возникает потребность, например, выключить физическую машину для профилактики, перевозки в другой дата-центр, апгрейда, что бы предоставить больше ресурсов клиентам на новых тарифах,
так как вычислтительная техника продолжает развиваться по закону Мура, удваивая вычислительную мощь каждые два года), да и в случае, если сервер ведет себя нестабильно, неплохо бы перенести VPS клиентов на новый сервер. Еще чаще возникает необходимость балансировки нагрузки: на одной ноде VPS продали слишком много, а на другой слишком мало. дешевые Xen хостеры вынуждены или выключать часть клиентов, и перевозить их offline на недогруженный сервер, или не обращать внимание на жалобы клиентов на перегруженном сервере : авось кто-то уйдет, и тормозить у остальных VPS перестанут!
Так вот, для того, что бы не выключать для клиентов сервис на несколько часов, нужна технология живой миграции, а она не совместима с дешевыми Xen VPS, так как требует от хостера инвестиций в SAN и сеть построения данных, и тогда уже нет смысла и закупать дешевые серверы: VPS на гипервизорах, или как сейчас часто говорят, в «облаках» это более качественная и «продвинутая» услуга, чем обычный сервер, и совсем не конкурент «контейнерным» VPS, прежде всего по цене.
OpenVZ и Virtuozzo контейнеры позволяют прозрачно для клиентов, online, переносить VPS с физического сервера на физический сервер без дорогостоящих инвестиций в сеть хранения данных.
Что касается «оверселлинга», это миф, так как наоборот, возможность оверселлинга для клиента хостера благо, так как ни один VPS, если он работает стабильно, не находится 100% времени возле пределов своего тарифного плана (иначе сервисы на VPS будут работать нестабильно и медленно, и тарифный план был выбран неверно).
При использовании обычных, выделенных, невиртуализированных серверов (colocation или dedicated) большая часть ресурсов сервера так же простаивает, и клиент платит за эти холостые такты.
Если хостер Вам нагло не врет, и ресурсов у физического сервера достаточно, возможность без ухудшения качества сервиса для конечного клиента передать неиспользуемые им ресурсы другому VPS, это благо и для хостера и для клиента, так как хостер повысит свою рентабельность, и может, например, или закупить более мощные серверы, что бы Ваши номинальные мегагерцы значили больше, или снизить цены, или повысить зарплаты саппорту.
При десятках VPS на физический сервер вероятность того, что всем клиентам одновременно потребуются их ресурсы, стремится к нулю. Зато она часто существенна при количестве VPS до десяти-пятнадцати на сервер, что часто встречается у Xen-хостеров, таким образом оверселлинг по CPU для «честного» Xen хостера гораздо более вероятен, чем оверселлинг по памяти для хостера OpenVZ
Так же в адрес Xen часто раздается критика по поводу производительности дисковой подсистемы, причем даже со стороны разработчиков других гипервизоров, того же KVM, да и Xen-хостеры часто лукавят: оверселлинг по CPU в Xen так же возможен.
Кроме того, VPS на Xen, KVM, Hyper-V с локальными дисками, без SAN, всегда катастрофически медленнее VPS на OpenVZ с локальными дисками из-за технологии vzswap.
Я бы сказала, что vzswap это такая убер фича OpenVZ VPS, которая, правда, включена не у всех OVZ хостеров.
Клиент, купивший VPS на гипервизоре, делает у себя swap файл. Когда его VPS «ложится» от, например, мощного DDoS, его приложения уходят в swap, от интенсивного ввода-вывода страдают соседи по физическому серверу. Очень тяжело помешать Вашему соседу по физической машине создать такой файл.
Напомню, если кто-то не знает, или забыл, виртуальную память можно представить как RAM(планки памяти DDR/DIMM/SIMM на x86/x86_64 компьютерах) + swap (файл или раздел подкачки).
В технологии OpenVZ свапинг осуществляется централизованно ядром, клиенту выделяется виртуальная память в качестве «RAM» и… виртуальная память в качестве «swap». Память vzswap тоже виртуальна! Только исскуственно замедленна, и обычно находится не в физическом swap, а в физическом RAM. Когда VPS начинают DDoS'ить, и она уходит в swap от десятков-сотен процессов апача, или сотен тысяч sql-запросов, VPS естественным образом замедляется, так как vzswap медленная память! Но диск физического сервера при этом не используется, так как ядро будет сбрасывать в настоящий swap только те данные, которые долго не использовались, что очень радикально скажется на производительности ввода-вывода для всех VPS.
В заключение хотелось бы напомнить о парадоксе заключенных из Теории Игр, текст из википедии:
Двое преступников, А и Б, попались примерно в одно и то же время на сходных преступлениях. Есть основания полагать, что они действовали по сговору, и полиция, изолировав их друг от друга, предлагает им одну и ту же сделку: если один свидетельствует против другого, а тот хранит молчание, то первый освобождается за помощь следствию, а второй получает максимальный срок лишения свободы (10 лет). Если оба молчат, их деяние проходит по более лёгкой статье, и каждый из них приговаривается к 0,5 года. Если оба свидетельствуют против друг друга, они получают минимальный срок (по 2 года). Каждый заключённый выбирает, молчать или свидетельствовать против другого. Однако ни один из них не знает точно, что сделает другой. Что произойдёт?
Ненависть к оверселлингу, и негатив к желанию хостера продавать другим клиентам те ресурсы, которые Вы все равно не используете, при том, что по теории вероятности, когда они Вам понадобятся, они Вам все равно практически всегда достанутся, является, на мой взгляд, самым худшим вариантом игры «Парадокс заключенных»: мешая хостеру заработать больше денег, вы мешаете прежде всего себе, так как и хостеру выгодно, что бы вы зарабатывали и оплачивали услуги, и вам выгодно, что бы хостинг был рентабелен, и у него было больше денег на оборудование, зарплату техподдержке, итд.
Тут некоторые Xen-хостеры, нападая на OpenVZ, часто используют низменные наклонности человеческой натуры, желание сыграть эгоистично в игре «парадокс заключенных», а так же врут, лукаво умалчивая про то, что они оверселлят процессор: у них на одном ядре CPU может быть несколько VPS, которые будут друг другу мешать.
Резюмируя, на сегодня лучшим выбором бюджетного VPS является только OpenVZ/Virtuozzo, а «гипервизорные» и «облачные» VPS, уже теснят услугу аренды физических выделенных серверов: если Вам нужна гибкость и стабильность услуги, и под проект есть бюджет, о таких VPS стоит задуматься уже сейчас.
UPDATE Судя по комментариям, и тому негативу, что мне написали в личке, не все поняли, что этот топик не против Xen, Kvm, VmWare и др. гипервизоров в хостинге, он наоборот за них, когда хостинг использует сеть SAN или хотя бы DAS, топик немножко против дешевых Xen хостеров, и в первую очередь, топик написан за OpenVZ
Производительность современных компьютеров давно уже превосходит стандартные потребности большинства организаций и отдельных юзеров. И все чаще вместо нескольких серверов место в стойке занимает один единственный, который затем уже «нарезается» на несколько машин. С выбором железа обычно проблем нет, а вот систему виртуализации подобрать сложнее.
VMware ESXi
Все, кто работал с виртуальными машинами с начала века, хорошо знает продукты VMware, пользовавшиеся популярностью благодаря своим функциональным возможностям и производительности.
Да и сегодня на десктопах нередко можно найти VMware Workstation и VMware Player. Последний появился как ответ MS Virtual PC и является бесплатной версией Workstation. Работает он из-под установленной ОС, то есть к промышленной среде не совсем подходит. Для установки на «голое железо» предлагается VMware ESXi – самостоятельный продукт, являющийся основой для установки гостевых ОС, а совместно с VMware vSphere — средством для построения виртуальной инфраструктуры и управления виртуальными ресурсами (подробнее в статье «Виртуальная сфера», см. ][ 08.2010). По сути, ESXi — это сильно урезанная версия Linux, содержащая гипервизор (VMkernel) и консоли управления: vCLI (vSphere CLI), PowerCLI (PowerShell интерфейс к vCLI), SSH и DCUI (Direct Console User Interface).
Ранее ESXi считался «младшим братом» в линейке продуктов VMware, ведь он представляет собой бесплатный и урезанный вариант ESX. Но время ESX прошло, следующие версии VMware VSphere будут включать поддержку исключительно ESXi (предложено также его альтернативное название — VMware vSphere Hypervisor), а все преимущества ESX перед ESXi сошли на нет. Так что разработчики рекомендуют переходить на ESXi.
Главное отличие ESXi от ESX заключается в архитектуре. Основой ESX служит полноценная версия Linux, на которую можно устанавливать при необходимости свои приложения. Агенты VMware работают через COS (Console OS), то есть через дополнительный уровень. В итоге мы имеем больший размер дистрибутива: ~2 Гб по сравнению с 350 Мб у ESXi (на хард ставится всего 70Мб).
В ESXi агенты работают прямо в VMkernel, при необходимости модули сторонних разработчиков (мониторинг, драйвера) также выводятся на гипервизор. Уменьшение слоев означает большую надежность и безопасность, меньше возможности для атак.
Продукт от VMware отличает поддержка большого количества гостевых ОС. Здесь полный фарш — Windows, Linux, Solaris, FreeBSD, Netware и многие другие, весь список доступен на сайте.
Функциональность последних релизов ESXi уже «подтянули» под возможности ESX — появилась интеграция с Active Directory (любая учетная запись будет проверяться в каталоге), функции расширенного управления памятью (неиспользованные ресурсы освобождаются), совместная работа с системами хранения данных VMware vStorage VMFS/Storage VMotion и SAN, настройка приоритетов трафика, технология безопасности VMsafe Security API. Гибкое распределение ресурсов позволяет «на горячую» добавить CPU, ОЗУ, жесткий диск (в том числе и изменить размер текущего без перезагрузки).
Установка дистрибутива на голое железо очень проста (стандартный вариант с привода или через PXE), к тому же начиная с версии 4.1 поддерживаются сценарии, позволяющие автоматизировать процесс инсталляции ПО, настройку сети и подключения к vCenter Server. Через VSphere API интегрировано управление резервного копирования ESXi.
Гипервизор KVM
Да простят нас гуру виртуализации, но для начала мы напомним читателям, что такое гипервизор и для чего он нужен. Для выполнения разных по смыслу задач (разработки программного обеспечения, хостинга ) проще всего использовать виртуальные машины: они позволят иметь несколько разных ОС с соответствующей программной средой. Для простоты работы с виртуальными машинами применяются гипервизоры — программные средства, позволяющие быстро развертывать, останавливать и запускать ВМ. KVM является одним из наиболее широко распространенных гипервизоров.
KVM — это ПО, позволяющее организовывать виртуализацию на основе ПК под управлением ОС Linux и похожих. С недавнего времени KVM считается составляющей и развивается параллельно ему. Этот гипервизор может использоваться только в системах, где виртуализация поддерживается аппаратно — с помощью процессоров Intel и AMD.
В процессе работы KVM осуществляет доступ к ядру напрямую посредством модуля ( или ). К тому же, в состав комплекса включено основное ядро — kvm.ko и элементы UI, включая широко распространенный QEMU. KVM дает возможность напрямую работать с файлами ВМ и дисковыми образами. Каждая виртуальная машина обеспечивается своим изолированным пространством.
Заключение
Ну вот, собственно, мы имеем Windows, запущенную внутри Linux. Конечно, рассматривать KVM для локальной установки, где сильны позиции у VirtualBox и VMware Workstation, не стоит, но при наличии свободных ресурсов на VDS можно быстро развернуть еще одну машину. Скорость, конечно, будет невелика, но для небольших тестов вполне достаточная.
Сеть в KVM
Настройка сети — самый важный момент при работе с KVM. По умолчанию используется Usermode или default, когда базовая система работает как маршрутизатор между внешней и гостевой сетью. Гостевая ОС может получать доступ к внешним сетевым сервисам, но не видна из сети. IP выбирается автоматически при помощи DHCP из диапазона 192.168.122.0/24 , интерфейс основной ОС всегда имеет IP 192.168.122.1 . Для доступа к сервисам нужно самостоятельно настроить маршрутизацию. После установки libvirtd должен создать ряд NAT-правил iptables .
Правила iptables после установки KVM
Второй вариант — Bridged, когда интерфейс гостевой ОС привязывается к физическому интерфейсу и VM доступна извне без допнастроек. Этот вариант чуть сложнее в настройках, так как из-за перестроек можно потерять SSH-подключение. Поэтому при отсутствии локальной консоли (Java/веб-аплета у провайдера) пользоваться им нужно только после тщательного тестирования, и мы его рассматривать не будем.
В первом варианте удобнее настроить KVM так, чтобы она назначала гостевой системе один и тот же IP-адрес. Это можно сделать прямо в конфигурационном файле /etc/libvirt/qemu/networks/default.xml или вызвав
Далее добавляем параметр host в секции dhcp :
Редактируем сетевые настройки для виртуального хоста
И так для каждого узла. После чего перезапускаем сеть.
Теперь можем указать маршрут к сервису в основной системе:
По умолчанию VNC в хостовой машине слушает только локальный порт. Поэтому при подключении с помощью VNC-клиента нужно обязательно пробрасывать порты.
Изменить эту ситуацию можно несколькими способами: добавив параметр --vnc,listen=0.0.0.0 и при необходимости указав другой порт --vncport 5901 .
Аналогичные настройки есть в сетевых установках хоста.
Чтобы не менять установки для каждой VM, проще изменить это поведение глобально:
Вместо заключения
В нашем тестировании 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 и занималась коммерческим развитием этого открытого проекта. Пруф.
Интерес пользователей к виртуализации в последнее время стал пропадать. С одной стороны, есть понятные десктопные решения под любую ось. С другой — стоимость VDS не так уж и высока, а сервер доступен всем, можно демонстрировать разработки с любой точки. Но если с Linux все более-менее ясно и выбор есть, то Windows-хостинги предлагают далеко не все, их стоимость высока (примерно в два раза дороже) и брать их, когда такая система нужна редко, не имеет смысла. Вот здесь нас может выручить знание KVM.
Бесплатный XenServer
XenServer (текущая версия 5.6.1) в чем-то похож на VMware ESXi. Предоставляется он бесплатно, и его можно использовать без ограничений. Но для централизованного управления фермой серверов предлагается XenCenter, продаваемый под собственнической лицензией Citrix. Функционально XenServer — очень мощный инструмент.
Админ получает неограниченное количество серверов и виртуальных машин; Live Motion; непрерывное обслуживание при условии, что ресурсы нескольких серверов объединены в пул; контроль доступа на основе ролей (RBAC) и интеграцию с Active Directory; динамическое управление памятью, позволяющее добавить RAM в VM без перезагрузки. Рабочая нагрузка динамически перераспределяется не только между виртуальными, но и между физическими серверами, что существенно упрощает управление. Спроектирован с учетом требований по предоставлению высокого уровня доступности системы (High Availability). Рабочую ОС, установленную на любом физическом сервере, можно легко конвертировать в виртуальную систему.
Умеет работать с основными системами хранения данных (локальный диск, NAS, SAN и так далее). Экспериментально может работать с образами дисков в форматах VMWare VMDK, MS VHD, VDI, WIM.
Официально в качестве гостевых систем поддерживаются все версии Windows, начиная от Win2k SP4, Linux (SLES, RHEL/CentOS, Oracle EL, Solaris, Debian). Гостевая система поддерживает до 64 логических процессоров, 256 Гб оперативной памяти и 16 сетевых адаптеров на хост. Хотя характеристики виртуальной машины будут зависеть от используемой гостевой ОС, VM не имеет ограничений на количество используемой оперативной памяти: все, что сможет выдать сервер, будет доступно.
Виртуализация — это не только инструмент администрирования и поддержки хостинга. Все чаще она применяется и для решения обыденных задач. Но в то же время системы виртуализации становятся достаточно многогранными и сложными. Сегодня мы расскажем о четырех основных системах, каждая из которых нашла применение в какой-то области.
Аппаратная виртуализация в настоящее время перестала быть недостижимой роскошью, доступной только на мейнфреймах, — начиная с 2006 года большинство процессоров средней ценовой категории ее поддерживает. Тем не менее помимо аппаратной поддержки должна быть поддержка программная, которая и обеспечивается гипервизорами. На данный момент существует два основных типа гипервизоров. Они так и именуются: «гипервизор типа 1» и «гипервизор типа 2».
Грань между этими двумя типами достаточно тонка и постепенно стирается. В частности, иногда выделяют третий тип — 1+, который подразумевает сервисную ОС — прослойку между гостевыми ОС и собственно гипервизором, в которой можно эти гостевые ОС запускать и останавливать. В статье будут рассмотрены гипервизоры типа 1 и 1+ — Xen и KVM.
Помимо гипервизоров, существует еще один слой виртуализации — «контейнеры», или, иначе, виртуализация на уровне ОС, хотя виртуализацией это можно назвать лишь с натяжкой. В отличие от «настоящей» виртуализации, контейнеры создают своего рода песочницу со своим пространством имен. Соответственно, накладные расходы на эмуляцию железа попросту отсутствуют. Я рассмотрю две подобные технологии — OpenVZ и LXC.
В Xen 4.4 появился новый режим, объединяющий аппаратную и паравиртуализацию, — то есть прослойка эмулируемого железа отсутствует как таковая, в то же время управление памятью и привилегированные инструкции выполняются в самом ядре гостевой ОС. Режим этот сейчас еще недостаточно отработан, некоторые функции не оттестированы (миграция, проброс оборудования), некоторые и вовсе отсутствуют — в частности, поддержка AMD. Так что если у тебя именно этот процессор — попробовать этот режим пока не получится.
Архитектура Xen
Другие статьи в выпуске:
Перейдем к практической части и установим самую последнюю версию XEN. Для этого придется компилировать как Xen, так и ядро. Далее предполагается, что все нужные инструменты и библиотеки уже стоят на компьютере. Сперва соберем Xen:
Затем нужно добавить файл local64.conf в /etc/ld.so.conf.d/ следующего содержания (после чего запустить ldconfig):
Описывать сборку ядра я особого смысла не вижу, скажу лишь, что для гостевого домена PVH необходимо включить опцию Processor type and features -> Linux guest support -> Support for running as a PVH guest (NEW). Кроме того, в случае самосборного Xen надо добавить файловую систему xenfs в /etc/fstab — в современных дистрибутивах подобное делать, конечно, моветон, но так будет проще всего.
Перейдем к созданию гостевых виртуальных машин. Рассматривать будем стандартный сейчас стек утилит XL и сопутствующие конфиги. Файл xl.conf является глобальным файлом для dom0-хоста, и конфигурация по умолчанию, как правило, в изменении не нуждается. Поэтому перейду сразу к конфигурации гостевого домена (HVM). Первым делом нужно создать файл дискового устройства (хотя можно использовать и существующий раздел). Перейдя в каталог, где будут храниться образы, набираем:
Затем создаем конфиг /etc/xen/vm.cfg согласно документации. Запускаем и подключаемся к VNC-серверу, а в конце работы останавливаем:
Для того чтобы попробовать режим PVH, нужно добавить в конфиг /etc/xen/vm.cfg примерно следующие строчки:
Xen поддерживает множество интересных возможностей. Его используют многие облачные сервисы, такие как Amazon EC2, Rackspace Cloud и другие. Забегая вперед, скажу, что это самая многофункциональная система виртуализации, рассматриваемая в данной статье. Однако его функциональность порой избыточна и подходит не для всех.
ОС Plan9, запущенная в Xen
В отличие от Xen, KVM поддерживает только аппаратную виртуализацию и вообще выглядит проще. Поэтому можно часто встретить применение KVM обычными юниксовыми пользователями. KVM поддерживает проброс USB- и PCI-устройств, появившийся относительно недавно. Я не буду расписывать его архитектуру, а сразу перейду к созданию виртуальных машин. Установим нужные пакеты (после этого лучше перезагрузиться) и проверим работоспособность:
После выполнения последней команды должен появиться список запущенных виртуальных машин. Поскольку у нас никаких виртуальных машин еще нет, он будет пустым. Исправим эту ситуацию.
Архитектура KVM
Первым делом установим систему. Для этого необходимо создать образ диска:
Следом набираем команду, которая создает конфигурационный файл и запускает виртуальную машину, и подключаемся к ней:
Рассмотрим проброс USB-устройств. Для его осуществления нужно узнать VID и PID пробрасываемого устройства (с помощью команды lsusb) и добавить в конфиг виртуальной машины freebsd.xml следующие строки:
И перезапустить ее. Настройка проброса PCI-устройств для хостовой системы почти аналогична таковой для Xen. Только вместо установки параметра ядра xen-pciback.hide необходимо подключить пробрасываемое устройство к драйверу pci-stub. При этом помимо номера устройства надо знать еще и его VID/PID, который узнаем с помощью команды lcpci -n. Затем создаем конфиг /etc/modprobe.d/kvm.conf для модуля kvm:
Затем выполняем комбинацию команд rmmod kvm / modprobe kvm и добавляем соответствующие строчки в конфиг виртуальной машины freebsd.xml.
Стоит также упомянуть технологию SPICE. Она изначально разрабатывалась в качестве замены VNC для виртуальных машин и не требует наличия сети. В контексте проброса видеокарт SPICE примечательна тем, что позволяет на хостовой машине эмулировать видеокарту и пробрасывать реальную видеокарту на гостевую систему. Однако видеокарта, эмулируемая SPICE, целиком виртуальная и не имеет никакого устройства вывода, поэтому могут возникнуть некоторые сложности. Если же хочется «всего и сразу» — и проброс, и беспроблемное переключение, — можно попробовать пробрасывать не напрямую, а через драйвер VFIO.
Конфигурационный файл KVM (libvirt)
Существуют версии VirtIO-драйверов (для удобства работы с оборудованием и динамического выделения памяти) и для Windows.
Архитектура LXC
Об архитектуре LXC я писал не так давно, поэтому повторяться смысла нет. Лучше кратко рассказать о создании контейнера и некоторых полезных командах. Наиболее легким способом создать контейнер будет использование команды lxc-create:
Она разворачивает с помощью debootstrap минимальную версию Ubuntu — причем по умолчанию используется та версия дистрибутива, которая стоит на хосте.
Создание контейнера LXC
Для запуска же используем другую команду:
Эта команда запускает контейнер в фоновом режиме. Так что для подключения к нему уже нужно использовать команду lxc-console c тем же параметром. После этого можно работать с контейнером точно так же, как и со свежеустановленной системой. Для нормального завершения работы контейнера используй команду (на хосте) lxc-stop с параметром -s, для «жесткого» — ее же с параметром -k, а для уничтожения остановленного контейнера — lxc-destroy. Параметр имени контейнера обязателен для всех этих команд.
Теперь посмотрим конфиг данного контейнера, который находится в файле /var/lib/lxc/ubuntu-container/config. Он состоит из следующих частей: сеть, терминалы, безопасность (AppArmor) и устройства. Опишу парочку интересных опций, которые можно туда добавить:
Еще раз отмечу, что LXC — технология крайне молодая. Так, User namespaces в их «завершенном» виде появились только в ядре 3.8, да и то включены они не везде. Однако технология эта уже может применяться для нужд пользователя, например, в прошлом номере мы писали о ее использовании для безопасного веб-серфинга.
OpenVZ является наиболее старой технологией контейнерной виртуализации на архитектуре PC — его прародитель, Virtuozzo, возник в 2001-м, еще до того, как в Solaris появились зоны и контейнеры.
Стоит рассказать об одной особенности OpenVZ, которой нет в аналогах, — vSwap. Допустим, у контейнера задан лимит памяти и некое приложение превысило его. В обычном случае приложение прибивается ядром и все его данные теряются. vSwap представляет собой оперативную память, замедленную в несколько раз, и при его использовании приложение, если превысит лимит, не прибивается ядром, а терпеливо ждет, когда память освободится.
Основное понятие в OpenVZ — VE (Virtual Environments, виртуальные окружения), аналог контейнеров. Их поддержка обеспечивается патчсетом, добавляющим ко множеству сущностей (процессы, сокеты. ) поле VEID, которое идентифицирует контейнер. Стабильная версия данного патчсета на момент написания статьи поддерживала только ядро 2.6.32 (которое является основой для RHEL6-based-дистрибутивов). Это ограничивает его применение данными системами.
Архитектура OpenVZ
Конечно, пакет с OpenVZ-ядром есть и для Debian-based-систем, но RHEL-based предпочтительнее — относительно них и будем рассматривать. К счастью, компилировать ядро и утилиты не нужно — есть уже готовые пакеты. Установим их, добавив предварительно репозиторий, и перезагрузимся на свежеустановленное ядро:
Теперь сделаем контейнер с тем же самым CentOS. Для начала понадобится загрузить шаблон:
Затем введем собственно команды для его создания и запуска (адреса взяты с потолка):
Для входа в оболочку контейнера нужно набрать команду vzctl enter 12, а для выхода exit — разработчики решили не мудрить с сочетаниями клавиш. Остановка же и уничтожение контейнеров осуществляются с помощью команд vzctl stop и vzctl destroy соответственно — конечно, с указанием его идентификатора.
Создание и запуск контейнера OpenVZ
В целом OpenVZ более зрелое и отработанное решение, чем LXC. Кроме того, оно лучшее по производительности и масштабируемости в силу своей архитектуры. И действительно, огромное количество хостеров предоставляет VPS на его основе.
Установка KVM
Плюсы KVM в том, что она работает из коробки и что процессоры серверов хостеров однозначно поддерживают эту технологию. Поэтому вполне реально при наличии свободных ресурсов подгрузить в VDS еще одну виртуальную машину (или несколько). Конечно, под фактически двойной виртуализацией они будут работать не так быстро, как на железе, но если большая нагрузка не планируется, то этого вполне должно хватить. Более того, у некоторых хостингов есть rescue-инструменты, дающие возможность подмонтировать другую файловую систему (в hetzner это rescue/LARA ), подменить имеющуюся и даже установить свою ОС. При некотором умении можно по тарифам Linux абсолютно легально использовать Windows.
Наша задача — установить под KVM Win и настроить доступ. KVM работает со всеми версиями Win, включая и последние. Но Win капризней к ресурсам, поэтому тариф следует подбирать с учетом минимальных системных требований и накладных расходов на ОС и виртуализацию. На Digital Ocean, например, Win2012R2 при 4 Гбайт ОЗУ сильно тормозит, а если выделить 6+ Гбайт, то уже вполне нормальный отклик. В различных дистрибутивах и даже версиях процесс немного отличается, но в основном это касается названий пакетов. Мы будем использовать Ubuntu 16.06. Ставим пакеты.
Проверяем поддержку KVM.
Если такой ответ получен, значит, все нормально. Список поддерживаемых ОС и их правильное название можно получить при помощи osinfo-query .
Список поддерживаемых ОС и их названия
Конфигурационные файлы libvirt находятся в каталоге /etc/libvirt , журналы, в которых нужно искать ответы на проблемы, размещаются в /var/log/libvirt . В /var/lib/libvirt несколько каталогов: в boot система, если не указан путь, будет искать образ для установки гостевой системы, а в images размещать жесткие диски.
Управление виртуальными машинами из консоли производится при помощи утилиты virsh . Параметров много, их все можно узнать, введя:
Вначале просто стоит пройтись и познакомиться, чтобы понять суть. Список ОС пока пуст:
Проверяем, что сеть настроена. По умолчанию используется default (подробнее дальше по тексту).
Если в ответ получаем, что невозможно подключиться, проверяем права доступа на сокет и каталоги выше (в основном в этом проблема).
И перезагружаем модули:
Далее два варианта. Можно самостоятельно установить операционную систему или взять уже готовый образ с установленной ОС. Первый шаг в общем отличается тем, что нужно подготовить диск, запустить VM и установить ОС стандартным способом. Создадим диск размером 25 Гбайт.
Если в будущем нужно изменить размер диска, то используется команда resize:
Некоторые параметры очевидны, поэтому кратко:
- name — имя, по которому можно обращаться к VM;
- ram и vcpus — количество памяти и vCPU, выделяемых VM;
- disk — имя диска, формат и драйвер;
- cdrom — виртуальный CD-ROM, здесь указан ISO-образ, с которого будет загружаться система;
- network — сетевое подключение, тип и модель (можно использовать virtio, но бывают проблемы, потом можно сменить);
- os-type и os-variant — тип ОС.
Параметр --vnc имеет смысл только на сервере без GUI, при наличии интерфейса KVM сразу откроет окно через SDL. Также можно подключиться локально при помощи virsh:
Удаленно также можно зайти с использованием любого VNC-клиента, при необходимости используя port forwarding (см. ниже).
Коннектимся к Windows, запущенной под KVM
После установки ОС можно приступать к работе. Второй вариант позволяет использовать уже готовый диск с установленной ОС. Его можно скопировать с готовой системы, сконвертировать при помощи qemu-img convert, которая поддерживает форматы дисков практически всех систем виртуализации. Или взять с сайта проекта Cloudbase.
Запуск почти не отличается от предыдущего, убираем, если не нужен, cdrom и добавляем --import .
В дальнейшем можно управлять поведением VM при помощи virsh start|reboot|shutdown|suspend|resume|destroy|undefine|edit|autostart|info и так далее.
Настройки VM хранятся в отдельных XML-файлах в каталоге /etc/libvirt/qemu , имя соответствует параметру --name . Можно их просмотреть, отредактировать при необходимости, скопировать при помощи virsh. Например, нужно изменить настройки сетевого адаптера.
Скопируем настройки в файл.
Теперь в любом текстовом редакторе правим параметры второй машины, указываем новый виртуальный диск и можем запускать второй экземпляр. Для клонирования есть и другой вариант.
Настройки виртуальной машины
Гипервизор Xen
Изначально студентами Кембриджа был запущен проект, который в итоге стал коммерческой версией Xen. Первый релиз датирован 2003 годом, а в 2007 исходный код выкупила компания Citrix. Xen — это кроссплатформенный гипервизор с большим функционалом и огромными возможностями, что дает возможность применять его в корпоративной сфере. Xen поддерживает паравиртуализацию — особый режим ядра операционной системы, когда ядро настроено на одновременную работу с гипервизором.
В код Xen добавлен только необходимый комплект функций: управление виртуальной памятью и тактовой частотой процессора, работа с DMA, таймером реального времени и прерываниями. Остальной функционал вынесен в домены, то есть в работающие в это время виртуальные машины. Таким образом, Xen — самый легкий гипервизор.
Суть исследования
- Kernel: 3.14.8
- Для KVM: 1.6.2
- Для Xen: xen 4.3.2
Плюсы и минусы KVM
Технология предоставляет полную виртуализацию на аппаратном уровне. Поэтому, в отличие от популярных LXC и OpenVZ, KVM может запускать в принципе любую ОС, не только Linux (Windows, FreeBSD. ), и Linux, отличающийся от конфигурации основной системы. Если нужна виртуальная машина, не совпадающая параметрами с основным хостом, то выбора особо нет. Включение в ядро было большим прорывом. Теперь поддержка виртуализации в ОС не требовала установки гипервизора (как Xen) и могла быть реализована в любом дистрибутиве, включая настольный. Из коробки доступен VNC, дающий возможность управлять виртуальным сервером с момента загрузки (то есть когда еще не работает SSH), как будто из локальной консоли. Проект активно сотрудничает с другим подобным решением QEMU, задействованы некоторые утилиты и общий формат файла образа Qcow2.
Минусы, конечно, тоже есть. Куда же без них. Главный — процессор должен иметь аппаратную поддержку виртуализации Intel VT-x или AMD-V. Проверить их наличие можно вручную или при помощи утилит:
Также о поддержке технологий говорят флаги в CPU:
В зависимости от производителя процессора будет загружен свой модуль ядра (kvm-amd.ko либо kvm-intel.ko).
Проверяем поддержку KVM
Другие статьи в выпуске:
Накладные расходы чуть выше, чем при использовании LXC и OpenVZ. Причин тому две.
KVM-контейнер запускает свою копию ядра и окружения, и под них требуется память. LXC и OpenVZ же используют ядро и системные вызовы сервера. Поэтому при одинаковых характеристиках на хостинге у них совершенно разные возможности. При создании KVM-контейнера под него сразу резервируются все ресурсы согласно установкам. Это хорошо видно в htop. Стоит добавить ОЗУ в KVM, как сразу на это значение увеличивается объем занятой памяти. Выйти за лимиты VM не может, они устанавливаются жестко. В этом даже и плюс, можно сразу рассчитать будущую нагрузку на своем сервере, а ресурсы никто не позаимствует.
И VM работают относительно стабильно в плане производительности. В то время как при OpenVZ-виртуализации ресурсы выделяются динамически по мере надобности и каждый виртуальный сервер использует ровно столько ресурсов, сколько ему сейчас нужно. Незанятые ресурсы остаются свободными. Поэтому он и популярен у хостеров, ведь можно всегда напихать чуть больше VM, и именно поэтому виртуальные машины, созданные с запасом, могут работать то быстрее, то медленнее. Иногда оптимизация VM под OpenVZ — настоящая мука: непонятно, почему сервер стал работать по-другому — из-за новых настроек или внешних факторов.
Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сети контейнеров отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС. В том же OpenVZ это можно сделать на лету. Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту virsh, реализующую все необходимые функции. Но, поискав в Сети, можно найти несколько интерфейсов, хотя для индивидуального использования одной или нескольких VM их обычно ставить нет смысла. К тому же много open source проектов, активно развивавшихся во время большого интереса к виртуальным машинам, сегодня стали коммерческими, хотя некоторые по-прежнему предлагают обрезанную free-версию. В репозитории пакетов есть virt-manager, предлагающий графический интерфейс для управления KVM и другими типами VM, поддерживающими virtlib, как установленных локально, так и удаленно через SSH.
В качестве веб-интерфейсов можно порекомендовать старенький, но еще рабочий WebVirtMgr, бесплатный UVMM UCS Core Edition, openQRM Free Community Edition и другие. Кроме того, существуют специальные дистрибутивы вроде Proxmox VE, в котором все необходимые инструменты для создания и управления VM на базе KVM и LXC уже есть (правда, он подходит для bare metal установки, а не на удаленный VDS).
MS Hyper-V
Технология виртуализации от MS, финальная версия которой выпущена летом 2008 года. С выходом Win2k8R2 Hyper-V получил новые возможности — Live Migration, динамическая память, улучшены ряд инструментов и поддержка оборудования.
Кроме лицензии, между разными вариантами Hyper-V есть и другие отличия, но в бесплатном варианте доступно все необходимое для построения сервера виртуализации. Это поддержка технологии Live Migration, консолидация серверов и кластеризация узлов.
Сервер, на который устанавливается MS Hyper-V Server, может иметь ОЗУ в 1 Тб и до 8 CPU, чего вполне достаточно для задач небольшой и средней организации.
Официально поддерживаются 32- и 64-битные версии Windows XP SP3, Vista SP2/2k3 SP1/2k8 и Linux (SLES и RHEL). Но в интернете можно найти десяток руководств, в которых описана успешная эксплуатация других версий *nix — Ubuntu, FreeBSD и так далее. Для установки рекомендуется выбирать дистрибутивы Linux с ядром 2.6.32+, в котором добавлена поддержка Hyper-V (LinuxIC, распространяется MS под GPL). Правда, только гостевые Win2k8 могут быть сконфигурированы с 4 vCPU.
Для установки MS Hyper-V Server потребуется компьютер с x64 CPU, поддерживающий технологии Intel VT или AMD-V, и минимум 1 Гб RAM.
Для управления большими массивами виртуальных серверов MS предлагает отдельный продукт System Center Virtual Machine Manager 2008 (SCVMM 2008), имеющий инструменты для P2V(Physical to Virtual) и V2V-конвертирования серверов (с VMware). Опять же, в списке поддерживаемых для P2V только Win. Поэтому, чтобы перенести свой сервак, работающий на Linux, придется выбрать длинный путь: VMware vCenter Converter .. ESXi .. SCVMM .. Hyper-V. Не всегда данный процесс проходит гладко, особенно для дистрибутивов, не поддерживаемых официально.
Пояснения
из вас может начать возмущаться — мол, владелец Fedora 20, Red Hat, тратит значительное количество усилий на поддержку именно KVM. Уточним: Red Hat не делали значительных продвижений по части Xen долгие годы.
Кроме того, конкуренция между гипервизорами жестко контролируется и сведена к минимуму. На большинстве виртуальных серверов у вас будет несколько виртуальных машин, борющихся за время процессора, устройства ввода/вывода и доступ к сети. Наше тестирование не принимает это во внимание. Один гипервизор может иметь низкую производительность при низкой конкуренции за ресурсы, а затем показать куда большую эффективность, чем конкуренты, когда борьба за ресурсы выше.
Исследование проводилось на процессорах Intel, поэтому его результаты могут отличаться для AMD и ARM.
Заключение
Победителя в этом обзоре не будет. Каждое решение имеет свои плюсы и минусы, поскольку в различных ситуациях нам важны разные свойства. Потери в производительности достаточно малы, чтобы обращать на них внимание. Обычно все упирается в дисковую подсистему. Если планируется управление несколькими серверами, то при недостатке средств в первую очередь следует присмотреться к OpenSourceрешениям, имеющим многочисленные панели управления.
Proxmox
Proxmox представляет собой Debian-based-дистрибутив, заточенный под управление виртуальными машинами. Основные возможности:
- поддержка как KVM, так и OpenVZ из коробки;
- удобный веб-интерфейс для администрирования с поддержкой RESTful API и прав доступа;
- поддержка GlusterFS (отказоустойчивой кластерной файловой системы, разработанной в Red Hat) для хранения виртуальных машин.
Дистрибутив поставляется бесплатно, а вот в смысле обновлений политика выпускающей компании аналогична таковой у Red Hat — обновления делятся на тестовые и enterprise. Первые бесплатны, на вторые надо оформлять подписку.
Технологии обычной и контейнерной виртуализации становятся все более популярными, а грань между ними — все более тонкой. Тем не менее какие-то различия все же есть. В частности, Xen кажется на сегодня самой стабильной системой аппаратной виртуализации, которая к тому же еще и развивается. В пользу Xen говорит еще и то, что его использует такой гигант облачного хостинга, как Amazon. Однако его конкурент, KVM, тоже не стоит на месте — в частности, в последних версиях появилась возможность пробрасывать видеокарту, не имея второй.
В случае контейнеров все сложнее. Официально поддержка технологий для их создания оформилась в ядре относительно недавно и еще сыровата. Аналогичная технология требует накладывания патчей и не поддерживает новые ядра. Но неоспоримым плюсом контейнеров является то, что издержки производительности, связанные с эмуляцией железа / переключением контекстов, отсутствуют.
Мы в Cloud4Y считаем лидирующим решением для виртуализации продукты VmWare. Тем не менее, мы интересуемся и другими решениями, в том числе, Xen и KVM. И вот что мы заметили: существует не так уж много информации, позволяющей сравнить эти гипервизоры: последние дельные исследования, которые мы нашли в сети, относятся к 2012 году и, конечно, уже не могут считаться актуальными. Сегодня мы представим вашему вниманию тоже не самое новое, но, на наш взгляд, достаточно полезное исследование, посвященное производительности гипервизоров KVM и Xen.
Результаты
Тесты для виртуальных машин, установленных непосредственно на «железо», то есть, без операционной системы (далее — «железо»), послужили основой для тестирования виртуальных машин. Отклонение в производительности между двумя серверами без виртуализации составило 0.51% или менее.
Производительность KVM упала в пределах 1,5% по сравнению с «железом» практически во всех тестах. Только два теста показали иной результат: один из них — тест , где KVM показал себя на 2,79% медленнее, чем «железо». Странно, что KVM был на 4,11% быстрее в тесте PostMark (который симулировал сильно загруженный почтовый сервер). Производительность Xen сильнее отличалась от производительности «железа», чем в ситуации с KVM. В трех тестах Xen отличался на 2,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 |
Если вы хотите увидеть результаты полностью, пройдите по ссылке.
OpenVZ
Такой подход практически не сказывается на производительности (накладные расходы не выше 1-3%). Зато в ресурсах админ практически не ограничен — до 64 Гб RAM, 4096 CPU и так далее. При установке создается виртуальное сетевое устройство (venet), которое дает возможность задать для каждой VM свои сетевые настройки (IP и правила маршрутизации). Собственно, отсутствие каких-либо ограничений на ресурсы (кроме тех ограничений, которые связаны с возможностями физического сервера) делают OpenVZ популярным у хостеров, да и у админов, юзающих Linux.
Гостевые ОС обычно разворачиваются при помощи подготовленных контейнеров ОС. Администратор указывает доступные ресурсы и дисковые квоты (по inodes и/или объему), создавая шаблоны, которые и становятся основой VM. Такой подход очень упрощает процесс при создании большого количества однотипных VM. Причем контейнеры используются и при миграции (Checkpointing), когда замороженное состояние переносится на другой физический сервер. Этот процесс происходит «вживую», пользователи обычно замечают лишь увеличенное время отклика.
Традиционно OpenVZ является «домашней» системой виртуализации для дистрибутивов, базирующихся на Debian.
Технология виртуализации KVM (Kernel-based Virtual Machine) продвигается компанией RedHat и является «основной» в этом дистрибутиве и его клонах. Требует поддержку аппаратной виртуализации Intel VT или AMD V. Это означает, что KVM может использоваться далеко не на каждом компьютере: старые и некоторые из новых CPU (например, Intel Atom) не подойдут. В принципе, если оборудование закупается под задачу — это не проблема. Проверить очень просто:
$ egrep '^fl ags.*(vmx|svm)' /proc/cpuinfo
Распространяется он по лицензии GNU GPL, компании RedHаt и Novell предоставляют коммерческую поддержку.
Реализован в виде базового модуля ядра (kvm.ko) и userspace.
Но у KVM есть несомненный плюс — в качестве гостевых можно запускать Linux, *BSD, Windows, Solaris, Mac OS X и ряд других ОС. Гостевые системы ограничены фактически ресурсами сервера, каждая может иметь до 16 vCPU (некоторые ОС, вроде Win XP, предварительно следует специфически подготовить). К слову, опыт показывает, что если в качестве гостевой используется Linux, то лучше выбрать такой же дистрибутив, как и базовая система. Производительность и стабильность работы будут заметно выше.
Основным условием успешного переброса хоста является идентичность оборудования (тип CPU) и настроек гостевой системы, в том числе и пути к файлам образов. Хотя в некоторых случаях можно перенести ОС и без полного соответствия, но это потребует больше трудов и увеличивает вероятность ошибки. Гостевые ОС легко клонируются: один раз создав шаблон, его легко размножить.
Конвертирование P2V возможно двумя способами.
- Первый через dd, как описано в документации QEMU, но стандартной такую операцию назвать нельзя.
- Второй — применить VMWare Converter.
Так как KVM основан на QEMU (оба проекта тесно связаны друг с другом), то принципы управления (в частности, создания образов) остались те же. Для загрузки новой гостевой ОС через /dev/kvm используется специальная утилита kvm.
Управление осуществляется при помощи фронт-энда virt-manager, разработанного RedHat, или утилит командной строки qemu* и kvm. Чаще всего админы для удобства используют скрипты (на сайте проекта можно найти несколько заготовок).
Также доступны и интерфейсы: кроме тех о которых говорилось выше, это Karesansui (Xen/KVM), Symbolic, ConVirt (Xen/KVM), Ganeti (Xen/KVM).
Популярный гипервизор начал свой путь в конце 90-х, в недрах компьютерной лаборатории Кембриджского университета, и был доступен по GNU GPL. Первый публичный релиз вышел в 2007 году. Со временем была образована компания XenSource, выкупленная чуть позже Citrix, который создал на его основе свой Citrix XenServer (CentOS + Xen). Кроме того, гипервизор Xen используется в Oracle VM. Но изначально все новшества появляются в Xen, и только через некоторое время — в сторонних продуктах.
Относительно недавно проект начал разработку платформы облачных вычислений Xen Cloud Platform. Xen можно назвать универсальным, так как помимо поддержки полной (аппаратной) виртуализации (HVM, Hardware Virtual Machine) реализован режим паравиртуализации (PV). А значит, мы можем запустить его на сервере, не имеющем CPU с Intel-VT и AMD-V, но для этого требуется модифицированная версия ОС. К слову, именно разработчики Xen ввели в свет термин «паравиртуализация».
Код гипервизора и сопутствующих модулей сделан переносимым, в итоге Xen поддерживает несколько архитектур: x86, x86_64, Itanium, Power PC и ARM, хостовые ОС — Linux, NetBSD и FreeBSD. Первые релизы гипервизора были внедрены и в WinXP, однако конечное решение так и осталось экспериментом. В качестве гостевых ОС можно установить Linux, NetBSD, FreeBSD, Solaris и Windows. Производительность гостевых систем близка к работе непосредственно на железе, максимальные потери — до 8%. Поддерживаются Live Migration, изменение размеров диска, использование гостевой ОС видеокарты напрямую, задействование неиспользуемой памяти гостевых систем, синхронизация состояния VM между серверами (Remus Fault Tolerance), доступ к USB-устройствам.
Процессы гостевых ОС полностью изолированы друг от друга, не могут использовать привилегированные инструкции (такие обращения отправляются непосредственно гипервизору).
В версии 4.1 физический сервер может иметь > 255 CPU, 1 Тб RAM, а гостевая система — до 128 vCPU; доработано управление пулами CPU и теперь каждый пул может работать со своим планировщиком. В ядре vanilla Linux Xen «поселился» с версии 2.6.37, хотя в некоторых дистрибутивах Linux он уже давно поддерживался «из коробки».
Управление производится при помощи пакетов xen-utils, xen-tools, плюс доступно несколько интерфейсов. Кроме тех, о которых говорилось выше, сюда можно добавить virt-manager, AQEMU, OpenQRM, Xen Orchestra, Zentific, xnCORE и некоторые другие.
Читайте также: