Xen (произн. / ˈ z ɛ n / ) — кроссплатформенный гипервизор , разработанный в компьютерной лаборатории Кембриджского университета и распространяемый на условиях лицензии GPL . Основные особенности: поддержка режима паравиртуализации помимо аппаратной виртуализации, минимальность кода самого гипервизора за счёт выноса максимального количества компонентов за пределы гипервизора.

История

Xen начинался как исследовательский проект Кембриджского университета под руководством Иэна Прэтта ( Ian Pratt ), ставшего в дальнейшем основателем компании XenSource. Компания поддерживала разработку версии с открытым исходным кодом (xen) и параллельно продавала коммерческие версии программного обеспечения, называвшиеся XenServer и XenEnterprise.

Первый публичный релиз Xen выпущен в 2003 году. В октябре 2007 Citrix купила XenSource и осуществила переименование продуктов:

• XenExpress в «XenServer Express Edition» (встроенная версия гипервизора стала называться «XenServer OEM Edition»)
• XenServer в «XenServer Standard Edition»
• XenEnterprise в «XenServer Enterprise Edition»

В дальнейшем они были переименованы в XenServer (Free), Essentials for XenServer Enterprise, и Essentials for XenServer Platinum.

22 октября 2007 Citrix завершила поглощение XenSource , и свободный проект переехал на сайт xen.org.

21 октября 2009 Citrix объявила, что коммерческие версии XenServer станут полностью свободными . Саймон Кросби ( Simon Crosby ), главный инженер подразделения Citrix по виртуализации заявил: «XenServer 100 % бесплатен и его исходные коды будут полностью открыты в ближайшее время. Мы вообще не планируем получение прибыли [с этого]» ). Хотя существует свободная версия Citrix XenServer, для XenCenter (программного обеспечения для централизованного управления) не предоставляется исходных кодов, хотя она доступна бесплатно для загрузки.

15 апреля 2013 Xen перешел под крыло Linux Foundation от 19 апреля 2013 на Wayback Machine

История версий

Версия	Дата выпуска	Примечания
1.0	2003.10.02
2.0	2004.11.05	Живая миграция для паравиртуальных гостевых машин
3.0	2005.12.05	Поддержка Intel-VT для гостевых систем HVM. Поддержка архитектуры Intel IA64 . Версия 3.0.4 также добавила: Поддержка расширения AMD-V . Поддержка архитектуры PowerPC . Поддержка графического фреймбуфера для паравиртуализированных гостевых систем.
3.1	2007.05.18	Живая миграция для гостевых систем HVM, поддержка XenAPI
3.2	2008.01.17	«Проброс» PCI, режим «сна» ACPI S3.
3.3	2008.08.24	Улучшения «проброса» PCI и управление электропитанием.
3.4	2009.05.18	Содержит первую версию «Xen Client Initiative» (XCI).
4.0	2010.04.07	Позволяет использовать ядра Linux как dom0, с использованием нового механизма PVOps.
4.1	2011.03.25	Поддержка более чем 255 процессоров, улучшение стабильности.( ).
4.2	2012.09.17	Поддержка 4095 физических (и до 512 виртуальных) процессоров, поддержка нескольких сегментов PCI, улучшение безопасности и документации.( ).
4.3	2013.07.09	Экспериментальная поддержка ARM. Учёт в планировщике особенностей архитектуры NUMA. Поддержка Open vSwitch .
4.4	2014.03.10	Поддержка ARM получила статус стабильной. Поддержка libxl библиотекой libvirt. Новый масштабируемый интерфейс для каналов событий. Поддержка создания вложенных виртуальных окружений на оборудовании Intel. Убрана поддержка x86 32-bit и ia64 (itanium) гипервизоров.
4.5	2015.01.15	Toolstack теперь переписан на С и называется xl или libxl, полностью заменив старый toolstack xend, который был написан на python.
4.6	2015.10.13
4.7	2016.06.24	Улучшения: безопасность, живые миграции, производительность и рабочая нагрузка. Аппаратная поддержка (ARM и Intel Xeon).
4.8.1	2017.04.12
4.9	2017.07.28
4.10	2017.12.12
4.11	2018.07.10
4.12	2019.04.02
4.13	2019.12.18
4.14	2020.07.24
4.15	2021.04.08
4.16	2021.12.02
4.17	2022.12.14

