Как переехать с esxi на kvm/lxd и не сойти с ума

vMotion: как мигрировать ВМ между серверами

Чтобы с помощью vMotion перенести запущенную ВМ между двумя ESXi хостами, запустите vSphere Client, щелкните по ВМ и выберите Migrate.

Выберите тип миграции, который вы хотите использовать:

• Change compute resource only — миграция ВМ на другой сервер ESXi;
• Change storage only — подразумевается Storage vMotion – смена Datastore, на котором хранятся файлы ВМ;
• Change both compute resource and storage — режим миграции без общего хранилища (vMotion without shared storage/Shared-Nothing), при этом файлы ВМ копируются между хостами черед сеть).

Я выбрал первый вариант.

Мастер миграции предложит выбрать хост, кластер, resourse pool или vApp, в который нужно перенести данную виртуальную машину. Выберите хост. Если vMotion настроен правильно, и не обнаружено конфликтов, в секции Compatibility будет указано: Compatibility checks succeeded.

Если в поле совместимости содержатся какие-то ошибки, нужно внимательно прочитать их и исправить.

Нажмите Next.

Мастер миграции ВМ предложит выбрать в какую сети нужно поместить vNIC сетевой ВМ при миграции. Если вы хотите, чтобы ВМ была доступна после миграции, она должна быть помещена в тот же самый сегмент (VLAN), как и на исходном хосте. Если у вас используется стандартный vSphere Switch, нужно создать одинаковые группы портов (Port Group) на всех ESXi хостах. При использовании VDS, группы портов на всех хостах кластера одинаковые.

На последнем этапе нужно выбрать приоритет задачи миграции vMotion. По-умолчанию используется наивысший приоритете (Schedule vMotion with high priority). Я всегда использую именно его.

Осталось нажать Next -> Finish и запустится процедура миграции ВМ на другой хост. За статусом миграции можно следить в панели Recent Tasks (задание Relocate virtual machine). В моем случае процесс миграции ВМ с помощью vMotion по 10 Гб Ethernet занял около 3 секунд.

Убедитесь, что ваша ВМ теперь запущена на другом хосте ESXi.

Можно переместить запущенную ВМ на другой хост с помощью PowerShell командлета Move-VM из PowerCLI. Например, мы хотим перенести все ВМ с хоста esxi-1 на esxi-2:

Проверка подлинности пользователей

Несмотря на то что для запуска всех повседневных процессов достаточно сервера vCenter, выполнение некоторых задач (например, резервного копирования конфигураций и доступа к файлам журналов) невозможно без непосредственного доступа к узлу vSphere. Для управления доступом можно настроить узлы vSphere таким образом, чтобы они подключались к домену Active Directory, а подлинность всех пользователей при получении доступа к узлу автоматически проверялась по централизованному каталогу. Кроме того, с помощью клиента vSphere или интерфейсов командной строки vCLI и PowerCLI на каждом узле можно создавать и настраивать локальные учетные записи пользователей. Второй вариант можно использовать как вместо интеграции с Active Directory, так и вместе с ней.

Можно также создавать локальные роли, аналогичные ролям vCenter, которые будут определять права пользователей для этого узла. Например, пользователю может быть предоставлен доступ в режиме «только для чтения» (то есть разрешение просматривать информацию узла) или права администратора, с которыми можно не только просматривать, но и изменять конфигурацию узла. Если узел интегрируется с доменом Active Directory, локальные роли могут предоставляться также пользователям и группам AD.

По умолчанию в системе определен только привилегированный пользователь. Начальный пароль привилегированного пользователя устанавливается интерактивно через пользовательский интерфейс прямой консоли (DCUI) или задается автоматически в ходе установки. Затем его можно изменить с помощью клиента vSphere или интерфейсов командной строки vCLI и PowerCLI.

При использовании платформы vSphere пользователи могут получить права администратора, которые автоматически предоставляют доступ ко всей оболочке. С такими правами они не обязаны регистрироваться как привилегированный пользователь с помощью команды su, чтобы выполнять команды соответствующего уровня.

Платформа vSphere поддерживает запись всех действий, выполненных на узле через оболочку или интерфейс DCUI, в журнал под учетной записью текущего пользователя. Таким образом обеспечивается учет пользователей и упрощается мониторинг и аудит активности на узле.

Виртуальный коммутатор VMWare ESXi

Виртуальный коммутатор (vSphere Switch или vSwitch) – это виртуальное устройство, которое передает данные между виртуальными машинами внутри сервера и передает данные наружу через физический NIC. Есть два вида виртуальных коммутаторов:

