Xen (произн. ) — кроссплатформенный гипервизор, разработанный в компьютерной лаборатории Кембриджского университета и распространяемый на условиях лицензии 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 % бесплатен и его исходные коды будут полностью открыты в ближайшее время. Мы вообще не планируем получение прибыли [с этого]»«XenServer is 100 % free, and also shortly fully open sourced. There is no revenue from it at all.»). Хотя существует свободная версия Citrix XenServer, для XenCenter (программного обеспечения для централизованного управления) не предоставляется исходных кодов, хотя она доступна бесплатно для загрузки.
15 апреля 2013 Xen перешёл под крыло Linux Foundation
История версий Версия Дата выпуска Примечания 1.0 2003.10.02 The first stable Xen release [LWN.net] 2.0 2004.11.05 Xen 2.0 released [LWN.net] Живая миграция для паравиртуальных гостевых машин 3.0 2005.12.05 Xen 3.0 released [LWN.net]XenSource: Press Releases Поддержка Intel-VT для гостевых систем HVM. Поддержка архитектуры Intel IA64.
Версия 3.0.4 также добавила: Поддержка расширения AMD-V . Поддержка архитектуры PowerPC. [Xen-devel] Xen 3.0.3 released! — Xen Source Поддержка графического фреймбуфера для паравиртуализированных гостевых систем. [Xen-devel] FW: Xen 3.0.4 released! — Xen Source 3.1 2007.05.18 [Xen-devel] Xen 3.1 released! — Xen Source Живая миграция для гостевых систем HVM, поддержка XenAPI 3.2 2008.01.17 «Проброс» PCI, режим «сна» ACPI S3. 3.3 2008.08.24Xen 3.3.0 hypervisor ready for download — The H: Security news and Open source developments Улучшения «проброса» 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.12017.04.124.92017.07.28Xen Project 4.9 Release Notes4.102017.12.12Xen Project 4.10 Release Notes4.112018.07.10Xen Project 4.11 Release Notes4.122019.04.02Xen Project 4.12 Release Notes4.132019.12.18Xen Project 4.13 Release Notes4.142020.07.24Xen Project 4.14 Release Notes4.152021.04.08Xen Project 4.15 Release Notes4.162021.12.02Xen Project 4.16 Release Notes4.172022.12.14Xen Project 4.17 Release Notes4.182023.11.17Xen Project 4.18 Release Notes
Области применения Технология виртуальных машин позволяет расширить функциональность оборудования следующими способами: Виртуальная машина обладает производительностью, сравнимой с реальной. Возможность миграции запущенной виртуальной машины между физическими машинами. Хорошая поддержка оборудования (поддерживается большинство драйверов устройств Linux) Возможность создания песочницы, перезагружаемые драйверы устройств.
Терминология Основной концепцией гипервизора является домен. Доменом называется запущенная копия виртуальной машины. Если виртуальная машина перезагружается, то её домен завершается (в момент перезагрузки) и появляется новый домен. Более того, даже при миграции содержимое копируется из одного домена в другой домен. Таким образом, за время своей жизни практически все виртуальные машины оказываются по очереди в разных доменах. Xen оперирует только понятием домена, а понятие «виртуальной машины» появляется на уровне администрирования (прикладных программ, управляющих гипервизором).
Домены бывают нескольких типов. Самые известные dom0 и domU. dom0 — первый запущенный Xen домен, обычно он автоматически создаётся и загружается сразу после загрузки и инициализации гипервизора. Этот домен имеет особые права на управление гипервизором и по умолчанию всё аппаратное обеспечение компьютера доступно из dom0. Фактически, dom0 — это место жизни ПО, управляющего Xen . dom0 всегда один.
domU — рядовой домен (сокращение от User domain), содержащий в себе домен выполняющихся виртуальных машин. Обычно не имеет доступа к реальному оборудованию и является «полезной нагрузкой» системы виртуализации. В отличие от dom0, domU может быть множество (обычно несколько десятков).
stub-domain — домен, в котором запущена очень специализированная ОС, обеспечивающая работу с каким-либо оборудованием или бэк-эндом драйвера. Является развитием модели безопасности Xen.
domain builder (конструктор доменов) — программа, которая создаёт domU (загружает в него нужный код и сообщает гипервизору о необходимости запуска). Помимо конструирования домена, обычно занимается подключением и конфигурированием виртуальных устройств, доступных для виртуальной машины. Она же отвечает за процесс миграции виртуальной машины с хоста на хост.
Технологии
Паравиртуализация
Паравиртуализация — адаптация ядра исполняемой ОС для работы совместно с Xen, обычно сокращается до PV. Позволяет достичь очень высокой производительности за счёт отсутствия эмуляции «настоящего железа», простоты интерфейсов и учёта существования гипервизора при выполнении системных вызовов в коде ядра. Выполнение привилегированных операций запрещено, вместо них совершаются гипервызовы () — обращения ядра гостевой ОС к гипервизору с просьбой о выполнении тех или иных операций. В большинстве случаев изменения при портировании ОС под 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 — быстрая синхронная или асинхронная передача сигнала о наступлении какого-то события. Общий доступ к памяти обеспечивает возможность передачи значительных объёмов информации, а события — скорость передачи.