Области применения

Технология виртуальных машин позволяет расширить функциональность оборудования следующими способами:

• Виртуальная машина обладает производительностью, сравнимой с реальной.
• Возможность миграции запущенной виртуальной машины между физическими машинами.
• Хорошая поддержка оборудования (поддерживается большинство драйверов устройств Linux )
• Возможность создания песочницы, перезагружаемые драйверы устройств.

Терминология

Основной концепцией гипервизора является домен . Доменом называется запущенная копия виртуальной машины. Если виртуальная машина перезагружается, то её домен завершается (в момент перезагрузки) и появляется новый домен. Более того, даже при миграции содержимое копируется из одного домена в другой домен. Таким образом, за время своей жизни практически все виртуальные машины оказываются по очереди в разных доменах. Xen оперирует только понятием домена, а понятие «виртуальной машины» появляется на уровне администрирования (прикладных программ, управляющих гипервизором).

Домены бывают нескольких типов. Самые известные dom0 и domU . dom0 — первый запущенный Xen домен, обычно он автоматически создаётся и загружается сразу после загрузки и инициализации гипервизора. Этот домен имеет особые права на управление гипервизором и по умолчанию всё аппаратное обеспечение компьютера доступно из dom0. Фактически, dom0 — это место жизни ПО, управляющего Xen . dom0 всегда один.

domU — рядовой домен (сокращение от User domain), содержащий в себе домен выполняющихся виртуальных машин. Обычно не имеет доступа к реальному оборудованию и является «полезной нагрузкой» системы виртуализации. В отличие от dom0, domU может быть множество (обычно несколько десятков).

stub-domain — домен, в котором запущена очень специализированная ОС, обеспечивающая работу с каким-либо оборудованием или бэк-эндом драйвера. Является развитием модели безопасности Xen.

domain builder (конструктор доменов) — программа, которая создаёт domU (загружает в него нужный код и сообщает гипервизору о необходимости запуска). Помимо конструирования домена, обычно занимается подключением и конфигурированием виртуальных устройств, доступных для виртуальной машины. Она же отвечает за процесс миграции виртуальной машины с хоста на хост.

Технологии

Паравиртуализация

Паравиртуализация — адаптация ядра исполняемой ОС для работы совместно с Xen, обычно сокращается до PV. Позволяет достичь очень высокой производительности за счёт отсутствия эмуляции «настоящего железа», простоты интерфейсов и учёта существования гипервизора при выполнении системных вызовов в коде ядра. Выполнение привилегированных операций запрещено, вместо них совершаются гипервызовы ( англ. hypercalls ) — обращения ядра гостевой ОС к гипервизору с просьбой о выполнении тех или иных операций. В большинстве случаев изменения при портировании ОС под Xen затрагивают только ядро ОС, хотя могут предполагать и незначительные изменения в системных библиотеках (например, libc). Процесс адаптации к Xen очень похож на портирование для новой платформы, однако значительно проще ввиду простоты реализации «гостевой» части драйвера (драйверы в Xen состоят из двух частей — одна исполняется вне виртуальной машины, вторая находится внутри неё. Часть драйвера в гостевой системе крайне примитивна и служит лишь транслятором запросов во вторую часть. Это сделано преднамеренно для простоты портирования ОС под Xen). В PV-режиме не поддерживаются «вложенные» режимы работы процессора, такие как real-86, virtual-86, переключение между 32-битным и 64-битным режимом, поддержка эмуляции аппаратной виртуализации и т. д. В связи с этим в PV-режиме отсутствует начальный фрагмент загрузки компьютера (с имитацией кода BIOS, загрузчика и т. д.), а ядро гостевой системы сразу же запускается в нужном режиме, подобно тому, как запускаются обычные программы. В связи с этим, в частности, сам Xen не может работать в PV-режиме (то есть невозможно запустить «вложенный» гипервизор в PV-режиме).

Аппаратная виртуализация