• Standard Switches — простой виртуальный коммутатор, логически находится внутри физического сервера.
• Distributed Switches — распределенный виртуальный коммутатор, может быть распространен на несколько физических серверов (не доступен в бесплатной версии VMWare Hypervisor, да и в платной редакции VMWare vSphere доступен только в Enterprise Plus редакции).

После установки и запуска гипервизора уже имеется один виртуальный коммутатор vSwitch0, который включает в себя один физический адаптер vmnic0 и две группу портов – служебная (Management Network) для управления гипервизором и сеть для передачи данных (VM Network). Интерфейс управления гипервизором vmk0 (vmkernel port) включен в группу Management Network.

В большинстве случаев на отдельно стоящем гипервизоре вам будет достаточно одного виртуального коммутатора. Групп портов нужно создавать, если вы хотите изолировать виртуальные машины друг от друга, использовать различные настройки VLAN для группы портов.

Без особой необходимости не нужно вносить изменения в Management Network или vmkernel port, иначе вы можете потерять доступ к вашему интерфейсу управления гипервизором. Если вы потеряли доступ к гипервизору, вы можете сбросить сетевые настройки с помощью меню Network Restore Options в консоли DCUI.

Storage Requirements for ESXi 6.7 Installation or Upgrade

Installing ESXi 6.7 or upgrading to ESXi 6.7 requires a boot device that is a minimum of 1 GB. When booting from a local disk, SAN or iSCSI LUN, a 5.2-GB disk is required to allow for the creation of the VMFS volume and a 4-GB scratch partition on the boot device. If a smaller disk or LUN is used, the installer attempts to allocate a scratch region on a separate local disk. If a local disk cannot be found the scratch partition, /scratch, is on the ESXi host ramdisk, linked to /tmp/scratch. You can reconfigure /scratch to use a separate disk or LUN. For best performance and memory optimization, do not leave /scratch on the ESXi host ramdisk.

To reconfigure /scratch, see the topic «Set the Scratch Partition from the vSphere Web Client» in the vCenter Server Installation and Setup documentation.

Due to the I/O sensitivity of USB and SD devices, the installer does not create a scratch partition on these devices. When installing or upgrading on USB or SD devices, the installer attempts to allocate a scratch region on an available local disk or datastore. If no local disk or datastore is found, /scratch is placed on the ramdisk. After the installation or upgrade, you should reconfigure /scratch to use a persistent datastore. Although a 1GB USB or SD device suffices for a minimal installation, you should use a 4GB or larger device. The extra space is used for an expanded coredump partition on the USB/SD device. Use a high-quality USB flash drive of 16 GB or larger so that the extra flash cells can prolong the life of the boot media, but high-quality drives of 4 GB or larger are sufficient to hold the extended coredump partition. See Knowledge Base article http://kb.vmware.com/kb/2004784.

In Auto Deploy installations, the installer attempts to allocate a scratch region on an available local disk or datastore. If no local disk or datastore is found, /scratch is placed on ramdisk. You should reconfigure /scratch to use a persistent datastore following the installation.

Мониторинг оборудования (В том числе SNMP)

Модель CIM — это открытый стандарт, определяющий характеристики платформы мониторинга аппаратных ресурсов узлов vSphere, на которых развертывается архитектура ESXi. Особенностями такой платформы являются отсутствие агентов и использование стандартов в качестве основы. В состав этой платформы входит диспетчер объектов CIM, который также называют брокером CIM, и набор подключаемых модулей — поставщиков CIM.

Доступ для управления драйверами устройств и соответствующим оборудованием реализован с помощью поставщиков услуг управления облачной инфраструктурой (CIM). Поставщики оборудования, в том числе производители серверов и специализированных устройств, могут регистрировать таких поставщиков для мониторинга и администрирования собственных устройств.

Это относится и к компании VMware, которая разрабатывает модули для мониторинга инфраструктуры серверного аппаратного хранилища и ресурсов, используемых для виртуализации. Эти модули работают на узле vSphere, поэтому они занимают очень мало места и применяются для выполнения конкретных задач в области управления. Брокер CIM собирает данные всех поставщиков CIM и выводит их во внешнюю инфраструктуру с использованием стандартных API-интерфейсов, таких как WS-MAN и CIM-XML. Любое программное средство, которое поддерживает один из этих API-интерфейсов, например HP SIM или Dell OpenManage, может считывать эту информацию и, соответственно, выполнять мониторинг оборудования узла vSphere.

Одной из точек обработки данных CIM является сервер VMware vCenter. В клиенте или веб-клиенте vSphere можно в любой момент просмотреть состояние оборудования любого узла vSphere в среде. Таким образом формируется единое представление показателей работоспособности физических и виртуальных компонентов системы. Можно также настроить сервер vCenter для отправки оповещений, чтобы своевременно узнавать о таких событиях в физической инфраструктуре, как изменение температуры или отключение электричества, а также о серьезных отклонениях от заданных параметров.
Кроме того, решение vSphere использует стандарт SNMP для передачи данных о состоянии оборудования другим средствам управления, которые применяют этот же стандарт. Доступ к ловушкам SNMP возможен как с узла vSphere, так и с сервера vCenter.

Use vSphere Documentation

The vSphere documents in HTML reflect the latest vSphere update release of each major vSphere version. For example, version 7.0 contains all the updates for 7.0.x releases. All our documentation comes in PDF format, which you can access by selecting the Download PDF icon on any page in the HTML documentation. PDFs for previous releases of vSphere are available for download in a ZIP archive format. The archive can be found under the Archive Packages heading for each major version in the table of contents on the left.

You can create custom documentation collections, containing only the content that meets your specific information needs, using MyLibrary.

Редакции

Продукт vSphere лицензируется по процессорным сокетам и физическим хостам виртуализации (в зависимости от редакции).

Для малого бизнеса существуют редакции Essentials (600$) и Essentials Plus (4500$). Основное отличие между ними – живая миграция (vMotion), вещь довольно полезная. Живая миграция позволяет без остановки виртуальной машины в реальном времени перемещать её на соседний физический сервер. При этом работа виртуальной машины не прерывается, и факт миграции не замечают ни приложения внутри этой машины, ни внешние клиенты, работающие с этими приложениями. Редакция Essentials, по сути, это просто лицензия на 3 отдельных гипервизора с общим управлением, не более того. Редакция Plus позволяет создавать кластер высокой доступности (HA Cluster). Данная технология позволяет в автоматическом режиме перезапустить (холодный рестарт) на «живом» хосте виртуальные машины, которые работали на вышедшем из строя хосте кластера. Естественно, некоторый перерыв сервиса будет, машинам необходимо время на загрузку и запуск сервисов. Но 3 минуты в автоматическом режиме это лучше, чем часы простоя при ручном вмешательстве на физическом оборудовании.

С точки зрения лицензирования эти редакции позволяют собрать кластер из максимум трех хостов виртуализации, и установить сервер управления vCenter Server в урезанной версии Foundation. Эта версия vCenter может работать максимум с тремя хостами и создана именно для малого бизнеса.

Минимально рабочий вариант – редакция Essentials Plus из-за наличия vMotion. При покупке vSphere необходимо приобрести подписку на любой срок. Существуют варианты на 2 месяца, 1 и 3 года при покупке у VMWare. Если покупать через сторонних вендоров вроде IBM или HP, то подписка бывает и на 5 лет. Сама подписка дает право обновляться на любую версию vSphere бесплатно. Так же возможен даунгрейд. В рамки подписки так же входит техническая поддержка. При покупке подписки можно выбрать уровень поддержки, базовая только в рабочее время, или расширенная круглосуточно. Основные проблемы vSphere решаются через 5 минут поиска в , а действительно серьезные проблемы, обычно, связаны с серьезными ошибками в коде vSphere, и поддержка в таких случаях советует не использовать определенный функционал и дождаться очередных патчей. В случае, если клиент не продлил поддержку, это не является нарушением лицензионного соглашения. Но если позже клиент вдруг задумается сделать апгрейд до новой версии, то ему придется либо заново приобрести весь пакет лицензий с подпиской, либо восстановить подписку. Восстановление подписки производится за весь срок просрочки с уплатой штрафа и примерно равно стоимости подписки умножить на 1.2

Далее следуют редакции Standart (1000$), Enterprise (2500$) и Enterprise Plus (3500$). Данные редакции лицензируются на каждый сокет хостов виртуализации. Например, если у вас 6 хостов по 4 сокета, то необходимо приобрести 24 лицензии vSphere. Для создания кластера необходимо дополнительно приобрести сервер управления vCenter Standart (7000$). Так же существуют бандлы, которые чуть дешевле, чем продукты в розницу. Но после выхода Operations Manager (который не особо продается), VMWare упразднили обычные бандлы и теперь они есть только с Operations Manager, что учитывая повышенную цену, становится не особо привлекательным.