В режиме аппаратной виртуализации (HVM) гостевая ОС не «знает» про существование гипервизора. Xen с помощью модулей из QEMU эмулирует реальное аппаратное обеспечение и позволяет провести начальную загрузку ОС. По её окончании для нормальной производительности должны запускаться PV-драйверы, которые реализуют быстрый интерфейс с виртуальными устройствами, подобно тому, как это работает в PV-режиме. Поскольку большинство привилегированных операций эмулируется, возможен запуск Xen в HVM-режиме из-под Xen. В этом случае вложенный гипервизор сможет работать только в PV-режиме.

Минимизация функций гипервизора

Гипервизор Xen (для версии 3.4) реализует минимальный набор операций для управления оперативной памятью, состоянием процессора, таймерами реального времени и счётчиками тактов (TSC) процессора, прерываниями и контролем за DMA. Все остальные функции, такие как реализация дисковых и блочных устройств, создание и удаление виртуальных машин, их миграция между серверами и т. д. реализуется в управляющем домене. За счёт этого размер гипервизора получается весьма малым (для версии 3.4 размер двоичного кода всего гипервизора меньше 600 КБ), так же как и размер его исходного текста. По замыслу авторов это увеличивает устойчивость системы виртуализации, так как ошибка в компонентах вне гипервизора не приводит к компрометации/повреждению самого гипервизора и ограничивает повреждения только вышедшим из строя компонентом, не мешая работать остальным.

Все функции, связанные с обеспечением работы сети, блочных (дисковых) устройств, эмуляции видеоадаптеров и прочих устройств вынесены за пределы гипервизора. Большинство таких устройств состоит из двух частей: драйверы в domU и программы в dom0. Драйвер (чаще всего встроенный в ядро ОС или загружающийся в виде модуля) реализует минимальный объём работы, фактически, транслируя запросы от ОС в программу в dom0. Программа в dom0 выполняет основную часть работы. При этом программа чаще всего запускается в виде отдельного процесса для каждого обслуживаемого устройства. Сбой в такой программе ведёт к сбою только одного устройства (блочного, сетевого) и не затрагивает работу других копий программы (то есть не затрагивает сетевые/блочные устройства остальных доменов, или даже другие устройства того же самого домена).

Традиционно используется следующая терминология: frontend — часть модуля, находящегося в domU, backend — часть, находящаяся в dom0. Для некоторых типов устройств backend часть может быть различной при сохранении одной и той же frontend части. Например, драйвер блочного устройства может иметь backend в форме программы работы с VHD-образами, с блочными устройствами, с iscsi-инициатором и т. д.

Междоменное взаимодействие

Xen предоставляет доменам три механизма взаимодействия: один — с гипервизором (hypercalls), и два между доменами. Чаще всего, взаимодействие происходит между dom0 и domU, хотя модель допускает взаимодействие и между двумя domU.

Междоменное взаимодействие сводится к двум видам: events (события) и shared mem (общий доступ к памяти). Третий вариант — передача страницы памяти, является частным случаем общего доступа к памяти.

Events служат примерно для того же, для чего служат прерывания в архитектуре x86 или сигналы в Unix — быстрая синхронная или асинхронная передача сигнала о наступлении какого-то события. Общий доступ к памяти обеспечивает возможность передачи значительных объёмов информации, а события — скорость передачи.

События могут быть маскированными и немаскированными. Немаскированные события вызывают callback (вызов функции, адрес которой передан ранее) и позволяют обрабатывать событие сразу же по факту его возникновения. Маскированные события лишь устанавливают флаг о том, что событие произошло, а обработчик периодически смотрит, произошло ли событие (одно или более). Второй метод позволяет не вызывать callback по каждому событию и в случае частых событий существенно снижает время обработки. Напротив, первый вариант (с вызовом callback) позволяет увеличить скорость обработки события, которое, возможно, происходит не слишком часто, но требует немедленной реакции.

Миграция виртуальных машин

Xen (с помощью стека управления) поддерживает миграцию гостевых виртуальных машин по сети. Миграция паравиртуальных машин поддерживается с версии Xen 2, а HVM – с версии 3. Миграция может происходить с выключением гостевой системы, или прямо в процессе работы, так называемая «живая» миграция ( англ. live migration ) без потери доступности.