Редакция vSphere Standart по функционалу практически идентична редакции Essentials Plus, разве что не имеет ограничения на количество хостов в кластере (техническое ограничение максимум 32 хоста на кластер). Так же в редакции Standart есть искусственные ограничения по размеру виртуальных машин (8 виртуальных ядер vCPU). К сожалению, во всех младших редакциях vSphere нет балансировщика нагрузки, который может в автоматическом режиме перемещать виртуальные машины по хостам кластера, тем самым выравнивая их нагрузку (технология DRS).

Функционал DRS включен в редакции Enterprise и Enterprise Plus.

Enterprise Plus несет полный функционал, и является самой дорогой. Тут есть балансировка места на системах хранения (Storage DRS или просто SDRS), есть новая технология хранения данных vSAN, есть распределенный виртуальный свитч vDS, есть функция SSD кэширования vFRC. Конечно, список функций не ограничен только этими, но названные функции являются основными.

Получаем ESXi 7 iso

1. Заходим на страницу загрузки

2. Заполняем 3 поля, жмём Continue

3. Получаем в ответ КОСМИЧЕСКИХ МАСШТАБОВ анкету Её тоже заполняем, необязательные пункты отмечены как Optional. Если вы не юрлицо, но очень хочется дистрибутив, ваш единственный выбор – безбожно врите (: По завершении заполнения анкеты, на почтовый ящик придёт письмо с подтверждением

4. Завершаем регистрацию на сайте, активировав ссылку пришедшую на почту На этом этапе нужно будет ввести пароль от учётки что вы только что создали

5. Снова заходим на страницу загрузки И видим что появилась нужная нам кнопка. Скачиваем ISO

   Дожидаемся окончания загрузки и переходим к следующему этапу

Storage Requirements for ESXi 7.0 Installation or Upgrade

Installing ESXi 7.0 requires a boot device that is a minimum of 8 GB for USB or SD devices, and 32 GB for other device types. Upgrading to ESXi 7.0 requires a boot device that is a minimum of 4 GB. When booting from a local disk, SAN or iSCSI LUN, a 32 GB disk is required to allow for the creation of system storage volumes, which include a boot partition, boot banks, and a VMFS-L based ESX-OSData volume. The ESX-OSData volume takes on the role of the legacy /scratch partition, VM-tools, and core dump destination.

The recommended
ESXi
7.0 install options are the following:

• An 8 GB USB or SD and an additional 32 GB local disk. The ESXi boot partitions reside on the USB or SD and the ESX-OSData volume resides on the local disk.
• A local disk with a minimum of 32 GB. The disk contains the boot partitions and ESX-OSData volume.
• A local disk of 142 GB or larger. The disk contains the boot partitions, ESX-OSData volume, and VMFS datastore.

The
ESXi
7.0 system storage volumes can occupy up to 138 GB of disk space. A VMFS datastore is only created if the local disk device has at least 4 GB additional free space. To share a boot device with a local VMFS datastore, you need to use a local disk of 142 GB or larger.

If a local disk cannot be found, then ESXi 7.0 operates in degraded mode where certain functionality is disabled and the /scratch partition is on the RAM disk, linked to /tmp. You can reconfigure /scratch to use a separate disk or LUN. For best performance and memory optimization, do not run ESXi in degraded mode.

The upgrade process to
ESXi
7.0 repartitions the boot device and consolidates the original core dump, locker, and scratch partitions into the ESX-OSData volume. If a custom core dump destination is not configured, then the default core dump location is a file in the ESX-OSData volume.

Note: Rollback to an earlier version of
ESXi is not possible due to the repartitioning process of the boot device. To use an earlier version of
ESXi after upgrading to version 7.0, you must create a backup of the boot device before the upgrade, and restore the
ESXi boot device from the backup.

Due to the I/O sensitivity of USB and SD devices, the installer only creates a VMFS-L locker partition on these devices to store VM-tools and core dump files. When installing or upgrading on USB or SD devices, the installer attempts to allocate an ESX-OSData region on an available local disk. A datastore is used for /scratch, if there is no available space. If no local disk or datastore is found, /scratch is placed on the RAM disk. After the installation or upgrade, reconfigure /scratch to use a persistent datastore or add a new disk for system storage volumes.

For more information on reconfiguring the /scratch partition, see the vCenter Server Installation and Setup documentation.

Although an 8 GB USB or SD device is sufficient for a minimal installation, you should use a larger device. The additional space is used for an expanded core dump file and the extra flash cells of a high-quality USB flash drive can prolong the life of the boot media. Use a 32 GB or larger high-quality USB flash drive. See Knowledge Base article http://kb.vmware.com/kb/2004784.

In Auto Deploy installations, the installer attempts to allocate a scratch region on an available local disk or datastore. If no local disk or datastore is found, the /scratch partition is placed on the RAM disk. Reconfigure /scratch to use a persistent datastore after the installation.

Продакшн

LXD

Блочное устройство c rootfs надо монтировать. Миграции толком нетzabbix-agent странно ведет себя в контейнереПри взгляде на список процессов на гипервизоре, невозможно быстро понять, из какого контейнера растет конкретный процесс

Миграция

undefinesource — удалить виртуальную машину из гипервизора, с которого мигрируем. Без второго параметра — persistent — гипервизор, куда вы переехали, вообще не считает, что это постоянная миграция.

• Сеть: вам все время рассказывают про bridge — это кошмар! Читаешь и думаешь — как так?!
• Миграция: про нее тоже ничего внятного не скажут, пока сами головой не побьетесь об эту стенку.

Enhanced vMotion Compatibility (EVC) в VMWare

Режим Enhanced vMotion Compatibility (EVC) для кластеров VMware HA/DRS используется, если кластер построен на хостах с процессорами разных поколений (но не разных производителей!!). При включении EVC для кластера, гипервизор начинает маскировать инструкции CPU, которые поддерживаются не на всех хостах. При включении EVC все функции процессоров хостов ESXi в кластере начинают соответствовать некому базовому минимальному набору инструкций CPU, который задал администратора vSphere в настройках.

Таким образом благодаря EVC вы можете мигрировать ВМ между хостами с разными наборами инструкций процессора.

Нельзя смешивать в одном кластере vSphere хосты с разными вендорами процессоров, например, Intel и AMD. EVC позволяет добиться совместимости между процессорами только одного вендора.

Вы можете включить VMWare EVC на уровне кластера. Перейдите в раздел Configure -> Configuration -> VMWare EVC и нажмите кнопку Edit.

При включении EVC для кластера вам нужно выбрать режим EVC (для AMD или Intel) и выбрать в выпадающем списке минимальное поколение процессоров вендора, которые имеются в вашем кластере.

VMWare рекомендует всегда включать EVC, независимо от того какие хосты у вас в кластере. Так вам будет проще при расширении кластера. Есть даже отдельный документ, где доказывается, что даже если ваши ВМ не будут использовать весть набор инструкций, на производительность это не скажется.

В VMware vSphere 6.7 появились технологии миграции между облаком и on-prem (Cross-Cloud Cold и Hot Migration). Для реализации ВМ в облако теперь можно включать в настройках ВМ Per-VM EVC (доступно в vSphere 6.7 с Hardware Version 14).

Можно получить базовые уровни EVC выставлены для ВМ в кластере из PowerCLI:

Чтобы получить максимально поддерживаемый режим EVC на:

Проблемы при установке ESXi

Больше всего проблем возникает у тех, кто пытается произвести установку на несовместимое оборудование. Как я уже писал раньше, дистрибутив гипервизора имеет очень небольшой размер и драйверов в нем помещается немного. В основном VMwareподдерживает брендовых производителей, но иногда и на серверы известных марок, скачанный с официального сайта образ не устанавливается. Узнать точно совместим ли ваш сервер с гипервизором ESXiопределенной версии можно на специальной странице http://vmware.com/go/hcl Для тех кто планирует создание инфраструктуры с нуля, особенно для тех кто собирается экономить и покупать серверное оборудование по отдельным компонентам, эта страничка должна быть в закладках. Здесь можно найти информацию не только по совместимости с серверами, но и по совместимости с моделями определенных сетевых карт, PCI контроллеров, по поддерживаемым способам подключения между сервером и системой хранения и многое другое.

Для собственных серверов производители выпускают специальные сборки VMwareESXi, их чаще всего, можно найти на официальных сайтах вендоров. В этих сборках расширенный, обновленный до последних версий набор драйверов для устройств, устанавливаемых в серверное оборудование. Конечно, если есть такая сборка для вашего сервера, то лучше использовать ее.

Для встраивания своих драйверов в образ ESXiраньше использовалась программка VMware Image Builder, но я давно про нее ничего не слышал. То что вы встроили драйвер образ и он установился-запустился еще не означает его корректную работу. Поэтому все эксперименты на свой страх и риск.

Чаще всего на несовместимом оборудовании ESXiне устанавливается из-за отсутствия драйверов на сетевую карту, тогда есть вариант купить отдельно сетевую карту из листа совместимости, например, Intel PRO/1000, установить ее в сервер и, скорее всего, после этого установка завершится удачно.

Бывает, что установщик ESXi не находит дисков для установки. Возможен вариант, когда не видны диски, находящиеся не в рейде, тогда нужно собрать RAID, даже если диск в сервере один из него можно собрать RAID-0. А бывает наоборот, видны только диски, находящиеся не в рейде. Тогда есть вариант установить на один из дисков или для надежности на оба ESXi, а потом собрать RAID-1. Несколько раз на серверах Intelданный способ спасал.

И главное, получив ошибку при установке не унывайте раньше времени, воспользуйтесь поиском в Google, вы 100% не первый, кто наступает на эти грабли.

Для тех, кто собирается использовать оборудование, которого нет в листе совместимости и платные лицензии VMware. При обращении в службу технической поддержки вам откажут в решении проблемы, если узнают про несовместимость, а они узнают после того, как вы пришлете им логи.

Функциональные возможности

Ниже приведены ключевые концепции архитектуры Xen.

• Полная виртуализация.
• Xen может исполнять несколько гостевых ОС, каждую на своей виртуальной машине.
• Вместо драйвера, большинство интересных вещей происходит в xend, демоне Xen.

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

Большинство гипервизоров основаны на полной виртуализации, что означает, что они полностью эмулируют все аппаратные устройства для виртуальных машин. Гостевые операционные системы не требуют никакой модификации и ведут себя так, будто они имеют эксклюзивный доступ ко всей системе.

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

Паравиртуализация ― это метод виртуализации, который предоставляет виртуальным машинам программный интерфейс, подобный, но не идентичный базовым аппаратным средствам. Задачей этого модифицированного интерфейса является сокращение времени, затрачиваемого гостевой операционной системой на выполнение операций, которые в виртуальной среде выполнить значительно труднее, чем в невиртуализированной.

Существуют специальные «крюки» (hooks), позволяющие гостевой и хозяйской системам запрашивать и подтверждать выполнение этих сложных задач, которые можно было бы выполнить и в виртуальной среде, но значительно медленнее.

Полная виртуализация часто влечет неоптимальную производительность, потому что полная эмуляция обычно требует больше вычислительных ресурсов (и накладных расходов) со стороны гипервизора. Xen основан на паравиртуализации; он требует внесения в гостевые операционные системы изменений, направленных на поддержку операционной среды Xen. Тем не менее, пользовательские приложения и библиотеки никакой модификации не требуют.

Внесение изменений в операционную систему необходимо для того, чтобы:

• Xen мог заменить операционную систему в качестве наиболее привилегированной программы;
• Xen мог использовать более эффективные интерфейсы (например, виртуальные блочные устройства и виртуальные сетевые интерфейсы) для эмуляции устройств — это повышает производительность.

Xen может исполнять несколько гостевых ОС, каждую на своей виртуальной машине

Xen может исполнять несколько гостевых операционных систем, каждая из которых работает на своей собственной виртуальной машине или в своем домене. При первоначальной установке Xen автоматически создает первый домен, Domain 0 (dom0).

Domain 0 – это домен управления, который несет ответственность за управление системой. Он решает такие задачи, как создание дополнительных доменов (или виртуальных машин), управление виртуальными устройствами для каждой виртуальной машины, приостановка виртуальных машин, возобновление работы виртуальных машин и перенос виртуальных машин. Domain 0 исполняет гостевую операционную систему и отвечает за устройства.

Вместо драйвера, большинство интересных вещей происходит в демоне Xen

Демон Xen, xend, ― это программа на языке Python, которая запускается в dom0. Это центральный пункт управления виртуальными ресурсами всех виртуальных машин, работающих на гипервизоре Xen. Большинство команд анализа, проверки и планирования решается в пространстве пользователя Xend, а не в драйвере.

IBM поддерживает версию Xen для SUSE Linux Enterprise Edition (SLES) 10, которая обеспечивает следующую конфигурацию:

• четыре виртуальных машины на каждый процессор и до 64 виртуальных машин на одну физическую систему;
• гостевые операционные системы SLES 10 (только паравиртуализированные).