Необходимо, чтобы оба физических сервера Xen видели одно и то же хранилище, на котором находятся данные виртуальной машины. Это требуется потому, что при миграции виртуальной машины её файловая система не копируется, так как это требовало бы слишком много времени даже в случае быстрой сети. Общее хранилище может быть организовано на основе различных технологий SAN или NAS , например Fibre Channel , iSCSI или DRBD .

Toolstack

В связи с тем, что сам гипервизор (около 500—600 КБ) реализует только «ядро» системы, вся остальная функциональность выносится на прикладной уровень, работающий в dom0. Набор программ, реализующий функциональность за пределами Xen называют англ. toolstack (устоявшегося перевода не имеется, иногда используется термин «стек управления»).

Существуют две версии toolstack для Xen: основанная на xend (входит в большинство поставок Xen) и основанная на xapi (входит в состав Citrix XenServer и Xen Cloud Platform). Xend развивался одновременно с Xen, написан на Python и с самого начала шёл под открытой лицензией. Xapi был проприетарной разработкой Xensource (в дальнейшем Citrix), но в 2009 году был опубликован под лицензией GPL. Xapi написан на OCaml , на момент написания имел меньший набор возможностей, но работал более стабильно.

В версии 4.5 xend, написанный на python, был заменён на xl/libxl, написанном на C.

В обеих версиях toolstack присутствуют следующие утилиты:

• xenstored — демон, реализующий интерфейс XenStore – простая древовидная база данных, напоминающая procfs . В xapi-toolstack XenStore переписан на ocaml, но реализует ту же самую функциональность.
• xenconsoled — демон, обеспечивающий в dom0 доступ к консолям виртуальных машин. Xenconsoled реализует бэкэнд консольного устройства для domU и использует API для создания псевдотерминалов в dom0. Соответствие между номером псевдотерминала и виртуальной машиной записывается в XenStore.

Toolstack обеспечивает управление виртуальными машинами (создание/удаление, запуск/останов, миграция, подключение ресурсов и т.д). Кроме этого, инструментарий обеспечивает управление ресурсами для крупномасштабных систем: создаёт и поддерживает репозитории хранения образов дисков виртуальных машин (SR — storage repository), поддерживает пулы серверов для миграции виртуальных машин и может управлять сложными конфигурациями локальной сети, в том числе с поддержкой VLAN . Кроме того, поддерживается интерфейс удаленного управления XenApi на основе XML-RPC .

Использование

Xen с каждым днем поддерживает всё больше и больше платформ.

Хост-системы

Являясь гибридным гипервизором типа 1 , Xen запускается непосредственно на аппаратной платформе, но для своей работы требует управляющей операционной системы в dom0. Xen поддерживает процессоры, начиная от Pentium II , имеются версии для архитектур x86-64 , PowerPC , Itanium (до версии 4.4) и ARM (стабильна с версии 4.4). Загрузка Xen осуществляется начальным загрузчиком типа GRUB или подобным. Непосредственно после загрузки Xen запускает операционную систему в dom0.

В большинстве инсталляций в качестве ОС управляющего домена dom0 используется Linux. Долгое время поддержка Xen не была включена в официальное ядро Linux и существовала в виде набора патчей для ядра v2.6.18. Начиная с v2.6.37 в ядре Linux появился механизм pv_ops для взаимодействия с гипервизорами . Данный механизм позволяет ядру работать как в паравиртуальном режиме, так и непосредственно на железе. Начиная с версии Xen 4.0 поддерживает механизм pv_ops для ядра Linux в dom0 . Ядра Linux выше 3.0 также полностью поддерживают Xen и для dom0 и для domU .

Также в качестве dom0 могут работать следующие операционные системы:

• Основанные на OpenSolaris дистрибутивы могут работать как dom0 так и domU начиная с версии Nevada build 75 и выше.
• На 2009 поддержка OpenBSD существовала, но требовала исправления некоторых ошибок перед релизом
• NetBSD 3.x. включает в себя поддержку dom0 для Xen 2, поддержка Xen 3.0 доступна начиная с NetBSD 4.0. Поддержка Xen 4 стартовала в NetBSD 5
• FreeBSD начиная с 11 версии, в режиме HVM

Гостевые системы

Большинство операционных систем могут быть запущены в режиме аппаратной виртуализации HVM, однако для достижения высокой скорости исполнения применяется технология паравиртуализации. Следующие гостевые операционные системы могут быть запущены в паравиртуальном режиме в domU:

• Большинство дистрибутивов Linux
  • Debian Lenny, Debian Squeeze, Debian Wheezy
  • Ubuntu 10.04, 11.04, 12.04
  • RedHat Enterprise Linux 4, 5, 6 (версия 6 поддерживает Xen только в качестве гостя)
  • Oracle Linux 5, 6
  • Fedora 14, 15, 16
  • SLES 10, 11
• NetBSD: NetBSD 2.0 поддерживает Xen 1.2, NetBSD 3.0 – Xen 2.0, NetBSD 3.1 – Xen 3.0, NetBSD 5.0 – Xen 3.3
• FreeBSD : i386 - в режимах PV и HVM, а amd64 пока только в режиме HVM.

Порты других операционных систем, таких как Plan 9 также находятся в работе. Ожидается, что для всех этих операционных систем будут выпущены официальные порты для Xen (как это случилось для NetBSD).

Операционные системы семейства Microsoft Windows могут быть запущены в режиме полной виртуализации HVM начиная с Xen 3 на процессорах с поддержкой аппаратной виртуализации. В этом случае виртуальные устройства (диски, сеть) эмулируются с помощью специальной версии QEMU . Для ускорения работы Windows могут применяться так называемые паравиртуальные драйверы . В отличие от Linux в паравиртуальном режиме, ядро системы Windows не подвергается изменениям и работает в режиме аппаратной виртуализации, однако драйверы устройств обращаются напрямую к Xen (через HyperCalls), минуя слой эмуляции QEMU. Существует разработка GPL'ed Paravirtualisation drivers for Windows, а продукты Citrix XenServer и Oracle VM содержат в своем составе подписанные паравиртуальные драйверы Windows.

Облачные системы

Xen широко применяется как компонент виртуализации в облачных вычислениях и при организации служб выделенных частных серверов . Такие хостинговые компании как Amazon Elastic Compute Cloud , , , Linode , SparkNode и Rackspace Cloud используют Xen как гипервизор виртуальных машин.

В настоящее время ^{[ уточнить ]} сообщество Xen разрабатывает Xen Cloud Platform (XCP) — систему серверной виртуализации. Своё происхождение XCP ведет от бесплатной версии Citrix XenServer и выпускается полностью под GNU GPL .

Коммерческие продукты

На основе Xen создано несколько коммерческих продуктов для консолидации серверов. В частности это такие продукты как:

• Citrix XenServer — коммерческий продукт, имеется также бесплатная версия XenServer, в которой отключены некоторые функции. Стек управления — на основе xapi , имеется внешняя программа управления Citrix XenCenter.
• Virtual Iron С 2009 года права на продукт принадлежат корпорации Oracle , с июня 2009 года продукт не развивается и не поставляется заказчикам.
• Sun xVM — первоначально Sun xVM hypervisor и Sun xVM Server — на основе кода гипервизора Xen для OpenSolaris . С мая 2009 года разработка xVM Server ведется в рамках проекта Xen/OpenSolaris.
• Red Hat Enterprise Linux версии 5 (RHEL5) включает в себя опцию Virtualization на основе гипевизора Xen и стека управления xend . Для управления используются virt-manager или libvirt/virsh . В RHEL6 для виртуализации Xen не используется, вместо него применяется KVM , но имеется поддержка Xen в domU.
• Oracle VM — Продукт включает Oracle VM Server for x86 и Oracle VM Manager. Сервер и менеджер бесплатны и доступны для скачивания. Стек управления на основе xend Для управления сервером на него устанавливается специальный Oracle VM Agent (ovs-agent). Manager представляет собой клиент-серверное приложение на основе WebLogic и позволяет управлять серверами виртуализации из браузера.
• Oracle Linux подобно Red Hat Enterprise Linux содержит виртуализацию на основе Xen для версии 5 и KVM для версии 6.
• SUSE Linux Enterprise Server версий SLES10 и SLES11 поддерживают Xen или KVM на выбор.

Примечания

Ссылки

• (англ.)
• (англ.)
• (англ.)
• , ixbt.com, 13 сентября 2007
• Установка Xen на Debian
• (англ.)