Сегодня Четверг, 21 Сентября 2017 года

Доступность нашего хостинга:

uptime узнать

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Руководство пользователя Xen v3.0 - Часть 1

От переводчика

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

Этот документ является первым полным переводом руководства пользователя Xen на русский язык. Следует отметить, что существуют частичные переводы руководства пользователя Xen сделанные ранее (например, перевод Михаила Сгибнева доступный на сайте http://dreamcatcher.ru/).

Данный перевод выполнен в максимальном соответствии оригиналу. Любые дополнения по тексту отмечены текстом "прим. перев.".

 

Множество вопросов по инсталляции, настройке и эксплуатации Xen-системы, выходящих за рамки руководства, описано на русскоязычных wiki-страницах по Xen. Вы можете принять участие в работе над этими страницами, дополнить их или просто указать вопросы, которые, с вашей точки зрения, стоило бы осветить.

Спасибо за обратную связь, комментарии, замечания, и любую другую помощь; и просто за то, что вы пользуетесь Xen. А я надеюсь, что вам моя работа окажется полезной.

Введение

Xen -- это монитор виртуальных машин (VMM, Virtual Machine Monitor) или гипервизор (hypervisor) с поддержкой паравиртуализации (para-virtualization) для процессоров x86 архитектуры, распространяющийся с открытым исходным кодом (opensource). Xen может организовать совместное безопасное исполнение нескольких виртуальных машин на одной физической системе с производительностью близкой к непосредственной (native). Xen обладает функциональностью ПО корпоративного уровня; в нём, в частности, обеспечивается:

  • Производительность виртуальных машин близкая к производительности при непосредственном исполнении на железе;
  • Возможность живой миграции работающих виртуальных машин между хостами;
  • Поддержка до 32 виртуальных процессоров на одну гостевую машину с возможностью горячего добавления (hotplug) процессоров;
  • Поддержка платформ x86/32, x86/32 с PAE и x86/64;
  • Поддержка аппаратной виртуализации Intel Virtualization Techonology (VT-x) для запуска немодифицированных операционных систем (включая Microsoft Windows);
  • Отличная поддержка оборудования (поддерживаются практически все драйверы устройств Linux).

Варианты использования

Возможные варианты использования Xen:

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

Независимость от аппаратного обеспечения.
Запуск старых приложений и операционных систем на новом железе.

Запуск множества различных ОС.
Одновременное выполнение множества ОС при разработке, тестировании или экспериментах.

Разработка ядра ОС.
Тестирование и отладка ядра в ограниченной виртуальной машине -- нет необходимости в выделении отдельной тестовой машины.

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

Аппаратная поддержка для новых ОС.
Возможность разработки новых операционных систем пользуясь при этом широким спектром драйверов существующих операционных систем, в частности ОС Linux.

Поддержка операционными системами

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

Этот подход требует чтобы операционная система была портирована для запуска в Xen. Портирование ОС для запуска в Xen похоже на добавление поддержки ещё одной аппатной платформы, но проще, поскольку архитектура паравиртуальной машины очень похожа на архитектуру базовой системы. Ядра операционных систем должны быть портированы на Xen, но ключевая особенность заключается в том, что пользовательские программы (user space apllications) и библиотеки не требуют модификации.

На процессорах с аппаратной поддержкой виртуализации (технологии Intel VT и AMD SVM) есть возможность запускать немодифицированные гостевые системы. Портирование не требуется, однако необходима дополнительная драйверная поддержка внутри самого Xen. В отличие от традиционных гипервизоров, выполняющих полную виртуализацию, которые страдают от большой потери производительности, Xen и VT или Xen и Pacifica (SVM) дополняют друг друга: комбинация предлагает превосходную производительность паравиртуализированных гостевых операционных систем и вместе с тем полную поддержку немодифицированных гостевых систем, работающих непосредственно на процессоре. Полная поддержка технологий VT и Pacifica появится в начале 2006 года (Уже появилась -- Прим. перев.).

Поддержка паравиртуализации Xen в большом количестве операционных систем и их число постоянно растёт. В настоящий момент поддержка Linux находится уже в очень зрелом состоянии, она включена в стандартный дистрибутив. Портирование других ОС, включая NetBSD, FreeBSD и Solaris x86 v10, близко к завершению (о поддержке Xen разными ОС в настоящий момент читайте на странице Xen -- Прим. перев.).

Поддержка аппаратного обеспечения

В настоящий момент Xen работает на x86 архитектуре, и требует процессора P6 или новее (например, Pentium Pro, Celeron, Penitum II, Pentium III, Pentium IV, Xeon, AMD Athlon, AMD Duron). Поддерживаются многопроцессорные машины и поддерживается HyperThreading (SMT). Кроме того, ведется портирование на архитектуры IA64 и Power.

Обычный 32-битный Xen поддерживает до 4GB оперативной памяти. Однако, в Xen 3.0 появилась поддержка расширений физической адресации Intel PAE (Phyisical Addressing Extensions), которая позволяет на машине x86/32 адресовать до 64GB физической памяти. Xen 3.0 также поддерживает платформы x86/64, такие как Intel EM64T и AMD Opteron, на которых возможна адресация до 1TB физической памяти.

Xen перекладывает большинство задач по поддержке железа на гостевую операционную систему, работающую в управляющей виртуальной машине, также известной как домен 0. Сам Xen содержит только код, необходимый для обнаружения и запуска остальных процессоров системы, настройки обработки прерываний и нумерации PCI шины (PCI bus enumeration <--!-->). Драйверы устройств работают внтури привилегированной гостевой операционной системы, а не в самом Xen. Такой подход обеспечивает совместимость с большинством устройств, поддерживаемых Linux. Сборка XenLinux по умолчанию содержит поддержку большинства серверного сетевого и дискового оборудования, но при необходимости можно добавить поддержку других устройств, переконфигурировав Linux-ядро стандартным способом.

Структура Xen-системы

В системе Xen есть множество уровней, нижним и наиболее привилегированным из которых является сам Xen.

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

Первый домен, домен 0, создаётся автоматически при загрузке системы. Этот домен обладает особыми управляющими привилегиями. Домен 0 запускает остальные домены и предоставляет им виртуальные устройства. Еще он занимается выполнением административных задач, таких как остановка (suspending), возобновление (resuming) работы виртуальных машин и их миграция.

В домене 0 работает процесс xend, который и занимается управлением Xen. Xend отвечает за управление виртуальными машинами и обеспечение доступа к их консолям. Команды Xend даются из командной строки и передаются ему через HTTP-интерфейс.

История

Первоначально Xen разрабатывался исследовательской группой Systems Research Group компьютерной лаборатории Кембриджского университета (University of Cambridge Computer Laboratory) как часть проекта XenoServers, спонсируемого UK-EPSRC.

Цель XenoServers -- предоставить "общедоступную инфраструктуру для глобальных распределенных вычислений" (public infrastructure for global distributed computing). Xen играет здесь ключевую роль, позволяя эффективно разделять одну физическую машину между несколькими клиентами, выполняющими собственные операционные системы и приложения в собственной ограниченной среде. Эта среда предоставляет защиту, изоляцию ресурсов и учёт. Дополнительные сведения о Xenoservers можно получить на web-странице проекта, там же есть ссылки на документацию и технические отчёты: http://www.cl.cam.ac.uk/xeno.

Xen вырос в самодостаточный проект, позволяющий исследовать интересные вопросы, касающиеся наилучших решений в области виртуализации ресурсов: процессора, памяти, диска и сети. Среди тех, кто сделал и постоянно делает вклад в развитие проекта -- XenSource, Intel, IBM, HP, AMD, Novell, RedHat.

Xen впервые был описан в документе представленном на SOSP в 2003 году http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf, а его первый общедоступный релиз (1.0) был выпущен в октябре того же года. С того времени Xen существенно вырос и повзрослел, и сейчас он используется для решения производственных задач во многих системах.

Что нового

В Xen 3.0.0 есть:

  • Поддержка SMP гостевых операционных систем;
  • Поддержка Intel PAE (Physical Addressing Extensions) для серверов с большим чем 4G оперативной памяти;
  • Поддержка x86/64 (Intel EM64T, AMD Opteron);
  • Поддержка Intel VT-x для запуска немодифицированных гостевых ОС (Windows XP/2003, старый Linux);
  • Расширенные инструменты управления;
  • Улучшенная поддержка ACPI;
  • Поддержка графики AGP/DRM.

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

Инсталляция

Базовая инсталляция

Дистрибутив Xen включает три главных компонента: собственно Xen, порт Linux и NetBSD для работы в Xen и утилиты для управления Xen-системой. В этой главе рассказывается, как проинсталлировать дистрибутив Xen 3.0 из исходников. Возможен и другой вариант -- Xen может быть доступен в виде откомпилированных пакетов в самом дистрибутиве операционной системы.

Предварительные требования

Ниже перечислено программное обеспечение, необходимое для сборки и работы Xen.

Без этого Xen работать не будет:

  • Работающий дистрибутив Linux с загрузчиком GRUB, на системе с процессором P6 или старше.

Это необходимо для управляющих утилит Xen:

  • Пакет iproute2;
  • Пакет bridge-utils для Linux (например, /sbin/brctl);
  • Система hotplug для Linux (/sbin/hotplug и связанные с ним скрипты). В более новых дистрибутивах ещё и udev.

Это необходимо для того чтобы собрать Xen из исходников:

  • Сборочные утилиты (gcc v3.2.x или v3.3.x, binutils, GNU make);
  • Инсталляция zlib с заголовочными файлами (например, zlib-dev);
  • Инсталляция Python v2.2 или больше с заголовочными файлами (e.g., python-dev);
  • LaTeX и transfig для сборки документации.

После того как все требования удовлетворены, можно инсталлировать Xen из дистрибутива или его бинарную версию.

Инсталляция из архива бинарников

Архивы с откомпилированным Xen доступны для скачивания здесь:

    http://www.xensource.com/downloads/ 

После того как архив получен, его нужно распаковать и проинсталлировать.

# tar zxvf xen-3.0-install.tgz
# cd xen-3.0-install
# sh ./install.sh

После того как Xen установлен, его нужно сконфигурировать, как описано здесь.

Инсталляция из RPM

RPM-пакеты с откомпилированным Xen доступны здесь:

    http://www.xensource.com/downloads/ 

После того как пакет получен, его нужно установить с помощью программы rpm:

# rpm -iv rpmname

Смотрите инструкции и Release Notes для каждого RPM-пакета здесь:

    http://www.xensource.com/downloads/ 

Инсталляция из исходников

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

Получение архива исходников

Исходный код Xen доступен или как сжатый архивный файл или как клон Mercurial-репозитория Xen.

Получение архива

Архивы стабильных версий и ежедневных срезов дерева исходных кодов Xen находятся здесь:

	http://www.xensource.com/downloads/

Получение исходников из репозитория

Исходный код Xen можно получить непосредственно из Mercurial-репозитория, доступного здесь:

    	http://xenbits.xensource.com  

Подробности по ссылке "Getting Started Guide" отсюда:

        http://www.xensource.com/downloads/  

Сборка из исходников

В Makefile'е верхнего уровня Xen есть цель world, которая включает такие задачи:

  • Сборка Xen;
  • Сборка управляющих утилит, включая Xend;
  • Скачивание (если нужно) и распаковка ядра Linux 2.6, наложение патча Xen;
  • Сборка ядра Linux для запуска в доменах Xen.

После того как сборка завершена, должен появиться каталог первого уровня dist/, в котором будут находиться все результаты сборки. В частности, там будут два ядра -- одно с расширением -xen0, в него включены драйверы физических устройств и драйверы виртуальных устройств Xen; и второе с расширением -xenU; в нём драйверы только виртуальных устройств. Ядра находятся в каталоге dist/install/boot/, там же будет и гипервизор Xen, там же конфигурационные файлы ядер.

Список ядер, которые будут собираться, указывается в Makefile верхнего уровня, в строке:

KERNELS ?= linux-2.6-xen0 linux-2.6-xenU

В эту строку можно включать названия любых ядер, конфигурационные файлы которых присутсвуют в каталоге buildconfigs/

.

Нестандартноя ядро

Если нужно чтобы конфигурация ядра отличалась от стандартной, распространяющейся вместе с дистрибутивом Xen (например, для дополнительной драйверной поддержки или включения каких-либо опций ядра), можно использовать стандартный механизм конфигурирования ядра Linux. Например:

# cd linux-2.6.12-xen0
# make ARCH=xen xconfig
# cd ..
# make

Другой способой -- скопировать существующую конфигурацию ядра Linux (.config) в корень дистрибутива ядра и выполнить:

# make ARCH=xen oldconfig

Будут заданы вопросы о специфичных для Xen опциях. Если вы не знаете, для чего нужна та или иная опция, лучше оставляйте значение по умолчанию.

Имейте в виду, что единственное отличие между ядрами, используемыми в домене 0 и остальных доменах -- это их конфигурация. Версия с суффиксом U (непривилегированная версия) не содержит никаких драйверов физических устройств, что экономит до 30% его размера, и, вследствие этого, такое ядро может оказаться предпочительным для непривилегированных доменов. Версия с суффиксом 0 может использоваться как для загрузки системы, т.е. в домене 0, так и для управления непривилегированными доменами.

Инсталляция собранных бинарников

Файлы, полученные в процессе сборки, находятся в каталоге dist/install/. Для инсталляции файлов в систему нужно дать команду:

# make install

Вместо этой команды при необходимости можно скопировать файлы в соответствующие каталоги вручную.

В каталоге dist/install/boot находится конфигурационный файл использовавшийся при сборке ядра XenLinux, а также гипервизора Xen и ядра XenLinux с включенной отладочной символьной информацией (например, xen-syms-3.0.0 и vmlinux-syms-2.6.12.6-xen0). Эта информация имеет большое значение при анализе дампов в случае падения системы. Сохраняйте эти файлы, потому что при обращении за помощью в список рассылки разработчики могут попросить чтобы вы показали их.

Конфигурирование

После того как дистрибутив Xen скомпилирован и проинсталлирован, нужно подготовить систему к запуску и использованию Xen. Это сделать довольно легко.

Конфигурирование GRUB

Для того чтобы Xen/Linux мог загружаться, нужно добавить в grub.conf соответствующую запись (этот файл обычно находится в /boot или /boot/grub; в некоторых дистрибутивах он может называться menu.lst). Добавляемая запись должна выглядеть так:

title Xen 3.0 / XenLinux 2.6
kernel /boot/xen-3.0.gz dom0_mem=262144
module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro console=tty0

Строка kernel указывает GRUB где найти сам Xen, и какие конфигурационные параметры должны быть ему переданы (в данном случае, указывается сколько памяти, в килобайтах, должно быть выделено домену 0; и указывается настройка последовательного порта). Дополнительная информация о различных загрузочных режимах Xen, есть здесь.

Строка module конфигурационного файла указывает местоположение ядра XenLinux, которое должен загрузить Xen, и параметры, которые должны быть ему переданы. Это стандартные параметры Linux, которые:

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

В некоторых дистрибутивах, например, в SuSE, параметр ro может отсутствовать.

Для того чтобы использовать initrd, добавьте ещё одну строку module в конфигурационный файл:

  module /boot/my_initrd.gz

После инсталляции нового ядра рекомендуется не удалять существующую запись в меню из файла menu.lst, поскольку старое Linux-ядро может понадобиться в будущем, в особенности при возникновении проблем.

Serial-консоль

Доступ через serial-консоль даёт возможность управлять, наблюдать и взаимодействовать с системой через консоль на её последовательном порту (serial-консоль). Это дает возможность подключиться с другой, рядом стоящей системы через нуль-модемный кабель (LapLink) или удалённо, через serial-концентратор.

BIOS системы, загрузчик GRUB, Xen, Linux и Login -- каждый из них в отдельности должен быть сконфигурирован для доступа через последотельный порт. Не обязательно чтобы каждая из этих составляющих была полностью настроена, но это может оказаться весьма полезно.

Более подробно о кофнигурировании serial-консоли в Linux можно прочитать в "Remote Serial Console HOWTO" на сайте Linux Documentaion Project www.tldp.org

Настройка BIOS на использование serial-консоли

Включение поддержки serial-консоли в BIOS не означает, что автоматически включится поддержка serial-консоли в GRUB, Xen и Linux. Это нужно с другой целью: сделать удаленное управление системой более удобным, поскольку в этом случае POST и другие загрузочные сообщения (до загрузчика системы) передаются на serial-порт. Кроме того, становится доступным конфигурирование через serial-консоль самого BIOS.

О том как включить serial-консоль в BIOS должно быть написано в документации на материнскую плату/систему.

Настройка GRUB на использование serial-консоли

Включение поддержки serial-консоли в GRUB не включает и не выключает её в Xen и в Linux. Это нужно для того чтобы сделать использование системы с Xen более удобным: меню GRUB становится доступным через serial-порт и даёт возможность удалённого управления загрузкой.

Для того чтобы заставить GRUB работать с serial-консолью, надо добавить следующие строки в конфигурационный файл GRUB, который обычно находится в /boot/grub/menu.lst или в /boot/grub/grub.conf:

serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

Обратите внимание, что включены и последовательный порт, и локальная консоль на мониторе и клавиатуре. Текст "Press any key to continue" появится и там, и там. Нажатие клавиши на каком-либо из устройств приводит к тому что GRUB будет выводить информацию на него, а второе устройство ничего не получит. Если клавиши на клавиатуре не будут нажиматься в течение таймаута, система начнёт загружаться в соответствии с пунктом "по умолчанию".

Более подробная информация приводится в документации GRUB.

Настройка Xen на использование serial-консоли

Включение поддержки serial-консоли в Xen не включает и не выключает её в Linux. Вывод сообщений Xen на консоль делается для того чтобы можно было через serial-консоль смотреть на них при загрузке Xen, что может оказаться очень полезным во время отладки.

Для того чтобы включить вывод Xen на последовательный порт, нужно добавить загрузочную опцию Xen в конфигурационный файл GRUB; например, заменить приводившийся выше пример следующей строкой:

   kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1

Эта строка настраивает вывод Xen на COM1 на скорости 115200, 8 бит данных, без чётности, один стоп-бит. Параметры можно изменить. Описание всех возможных загрузочных параметров находится здесь.

Настройка ядра Linux на использование serial-консоли

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

Для того чтобы включить вывод сообщений Linux на serial-консоль во время загрузки, нужно в конфигурационном файле загрузчика передать ядру Linux параметр console=ttyS0 (или ttyS1, или ttyS2 и т.д.). Например, так:

  module /vmlinuz-2.6-xen0 ro root=/dev/VolGroup00/LogVol00 \
console=ttyS0, 115200

Вывод сообщений ядра будет выполняться на последовательный порт ttyS0 (COM1) на скорости 115200.

Конфигурирование Login на serial-консоли

Для захода в Linux-систему (не важно с Xen'ом или без) через последовательный порт нужно чтобы на порту было приглашение для входа в систему. Его можно получить с помощью программы mgetty или аналогичной (например, mingetty). Для того чтобы разрешить непосредственный вход root'у через консоль на последовательном порту, нужно добавить имя этого порта в /etc/securetty.

Для автоматического запуска программы-приглашения на последовательном порту нужно добавить в /etc/inittab:

    c:2345:respawn:/sbin/mingetty ttyS0

Чтобы init перечитал этот файл, нужно дать команду:

# init q

Для разрешения входа root'у через этот терминал, нужно добавить ttyS0 в /etc/securetty.

В вашем дистрибутиве может использоваться другая программы getty: mgetty, agetty или просто getty. Какую именно из них выбрать, уточните в документации на систему.

Библиотеки TLS

Пользователям XenLinux2.6 рекомендуется перед тем как загружать Xen отключить библиотеку TLS (Thread Local Storage). Проще всего это сделать так:

# mv /lib/tls /lib/tls.disabled

В любой момент можно включить TLS, переименовав каталог обратно:

# mv /lib/tls.disabled /lib/tls

Это связано с тем, что текущая реализация TLS использует сегментацию памяти недопустимую в Xen. Если TLS не отключить, Xen будет выполнять эмуляцию, которая приведёт к потере производительности. Для того чтобы быть уверенным в том что производительность на максимуме, нужно проинсталлировать специальную, адаптрированную для использования с Xen (nonsegneg) версию библиотеки.

Если запустить систему с отключённым TLS, в ходе загрузки будут выдаваться предупреждающие сообщения. В этом случае после того как машина загрузится нужно переименовать файлы, как описано выше, и запустить /sbin/ldconfig, для того чтобы переименование вступило в силу.

Загрузка Xen

После того как инсталляция и конфигурирование завершено, нужно перезагрузить систему и выбрать новый пункт Xen в меню загрузчика GRUB.

Процесс загрузки, который начнётся после этого, будет похож на обычный процесс загрузки Linux. Первая часть сообщений будет выведена собственно самим Xen, это -- низкоуровневые сведения о самом гипервизоре Xen и оборудовании. Оставшуюся информацию выводит уже XenLinux.

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

Когда загрузка закончится, можно зайти в систему, как и обычно. Если в процессе загрузки возникли какие-то проблемы, всегда можно перезагрузить систему и выполнить загрузку на старом Linux-ядре, выбрав его в приглашении GRUB.

Загрузка системы Xen

После загрузки Xen вы попадёте в привилегированный управляющий домен, Domain0. С этого момента можно с помощью команды xm create создавать гостевые домены и выполнять их загрузку.

Загрузка домена 0

После того как инсталляция и конфигурирование завершены, нужно перезагрузить систему и в меню загрузчика GRUB выбрать новый пункт Xen.

Процесс загрузки, который начнётся после этого, будет похож на обычный процесс загрузки Linux. Первая часть сообщений будет выведена собственно самим Xen, это -- низкоуровневые сведения о самом гипервизоре Xen и оборудовании. Оставшуюся информацию выводит уже XenLinux.

Когда загрузка закончится, можно зайти в систему, как и обычно. Если в процессе загрузки возникли какие-то проблемы, всегда можно перезагрузить систему и выполнить загрузку на старом Linux-ядре, выбрав его в приглашении GRUB.

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

Для запуска управляющего демона Xen, необходимо дать команду:

# xend start 

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

Запуск гостевых доменов

Создание конфигурационного файла домена
  • /etc/xen/xmexample1 -- простой шаблон конфигурационного файла, описывающий отдельную виртуальную машину.
  • /etc/xen/xmexample2 -- шаблон конфигурационного файла, который может использоваться для создания множества виртуальных машин. При использовании этого шаблона, при старте машины нужно указывать переменную vmid.

В этом каталоге есть множество других примеров, которые могут оказаться полезными. Можно скопировать любой из них и доработать. Чаще всего меняются такие параметры:


kernel
Путь к ядру, которое должно использоваться вместе с Xen (например, kernel = "/boot/vmlinuz-2.6-xenU")

memory
Объём оперативной памяти выделяемой домену, МБайт (например, memory = 64)

disk
Имя первого раздела в списке вычисляется на основе domain ID. Второй -- используется доменами совместно (например: disk = ['phy:your_hard_drive%d,sda1,w' % (base_partition_number + vmid), 'phy:your_usr_partition,sda6,r' ])

dhcp
Если раскомментировать эту переменную, домен будет получать IP-адрес от DHCP-сервера (например, dhcp="dhcp").

Может быть, потребуется отредактировать переменную vif и задать в ней MAC-адрес сетевого интерфейса виртуальной машины. Например:

    vif = ['mac=00:16:3E:F6:BB:B3']

Если переменную не установить, xend автоматически сгенерирует случайный MAC-адрес из диапазона 00:16:3E:xx:xx:xx, который закреплён организацией IEEE за XenSource как OUI (organizationally unique identifier - уникальный идентификатор организации). XenSource разрешает использовать в доменах Xen адреса выбранные случайным образом из этого диапазона.

Список назначенных номеров OUI можно посмотреть на странице http://standards.ieee.org/regauth/oui/oui.txt.

Запуск гостевого домена

Утилита xm предоставляет множество команд по управлению доменами. Запуск домена выполняется с помощью команды create. Предположим, что вы создали конфигурационный файл myvmconf, базирующийся на файле /etc/xen/xmexample2. Для старта домена с ID виртуальной машины 1 нужно ввести команду:

# xm create -c myvmconf vmid=1

Ключ -c обозначает, что после того как домен будет создан, xm должна превратиться в его консоль. Параметр vmid=1 устанавливает переменную vmid, использующуюся в конфигурационном файле myvmconf, равной 1.

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

Автоматический запуск и останов доменов

Можно сделать чтобы при старте домена 0 автоматически запускались избранные пользовательские домены, а при останове работы базовой системы она ожидала завершения их работы.

Для того чтобы включить автоматический запуск домена во время загрузки, разместите его конфигурационный файл (или ссылку на этот файл) в каталоге /etc/xen/auto/.

В дистрибутиве Xen есть стартовый скрипт в стиле Sys-V для RedHat Linux или других систем, совместимых с LSB, и при инсталляции Xen этот скрипт копируется в каталог /etc/init.d. Затем его можно добавить в загрузку способом, принятым в дистрибутиве системы.

Например, в RedHat:

# chkconfig --add xendomains

По умолчанию, он будет запускаться на уровнях запуска 3, 4 и 5.

Скрипт можно запустить вручную с помощью команды service (или вызвав непосредственно из каталога /etc/init.d):

# service xendomains start

Этак команда запускает все домены, перечисленные в каталоге /etc/xen/auto/

.

# service xendomains stop

Эта команда останавливает все, работающие в настоящий момент, домены Xen.

Конфигурирование и управление

Инструменты управления доменами

В этой главе рассматривается управляющее программное обеспечение и утилиты Xen.

Xend

Демон Xend выполняет функции по управлению виртуальными машинами. Он представляет собой центральную точку управления виртуализированными ресурсами. Этот демон обязательно должен работать, для того чтобы запускать и управлять виртуальными машинами. Xend должен работать от имени root'а, потому что ему нужен доступ к привилегированным системным функциям.

Для запуска Xend во время загрузки создан специальный стартовый скрипт /etc/init.d/xend. С помощью соответствующей программы (например, chkconfig) или создавая ссылки вручную можно указать уровни выполнения, на которых будет работать этот скрипт.

Демон Xend можно запустить прямо из командной строки.

# xend start 	    # запустить xend,  если он ещё не работает
# xend stop # остановить xend, если он запущен
# xend restart # перезапустить xend, ессли он работает; иначе - запустить
# xend status # показать состояние xend с помощью кода завершения

Скрипт SysV, предназначенный для запуска Xend во время загрузки, входит в состав дистрибутива Xen. Команда make install устанавливает скрипт в /etc/init.d. Для включения этого скрипта в загрузку, нужно воспользоваться chkconfig или создать символические ссылки вручную. После того как Xend работает, администрирование выполняется с помощью программы xm.

Ведение журналов

Сообщения от Xend записываются в файлы журналов /var/log/xen/xend.log и (менее часто) /var/log/xen/xend-debug.log. Эти файлы, наряду со стандартными журналами Syslog, могут пригодиться при поиске и устранении неисправностей.

Конфигурирование Xend

Xend написан на Python'е. При запуске он читает конфигурационную информацию из файла /etc/xen/xend-config.sxp. Инсталлятор Xen размещает файл-пример xend-config.sxp в каталог /etc/xen, что должно работать для большинства инсталляций.

Полное описание конфигурационных параметров приводится в файле xend-debug.sxp и man-странице xend-config.sxp. Некоторые наиболее важные параметры описаны ниже.

Для связи с Xend используется HTTP-интерфейс и доменные гнёзда UNIX. С их помощью удалённые пользователи могут передавать команды демону. По умолчанию Xend не запускает HTTP-сервер. Сервер управления через доменное гнездо Unix запускается, поскольку он требуется утилитой xm. Для поддержки миграции между машинами Xend может запускать демон перемещения (relocation daemon). Из соображений безопасности по умолчанию этот демон не включен.

Замечание: Настройки Xend в примере конфигурационного файла отличаются от настроек по умолчанию: запускается как HTTP-сервер, так и сервер перемещения.

Из файла:

#(xend-http-server no)
(xend-http-server yes)
#(xend-unix-server yes)
#(xend-relocation-server no)
(xend-relocation-server yes)

Для включения или выключения интересующих возможностей, нужно закомментировать или раскомментировать строки в этом файле.

Соединения с удалённых хостов по умолчанию отключены:

# Address xend should listen on for HTTP connections, if xend-http-server is
# set.
# Specifying 'localhost' prevents remote connections.
# Specifying the empty string '' (the default) allows all connections.
#(xend-address '')
(xend-address localhost)

Рекомендуется, что в случае, когда поддержка миграции не нужна, параметр xend-relocation-server устанавливать в no или комментировать.

Xm

Программа xm - это главный инструмент по управлению Xen из консоли. Общий формат командной строки xm такой:

# xm команда [ключи] [аргументы] [переменные]

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

Для того чтобы посмотреть справку самой программы, введите:

# xm help

Будет показан список наиболее часто использующихся команд. Полный список можно получить по команде xm help --long. Еще можно ввести xm help команда для просмотра справки по указанной команде

.

Базовые управляющие команды

Одна из очень полезных команд:

# xm list

Она выводит информацию о доменах в формате

name domid memory vcpus state cputime

Назначение полей:
name
Имя виртуальной машины.

domid
Номер домена, в котором выполняется виртуальная машина.

memory
Объем памяти машины, в мегабайтах.

vcpus
Количество виртуальных процессоров, которые есть у домена.

state
Состояние домена описыватся пятью полями:
r - работает; b - заблокирован; p - приостановлен; s - остановлен; c - упал.
cputime
Суммарное процессорное время (в секундах), которое использовал домен.

Команда xm list также поддерживает длинный формат вывода, с ключом -l. Эта команда выводит детальную информацию о доменах в формате xend SXP.

Если вы хотите узнать, сколько уже работают ваши домены, дайте команду:

# xm uptime

Доступ к консоли домена можно получить с помощью команды xm console. Например:

# xm console myVM

Команды управления планировщиком доменов

Планировщик атоматически распределяет гостевые виртуальные процессоры между всеми доступными физическими процессорами SMP системы. Привязывать вручную виртуальные процессоры к физическим нет необходимости. Однако, такая возможность есть. С помощью команды xm vcpu-pin можно указать на каких физических процессорах может работать виртуальный процессор машины.

У каждого гостевого домена есть два параметра: weight(вес) и cap (предел).

В нагруженной системе домен с весом weight 512 будет в два раза быстрее (по процессору) чем домен с весом 256. Допустимые значения весов находятся в диапазоне от 1 до 65535, значение по умолчанию равно 256.

Предел cap ограничивает максимальную величину процессорного ресурса, который может быть выделен гостевой системе, даже если хост-система простаивает. Предел выражается в процентах от одного физического процессора: 100 это один физический процессор, 50 это половина процессора, 400 -- это четыре процессора и т.д. Значение по умолчанию 0 означает что верхнего ограничения процессорного времени не существует.

Проверить и изменить значения веса и предела для каждого домена можно с помощью команд настройки планировщика (credit scheduler).

Показать вес weight и предел cap для домена:

# xm sched-credit -d домен

Установить вес для домена

:

# xm sched-credit -d домен -w вес

Установить предел для домена:

# xm sched-credit -d домен -c предел

Конфигурация домена

Здесь описывается формат конфигурационного файла домена, а также дополнительная информация о настройке сети в домене, драйверов и планировщика.

Конфигурационные файлы

В конфигурационных файлах Xen могут присутствовать перечисленные ниже параметры. Если не указано обратное, конфигурационные параметры заключаются в кавычки. В каталоге /etc/xen/ есть конкретные примеры.


kernel
Путь к образу ядра.

ramdisk
Путь к образу виртуального диска (не обязательно).

memory
Объём память в мегабайтах.

vcpus
Количество виртуальных процессоров.

console
Порт, на котором будет доступна консоль (по умолчанию 9600 + domain ID).

vif
Конфигурация сетевых интерфейсов. Может содержать пустую строку для каждого интерфейса, а может перекрывать значения по умолчанию, например:

    vif = [ 'mac=00:16:3E:00:00:11, bridge=xen-br0',
'bridge=xen-br1' ]

Запись означает: установить указанный MAC-адрес на первый интерфейс и подключить его к мосту xen-br0; подключить второй интерфейс к мосту xen-br1. Параметры, которые могут быть переопределены: тип type, мост bridge, IP-адрес ip, скрипт script, базовое устройство backend и имя интерфейса vifname.
disk
Список блочных устройств, которые должны быть экспортированы в домен. Например: ~disk = [ 'phy:hda1,sda1,r' ]%~ экспортирует физическое устройство /dev/sda1 в режиме только-для-чтения. Экспортировать в режиме чтение-запись смонтированный диск опасно. Если вы всё же хотите это сделать, нужно указать символы w! в качестве режима.

dhcp
Нужно установить равным 'dhcp', если для конфигурирования сети будет использоваться этот протокол.

netmask
Сетевая маска.

gateway
IP-адрес шлюза.

hostname
Имя виртуального хоста.

root
Имя корневого раздела, передаваемое ядру системы.

nfs_server
IP-адрес NFS сервера, если используется.

nfs_root
Путь к корневому каталогу на NFS-сервере, если используется.

extra
Дополнительные параметры, которые передаются ядру (не обязательно).

Есть другие конфигурационные параметры (например, для конфигурирования виртуальных TPM).

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

Конфигурирование сети

Для большинства пользователей подойдёт конфигурация сети ``прямо из коробки'', доступная непосредственно после установки. Более сложные сетевые инсталляции, например, с множеством Ethernet-интерфейсов и/или коммутатороми, требуют дополнительной настройки.

Эта секция описывает механизмы, которые xend предоставляет с целью гибкого конфигурирования виртуальной сети Xen.

Топология виртуальной сети Xen

Каждый сетевой интерфейс домена соединён с виртуальным сетевым интерфейсом домена dom0 с помощью соединения точка-точка (фактически, "виртуальным кроссовером"). Эти устройства называются vif<domid>.<vifid> (например, vif1.0 для первого интерфейса домена 1, vif3.1 для второго интерфейса домена 3).

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

Сетевые скрипты Xen

Виртуальная сеть Xen конфигурируется двумя скриптами (по умолчанию, network-bridge и vif-bridge). Они вызывются xend автоматически при появлении определённых событий. Аргументы скрипта предоставляют дополнительную контекстную информацию. По умолчанию, скрипты находятся в /etc/xen/scripts. Местоположение и имена скриптов могут быть сконфигурированы через /etc/xen/xend-config.sxp.


network-bridge:
Этот скрипт вызывается при запуске или остановке xend для того чтобы инициализировать или разорвать виртуальную сеть Xen. Скрипт стандартной конфигурации создаёт мост xen-br0 и переносит eth0 на этот мост, изменяя настройки маршрутизации соответствующим образом. Когда xend завершается, он удаляет мост Xen и eth0, возвращая нормальную конфигурацию IP и маршрутизации.

vif-bridge:
Этот скрипт вызывается для каждого виртуального интерфейса домена. Он может настраивать правила брандмауэра, и подключать vif к соответствующему мосту. По умолчанию, скрипт добавляет (или удаляет) виртуальные интерфейсы к мосту Xen по-умолчанию.

Существуют примеры скриптов (network-route, vif-route, network-nat и vif-nat). Для более сложных сетевых конфигураций (например, где требуется маршрутизация или интеграция с существующими мостами) эти скрипты могут заменяться другими доработанными вариантами.

Конфигурирование драйвера домена

PCI

Отдельные PCI устройства могут быть назначены конкретному домену (домен драйвера PCI), для того чтобы организовать прямой доступ из домена к PCI-устройствам.

Хотя, с одной стороны, домены PCI драйверов могут повысить стабильность и безопасность системы, остаётся несколько вопросов, связанных с безопасностью.

Настройка во время компиляции

Для того чтобы использовать этот функционал, убедитесь что поддержка PCI Backend вкомпилирована в ядро привилегированного домена (домена 0), а в ядра, которые будут запускаться в пользовательских доменах и которые собираются использовать PCI-устройства, вкомпилирована поддержка PCI Frontend. В XenLinux PCI Backend включается в конфигурационной секции Xen, а PCI Frontend включается в зависимой от архитектуры секции "Bus Options". Можно вкомпилировать вместе в одно ядро поддержку backend'а и поддержку frontend'а. Они друг другу не мешают.

Конфигурирование PCI Backend'а. Связывание при загрузке

PCI-устройство, которое вы хотите назначить непривилегированному домену, должно быть скрыто от backend-домена (обычно домена 0), и чтобы домен не загружал драйвер для этого устройства. Для этого используется параметр ядра pciback.hide, который указывается в командной строке ядра через GRUB. Обратите внимание, что в действительности устройства не скрыты от backend-домена. PCI Backend видится Linux как обычное PCI-устройство. PCI Backend привязывает себя как драйвер к какому-то устройству, и тем самым гарантирует, что никакие драйверы устройств для него больше загружатся не будут. PCI-устройства идентифицируются шестнадцатеричными числами слот/функция (slot/function), в Linux эти номера можно определить с помощью программы lspci. Их можно указывать с информацией о номере домена или без неё:

	
(bus:slot.func) например (02:1d.3)
(domain:bus:slot.func) например (0000:02:1d.3)

Пример параметров ядра Linux, скрывающих два PCI-устройства:

root=/dev/sda4 ro console=tty0 pciback.hide=(02:01.f)(0000:04:1d.0)

Конфигурирование PCI Backend'а. Позднее связывание

С помощью средств, предоставляемых Linux-ядром в sysfs, PCI-устройства можно привязывать к PCI-backend'у после загрузки (что позволяет предоставлять PCI-устройства драйверным доменам, которые не были указаны в командной строке ядра). Есть несколько атрибутов в каталоге PCI-backend'а в sysfs, которые можно использовать для того чтобы привязывать/отвязывать устройства:


slots
Показать список всех PCI-слотов, которые PCI-backend будет пытаться захватить (или "скрыть" от домена 0). Для того чтобы PCI-слот можно было привязать к PCI-backend'у посредством bind-атрибута, слот должен сначала быть в этом списке.

new_slot
Для того чтобы PCI-backend захватил какой-то слот, он должен быть указан здесь (в формате 0000:00:00.0).

remove_slot
Укажите здесь название слота (в таком же формате как new_slot), чтобы PCI-backend не пытался более захватить устройство в этом слоте. Обратите внимание, что с помощью этого нельзя отвязать драйвер от устройства, которое уже захвачено.

bind
Для того чтобы Linux-ядро пыталось привязать устройство в этом слоте к PCI-backend драйверу, нужно указать его в этом параметре (в формате 0000:00:00.0)

unbind
Напишите здесь имя слота (в таком же формате как для bind), для того чтобы Linux-ядро отвязало устройство от PCI-backend'а. Не отвязывайте устройство, пока оно отнесено к драйверному домену PCI!

Несколько примеров:

Привязать устройство к PCI Backend'у, который больше ни к чему не привязан:

# # Add a new slot to the PCI Backend's listO
# echo -n 0000:01:04.d > /sys/bus/pci/drivers/pciback/new_slot
# # Now that the backend is watching for the slot, bind to it
# echo -n 0000:01:04.d > /sys/bus/pci/drivers/pciback/bind

Отвязать устройство от драйвера и привязать к PCI Backend'у:

# # Unbind a PCI network card from its network driver
# echo -n 0000:05:02.0 > /sys/bus/pci/drivers/3c905/unbind
# # And now bind it to the PCI Backend
# echo -n 0000:05:02.0 > /sys/bus/pci/drivers/pciback/new_slot
# echo -n 0000:05:02.0 > /sys/bus/pci/drivers/pciback/bind

Обратите внимание на опцию -n в примере. Она заставляет echo не выводить перевод строки после текста, что имеет здесь принципиальное значение.

Конфигурирование PCI Backend'а. User-space quirks

Некоторым устройствам (например, Broadcom Tigon 3) может понадобиться доступ на запись к своим конфигурационным space регистрам. Xen'у можно указать для каких PCI-устройств есть доступ на запись в специфичные конфигурационные space регистры. Политика находится здесь:

	 /etc/xen/xend-pci-quirks.sxp

Файл содержит большое количество комментариев достаточных для того чтобы можно было его изменять и расширять.

Конфигурирование PCI Backend'а. Флаги разрешения

Если с помощью user-space quirks решить задачу не удалось, возможно, задачу можно будет решить с помощью permissive-флага для соответствующего устройства. Для этого прежде всего с помошью lspci нужно узнать PCI-домен, шину, слот и функцию этого устройства в домене dom0. После чего расширить user-space политику для permissive устройств. Permissive политика находится в:

/etc/xen/xend-pci-permissive.sxp

В настоящий момент единственный способо сбросить permissive-флаг это отвязать утсройство от PCI-backend драйвера.

Конфигурирование PCI Backend'а. Проверка состояния

Есть два важных узла sysfs, которые предоставляют механизм для просмотра специфичной информации о quirks- и permissive-устройствах:

/sys/bus/drivers/pciback/permissive

Просматривая с помощью cat этот файл, можно увидеть список permissive-слотов.

/sys/bus/drivers/pciback/quirks

Просматривая с помощью cat этот файл, можно увидеть иерархичесое представление устройств, привязанных к PCI-backend'у, их PCI vendor-ID и device-ID, а также все quirks, которое связаны с этим конкретным слотом.

Можно заметить, что у каждого устройства, привязанного к PCI-backend'у есть 17 стандартных quirks, независимо от того, что в xend-pci-quirks.sxp. Эти записи по умолчанию необходимы для обеспечения взаимодействия между менеджером шины PCI и устройствами, привязанными к ней. Даже у не-quirky устройств должны быть стандартные записи.

В данном случае эстетичность была принесена в жертву точности, и стандартные quirks показываются в общем списке quirks, а не скрываются.

Конфигурирование PCI Frontend'а

Есть несколько способов сконфигурировать пользовательский домен domU, чтобы он получил PCI-устройство.

С помощью командной строки. Использовать опцию командной строки pci. Если нужно передать несколько устройств, опция должна быть указана несколько раз.

	xm create netcard-dd pci=01:00.0 pci=02:03.0

С помощью конфигурационного файла. Указать все необходимые устройства в конфигурационном файле домена.

	pci=['01:00.0','02:03.0']

С помощью конфигурационного файла в формате SXP. Все PCI-устройства описываются в одной секции. Числа указываются в шестнадцаретичной системе счисления, начиная с символов 0x. Обратите внимание, что слово domain здесь относится к домену PCI, не домену виртуальной машины.

(device (pci
(dev (domain 0x0)(bus 0x3)(slot 0x1a)(func 0x1)
(dev (domain 0x0)(bus 0x1)(slot 0x5)(func 0x0)
)

Поддержка virtual Trusted Platform Module (vTPM)

Паравиртуализированным доменам можно предоставить доступ к виртуализированной версии TPM. Это даёт возможность приложениям в этих доменах использовать TPM-устройства, например, через TSS-стек Trousers TSS stack . В репозитории Xen есть все необходимые компоненты для обеспечения доступа к TPM. Поддержка выполняется за счёт нескольких вещей. Во-первых, модифицирован эмулятор TPM, для того чтобы он мог обеспечивать функциональность TPM для подсистемы виртуального TPM. Во-вторых, создан менеджер виртуального TPM, для того чтобы он мог координировать действия виртуальных TPM, управлять их созданием и provides protected key storage using the TPM. В-третьих, есть пара драйверов для XenLinux, представляющих TPM frontend и TPM backend. Драйверы нужны для передачи TPM-команд от домена менеджеру виртуального TPM, который отправляет их дальше программному TPM. Поскольку TPM Manager полагается на HW TPM для protected key storage, поэтому нужен аппаратный TPM, поддерживаемый Linux. Для разработчиков доступен эмулятор TPM, который можно использовать на платформах без аппаратной поддержки TPM.

Установка на этапе компиляции

Для включения доступа к virtual TPM, драйвер backend'а virtual TPM должен быть вкомпилирован в привилегированный домен (домен 0). В XenLinux необходимый драйвер можно выбрать в конфигурационной секции Xen. За исключением случая, когда драйвер вкомпилирован в ядро, для того чтобы активировать модуль необходимо дать следующую команду:

# modprobe tpmbk

Аналогичным образом, для поддержки функциональности TPM нужно вкомпилировать в ядро драйвер TPM fontend. Драйвер можно выбрать при конфигурировании ядра в меню Device Driver / Character Devices / TPM Devices. Вместе с этим драйвером нужно выбрать и TPM driver for the built-in TPM. Если драйвер виртуального TPM был скомпилирован как модуль, его нужно активировать с помощью команды:

# modprobe tpm_xenu

Далее, нужно откомпилировать менеджер виртуального TPM и программный TPM. Для этого нужно внести изменения в конфигурацию сборки Xen. Нужно сдобавить следующую сторку в файл Config.mk в корневом каталоге дистрибутива Xen:

VTPM_TOOLS ?= y

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

# vtpm_managerd
# vtpm_migratord

Как только VTPM менеджер работает, получить доступ к нему можно, загрузив драйвер в гостевой домен.

Разработка и тестирование эмулятора TPM

Для разработки и тестирования платформ без поддержки TPM, в качестве замены платформы TPM можно использовать эмулятор TPM.

Во-первых, запись в файле tools/vtpm/Rules.mk должна выглядеть следующим образом:

BUILD_EMULATOR = y

Во-вторых, запись в файле tool/vtpm_manager/Rules.mk должна быть раскомментирована:

# TCS talks to fifo's rather than /dev/tpm. TPM Emulator assumed on fifos
CFLAGS += -DDUMMY_TPM

Перед запуском менеджера virtual TPM, необходимо запустить эмулятор в домене dom0 с помощью такой команды:

# tpm_emulator clear

Конфигурирование vTPM Frontend'а

Для предоставления функциональности TPM домену пользователя, нужно добавить в конфигурационный файл виртуального TPM строку в следующем формате:

vtpm = ['instance=<instance number>, backend=<domain id>']

Параметр instance number это номер предпочитаемого виртуального TPM, который должен быть ассоциирован с доменом. Если указанный экземпляр уже ассоциирован с другим доменом, система автоматически выберет следующий доступный экземпляр. Обязательно должен быть указан номер экземпляра больший чем 0. Можно вообще не указывать параметр instance в конфигурационном файле.

Параметр domain id -- идентификатор домена, в котором работает драйвер backend'а виртуального TPM и сам TPM. В настоящий момент он всегда должен устанавливаться равным нулю.

Примеры записей vtpm в конфигурационном файле:

 vtpm = ['instance=1, backend=0']

и

 vtpm = ['backend=0'].

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

Доступ к функциональности TPM обеспечивается fontend-драйвером виртуального TPM. Этот драйвер предоставляет базовую информацию о состоянии TPM через файловую систему sysfs, точно так же как это делают существующие драйверы аппаратных TPM. В пользовательских доменах Xen эти записи sysfs можно найти в /sys/devices/xen/vtpm-0.

Отправлять команды virtual TPM можно с помощью символьного устройства /dev/tpm0 (major 10, minor 224).

Управление хранилищами и файловыми системами

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

Наиболее простой и прямой способ это экспортировать физическое блочное устройство (жесткий диск или раздел) из домена 0 в гостевой домен как виртуальное блочное устройство (Virtual Block Device, VBD).

Хранилище может быть также экспортировано из файла-образа файловой системы, как основанное на файле устройство (file-backed VBD).

Кроме того, для предоставления хранилищ виртуальным машинам могут использоваться стандартные сетевые протоколы, такие как NBD, iSCSI и NFS.

Экспорт физических устройств как VBD

Одна из самых простых конфигураций -- напрямую экспортировать отдельные дисковые разделы из домена 0 в другие домены. Для это используется ключевое слово phy: в конфигурационном файле домена. Например:

    disk = ['phy:hda3,sda1,w'] 

Эта строка указывает, что раздел /dev/hda3 домена 0 должен быть экспортирован в режиме чтение/запись в новый домен как /dev/sda1. С таким же успехом при желании можно было экспортировать его как /dev/hda или /dev/sdb5.

Помимо дисков и разделов можно экспортировать любые другие устройства, к которым Linux относится как к дискам. Например, если у вас есть диск iSCSI или том GNBD импортированный в домен 0, можно экспортировать его с помощью того же синтаксиса phy:. Например:

    disk = ['phy:vg/lvm1,sda2,w'] 

Если блочное устройство используется совместно несколькими доменами, то это должно быть в режиме только-для-чтения, иначе модуль файловой системы ядра Linux может очень удивиться, когда увидит, что структура файловой системы, с которой он работает, не соответствует его ожиданиям (если один и тот же раздел дисковой системы, отформатированный под ext3, смонтировать в режиме чтение/запись дважды, почти наверняка это приведёт к непоправимым последствиям). Демон Xend пытается защитить вас от такой ошибки, проверяя не смонтирована ли уже какая-то файловая система в режиме чтение/запись или в самом домене 0, или в гостевых доменах. Если требуется разделение в режиме чтение/запись, нужно или экспортировать соответствующий каталог через NFS из домена 0 или использовать кластерные файловые системы, такие как GFS или ocfs2.

Использование виртуальных блочных устройств основанных на файлах

В качестве основного хранилища для виртуальной машины можно использовать файл в домене 0. Это удобно, а кроме того виртуальное блочное устройство может быть разряжённым -- пространство будет действительно выделяться, только по мере использования файла. Если виртуальная машина использует, скажем, половину своего дискового пространства, тогда файл займёт только половину заданного размера.

Например, для того чтобы создать разрежённое файловое устройство размером 2GB (в действительности потребляет только 1 KByte дискового пространства):

# dd if=/dev/zero of=vm1disk bs=1k seek=2048k count=1 

Создайте в файле файловую систему:

# mkfs -t ext3 vm1disk 

(в ответ на вопрос о подтверждении введите y)

Наполните файловую систему, например, путём копирования из корневого каталога.

# mount -o loop vm1disk /mnt
# cp -ax /{root,dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{proc,sys,home,tmp}

Нужно доделать систему: отредактировать файл /etc/fstab, /etc/hostname. Нужно редактировать файлы на смонтированной новой файловой системе, а не на старой из домена 0, поэтому пути будут такими: /mnt/etc/fstab вместо /etc/fstab. Для нашего примера в fstab должна появится запись /dev/sda1 для корневого раздела.

После этого размонтируйте (это важно):

# umount /mnt 

В конфигурационном файле нужно установить:

    disk = ['tap:aio:/full/path/to/vm1disk,sda1,w'] 

По мере того как виртуальная машина будет писать на свой диск, разреженный файл будет наполяться и потреблять больше места, вплоть до заданных 2GB.

Замечание: Пользователям, которые работали с базирующимися на файлах виртуальными блочными устройствами в Xen предыдущих версий, будет интересно узнать, что сейчас поддержка этой функции выполняется с помощью драйвера blktap вместо loopback как раньше. В результате этих изменений файловые устройства стали более производительными, масштабируемыми и более надежными для хранения данных виртуальных блочных устройств. Для того чтобы использовать blktap вместо loop, достаточно изменить записи в конфигурационных файлах, с таких:

    disk = ['file:/full/path/to/vm1disk,sda1,w'] 

на такие:

    disk = ['tap:aio:/full/path/to/vm1disk,sda1,w'] 

Файловые виртуальные блочные устройства, работающие через loopback (устарело)

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

Файл с образом для виртуального блочного устройства можно подключить к виртуальной машине с помощью драйвера loopback в Linux. Единственное отличие от директив конфигурационного файла, описанных выше, в том что нужно указывать ключевое слово file:

    disk = ['file:/full/path/to/vm1disk,sda1,w'] 

Следует иметь в виду, что виртуальные блочные устройства, работающие через loopback, могут не подойти для использования в доменах с интенсивным вводом/выводом. При таком подходе возможны существенные потери производительности при больших величинах потоков ввода/вывода, связанные с тем как loopback-устройства обрабатывают ввод/вывод. Поддержка loopback-устройств оставлена для совместимости со старыми инсталляциями Xen; новым пользователям настоятельно рекомендуется использовать поддержку устройств, базирующихся на blktap (используя ''tap:aio'' как показано выше).

И ещё, Linux по умолчанию поддерживает только максимум 8 работающих через loopback блочных устройств для всех доменов вместе взятых. Этот предел можно статически увеличить параметром max_loop для модуля loop, при условии, что модуль скомпилирован отдельно от ядра (CONFIG_BLK_DEV_LOOP=M) или с помощью опции max_loop переданной непосредственно ядру при загрузке, в том случае, если модуль вкомпилирован в ядро (CONFIG_BLK_DEV_LOOP=Y). И здесь также пользователю рекомендуется использовать blktap, поскольку он масштабируется до намного большего количества активных VBD.

Использование виртуальных блочных устройств основанных на томах LVM

Особо привлекательной выглядит возможность хранения файловых систем домена на томах LVM, поскольку с их помощью можно легко увеличивать/уменьшать размеры томов, создавать снимки файловых систем (filesystem snapshots) и делать другие полезные вещи.

Для того чтобы иницииализировать поддержку LVM-томов дисковым разделом, нужно сделать с ним следующее:

# pvcreate /dev/sda10

Создайте группу томов (volume group), названную vg на физическом разделе (точнее, создайте группу томов, в которую будет входить физический том, созданный на предыдущем шаге):

# vgcreate vg /dev/sda10

Создайте догический том размером 4G, названный "myvmdisk1":

# lvcreate -L4096M -n myvmdisk1 vg

Появится устройство /dev/vg/myvmdisk1. Создайте файловую систему, смонтируйте её и заполните нужными файлами, например так:

# mkfs -t ext3 /dev/vg/myvmdisk1
# mount /dev/vg/myvmdisk1 /mnt
# cp -ax / /mnt
# umount /mnt

После этого измените конфигурацию виртуальной машины:

    disk = [ 'phy:vg/myvmdisk1,sda1,w' ]

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

Кроме этого можно использовать LVM для создания copy-on-write (CoW) клонов томов LVM (в терминологии LVM известные также как зaписываемые постоянные снимки, writeable persitent snapshots). Это средство появилось в Linux 2.6.8, и оно ещё не стало достаточно стабильным и зрелым. В частности, использование большого количества LVM-дисков требует много памяти домена 0, а также обработка ошибочных условий, таких как переполнение диска, выполняется не очень хорошо. Есть надежда, что ситуация изменится в будущем.

Создать два клона copy-on-write вышеуказанных файловых систем можно с помощью следующих команд:

# lvcreate -s -L1024M -n myclonedisk1 /dev/vg/myvmdisk1
# lvcreate -s -L1024M -n myclonedisk2 /dev/vg/myvmdisk1

Каждый из них может увеличиваться до тех пор пока не наберётся 1G отличий от основного тома. Увеличить величину пространства для хранения отличий можно с помощью команду lvextend, например:

# lvextend +100M /dev/vg/myclonedisk1

Нельзя позволять томам разницы заполняться, иначе LVM начинает сбиваться. Можно автоматизировать процесс расширения с помощью программы dmsetup, котороя наблюдает за томом, и как только он заполняется -- вызывает программу lvextend с целью его расширения.

В принципе, можно продолжать запись на том, который был склонирован (изменения не будет видны клонам), но это не рекомендуется: пусть лучше этот том будет нетронутым, и пусть он не монтируется ни одной из виртуальных машин.

Использование корневой файловой системы NFS

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

После этого нужно изменить конфигурацию NFS-сервера так чтобы он экспортировал эту файловую систему по сети. Для этого в файл /etc/exports нужно добавить, например, такие строки:

/export/vm1root      1.2.3.4/24 (rw,sync,no_root_squash)

Последнее, нужно сконфигурировать домен для использования корневой файловой системы NFS. В дополнение к обычным переменным нужно установить ещё следующий переменные в конфигурационном файле домена:

root       = '/dev/nfs'
nfs_server = '2.3.4.5' # substitute IP address of server
nfs_root = '/path/to/root' # path to root FS on the server

Домену нужен сетевой доступ во время загрузки, поэтому нужно или статически задать IP-адрес и прочие настройки с помощью переменных ip, netmask, gateway, hostname; или же включить DHCP (dhcp='dhcp').

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

Управление ресурсом процессора

Xen позволяет ассоциировать виртуальные процессоры домена с одним или более процессорами хоста. Это может помочь распределить ресурсы системы между гостевыми средами или сделать более оптимальным использование ресурсов в двухядерных процессорах и процессорах с гипертредингом (hyperthreading) и другими продвинутыми технологиями.

Xen нумерует процессоры "сначала в глубину". Для многоядерных процессоров с поддержкой гипертрединга сначала будут пронумерованы гипертреды (hyperthreads) в пределах ядра, затем все ядра, а потом гнезда. Например, если в системе два двухъядерных процессора с поддержкой гипертрединга, нумерация будет такой:

+----------------------------+-------------------------------+
| socket0 | socket1 |
|-------------+--------------+----------------+--------------+
| core0 | core1 | core0 | core1 |
|-------------+--------------+----------------+--------------+
| ht0 ht1 | ht0 ht1 | ht0 ht1 | ht0 ht1 |
+-------------+--------------+----------------+--------------+
#0 #1 #2 #3 #4 #5 #6 #7

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

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

Миграция доменов

Сохранение и восстановление доменов

У администратора Xen есть возможность сохранить текущее состояние на диск домена 0, чтобы затем продолжить его выполнение позже.

Например, сохранить домен VM1 на диск можно командой:

# xm save VM1 VM1.chk

Домен будет остановлен, а его состояние записано в файле VM1.chk.

Для того чтобы продолжить выполнение домена, используется команда restore:

# xm restore VM1.chk

Эта команда восстановит состояние домена и продолжит его выполнение. Домен будет выполняться как и раньше, а к его консоли можно будет подключиться с помощью вышеописанной команды xm console.

Миграция и живая миграция

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

Для выполнения живой миграции необходимо чтобы обе системы работали под управлением Xen, и в них был запущен xend. На системе, куда переносится домен, должно быть достаточно ресурсов (в частности, памяти) для перенесённого домена. В настоящий момент также требуется чтобы обе системы находились на канальном уровне в одной сети.

В настоящий момет при миграции домена не существует возможности автоматического удалённого доступа к локальным файловым системам. Администратор должен выбрать соответствующее хранилище (SAN, NAS и т.д.) для того чтобы доменная файловая система была доступна на обоих хост-системах. Хороший способ экспортировать том с одной машины на другую -- это GNBD. iSCSI может делать похожую работу, но его сложнее настраивать.

Когда мигрирует домен, его MAC и IP адрес мигрируют вместе с ним, поэтому миграция возможна только в пределах одной сети на канальном уровне. Если узел, на который переносится домен, находится в другой сети, нужно настроить туннелирование IP-пакетов на удалённый хост.

Миграция выполняется с помощью команды xm migrate. Для того чтобы выполнить живую миграцию на другую машину, нужно использовать команду:

    # xm migrate --live mydomain destination.ournetwork.com

Без ключа --live xend просто останавливает домен, копирует его образ по сети и запускает его заново. Поскольку у домена может быть большой объём памяти, перенос может потребовать достаточно много времени даже в гигабитной сети. С ключом --live xend пытается перенести домен в работающем состоянии. Простои при переносе составляют время порядка 60-300 мс.

Сейчас пока нужно соединяться заново с консолью домена на новой машине с помощью команды xm console. Если у мигрирированного домена были какие-то сетевые соединения, они сохранятся, поэтому SSH соединения не имеют указанного ограничения.

Безопасность Xen

В этой главе рассматривается как повысить безопасность Xen-системы. Описан ряд сценариев и хороших примеров. Начинается глава разделом, который посвящён общим вопросам безопасности Xen.

Рекомендации по безопасности Xen

При внедрении Xen системы нужно быть уверенным, что домен 0 находится в максимальной безопасности. Если взломан управляющий домен, все остальные домены автоматически оказываются под угрозой. Рекомендации для домена 0:

  1. Запускать как можно меньшее число сервисов, ничего лишнего. Чем меньше вещей присутствует в управляющем домене, тем лучше.
  2. Использовать брандмауэр для ограничения трафика к управляющему домену. Брандмауэр с правилами по умолчанию настроенными на запрет поможет предотвратить атаки на управляющий домен.
  3. Не допускать пользователей к домену 0. Известно, что существуют локальные эксплоиты для ядра Linux, позволяющие получить права root'а. Если у обычных (даже не обязательно привилегированных) пользователей есть возможность работать внутри домена 0, из-за локальных эксплоитов ядра существует риск для всех доменов системы.

Драйверные домены и безопасность

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

Однако, из-за ограничения существующего оборудования, при использовании драйверных доменов нужно иметь в виду несколько вещей (этот список не полный):

  1. Без IOMMU оборудование может выполнять прямое обращение к памяти (DMA) к областям памяти за пределами управляющего домена. Уязвимыми являются архитектуры, у которых нет модуля IOMMU, позволяющего ограничивать использование DMA (т.е. большинство x86-платформ). Устройство, которое может читать и изменять произвольные участки памяти, может читать и писать данные, находящиеся за пределами своего домена. Злонамеренный или работающий с ошибками домен может использовать подконтрольное ему устройство для записи или чтения данных в произвольных местах памяти другого домена.
  2. Разделяемые шины могут прослушиваться. Устройства, использующие совместно шину данных, могут прослушивать (или даже подменять) данные друг друга. Устройство A, назначенное домену A, может прослушивать данные, которые домен B передаёт устройству B, и передавать их домену A.
  3. Устройства, которые используют линии прерываний совместно с другими, могут при желании или помешать получению прерываний другим устройствам, или, наоборот, генерировать бесполезные прерывания. Устройства, совместно использующие level-triggered прерывания (например, PCI устройства) могут вызывать прерывания и никогда их не сбрасывать. Это блокирует для других устройств, которые используют эту же линию прерывания, возможность передачи сигнала о необходимости обслуживания своим управляющим драйверам. Устройства, использующие совместно линии прерываний любого типа, могут постоянно вызывать прерывания, что приведёт (причём в нескольких гостевых системах) к необходимости вызова процедур обработки прерываний (что потенциально может привести к тому, что другие процессы внутри соответствующего гостевого домена вообще не получат управления). Архитектура, в которой у каждого устройства может быть своя собственная линия прерываний (например, Message Signaled Interrupts шины PCI), подвержена этой проблеме в меньшей степени.
  4. Устройства могут совместно использовать адресное пространство ввода/вывода. Xen может ограничивать доступ к устройствам ввода/вывода только с определённым уровнем гранулярности. Для линий прерываний и портов ввода/вывода уровень гранулярности очень высокий (с точностью до одной линии или одного порта). Однако, что касается адресного пространства ввода/вывода, ограничение может выполняться только по границам страниц. Если несколько устройств совместно используют страницу в пространстве ввода/вывода, домены, которым принадлежат эти устройства, будут иметь возможность доступа к адресному пространству устройств друг друга.

Сценарии

Изолированная управляющая сеть

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

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

Подсеть за брандмауэром

В этом сценарии у каждого узла есть только одна сетевая карта, но весь кластер находится за брандмауэром. В этом случае брандмауэр должен делать как минимум следующее:

  1. Предотвращать IP-spoofing снаружи сети.
  2. Предотвращать доступ к порту перемещения (relocation) на всех узлах для всех, кроме самого кластра.

Такие правила можно использовать на каждом узле для запрета миграции снаружи сети, если главный брандмауэр не выполняет запрет:

# эта команда закрыват любой доступ к порту
# перемещения (relocation) Xen
iptables -A INPUT -p tcp --destination-port 8002 -j REJECT

# этак команда разрешает перемещение (relocation)
# только из определенной подсети
iptables -I INPUT -p tcp --source 192.168.1.1/8 \
--destination-port 8002 -j ACCEPT

Узлы в небезопасных сетях

В текущих версиях Xen миграция в небезопасных сетях также является небезопасной. Можно выполнять миграцию поверх безопасных туннелей VPN и SSH. Единственный безопасный вариант (за исключением туннелей) это отключение миграции как таковой. Проще всего это сделать с помощью iptables:

# эта команда закрыват любой доступ к порту
# перемещения (relocation) Xen
iptables -A INPUT -p tcp --destination-port 8002 -j REJECT

Управление доступом sHype/Xen

Framework принудительного контроля доступа (mandatory access control) это реализация sHype Hypervisor Security Architecture (www.research.ibm.com/ssd_shype). Она разрешает или запрещает обмен информацией и доступ к ресурсам на основе политики безопасности. Механизмы принудительного контроля доступа дополняют основные механизмы управления Xen, такие как механизмы защиты памяти. Они спроектированы таким образом, чтобы быть незаметными в ходе нормальной работы домена (policy-conform behavior), но в случае выхода домена за границы допустимого поведения быть готовыми вмешаться и ограничить его. В этой главе описывается как с помощью механизмов контроля доступа в Xen предотвратить распространение вирусов между доменами и утечку информации из одних нагрузок в другие. sHype/Xen зависит от правильного поведения домена 0.

Преимущества sHype/ACM в Xen:

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

Эти преимущества являются чрезвычайно ценными, поскольку нынешние операционные системы стали очень сложными, и в них часто не хватает механизмов принудительного контроля доступа (механизмы дискреционного контроля доступа, поддерживаемые в большинстве операционных систем, недостаточно эффективны против вирусов и неверно ведущих себя программ). Там где принудительный контроль доступа существует (например, SELinux), он обычно сопряжён со сложными и трудными для понимания политиками безопасности. Кроме того, в многоуровневых приложения для бизнес-сред обычно требуется совместная работа нескольких операционных систем (например, AIX, Windows, Linux), которые нельзя сконфигурировать так чтобы они использовали совместимые политики безопасности. Связанные распределённые транзакции и нагрузки нельзя простым способом защитить на уровне операционной системы. Framework контроля доступа Xen предлагает хотя и крупноблочный, но достаточно зрелый уровень безопасности в том случае если безопасность на уровне операционной системы отсуствует или недостаточная.

Чтобы контролировать совместное использование ресурсов доменами, Xen регулирует как междоменное взаимодействие (разделяемая память, события), так и обращение доменов к дискам. Так, Xen может держать в заданных рамках распределённые нагрузки, позволяя совместное использование ресурсов доменам выполняющим нагрузку одного типа и запрещая его для доменов выполняющих нагрузку разных типов. Будем исходить из предположения, что с точки зрения Xen только один тип нагрузки работает в одном пользовательском домене. Чтобы Xen мог ассоциировать домены и ресурсы с типами нагрузок, к доменам и ресурсам прикрепляются метки безопасности (включая типы нагрузок). Эти метки и sHype-контроль гипервизора нельзя обойти, и они являются эффективными даже против злонамеренных доменов.

Обзор

В этом разделе проводится обзор того как framework принудительного контроля доступа sHype может выполнять защиту нагрузок в Xen. На рисунке показаны необходимые для активации защиты нагрузок в Xen. Эти шаги подробно описаны здесь.


Обзор процесса активации защиты нагрузок sHype в Xen

Во-первых, средство управления доступом sHype/ACM должно быть собрано и проинсталлировано. Во-вторых, для того чтобы включать политику безопасности Xen, она сначала должна быть создана и внедрена. Политика определяет различные виды нагрузок, по которым делаются разграничения в ходе управления доступом. Кроме этого, она определяет различные правила, которые сравнивают типы нагрузок доменов и ресурсов и, основываясь на этом, принимают решение о разрешении или запрете доступа. Типы нагрузок представлены метками безопасности, которые могут прикрепляться к доменам и ресурсам. Защита sHype/Xen в действии продемонстрирована на простом примере. В этом разделе детально описывается синтаксис и семантика политики безопасности sHype/Xen, а также делается небольшое введение в использование программ, предназначенных для создания политик безопасности.

В следующем разделе описываются все шаги, необходимые для того чтобы создать, внедрить и проверить простую политику защиты нагрузки. С их помощью можно быстро попробовать механизм защиты нагрузки sHype/Xen. Те, кто хочет узнать больше о том, как работает контроль доступа sHype в Xen и как его настроить с помощью XML-политики безопасности, должны прочитать этот раздел. Этот раздел завершает главу обзором существующих ограничений реализации sHype в Xen.

Пошаговое руководство по защите нагрузок Xen

Процедура состоит из следующих шагов:

  • сконфигурировать и проинсталлировать sHype/Xen;
  • создать простую политику безопасности защиты нагрузки;
  • внедрить политику безопасности sHype/Xen;
  • ассоциировать домены и ресурсы с метками нагрузок;
  • проверить как выполняется защита нагрузок.

Важные команды, необходимые для создания и внедрения политики безопасности sHype/Xen, встречающиеся в следующих разделах, пронумерованы. Если вам понадобится быстрое руководство, или надо будет на скорую руку выполнить те действия, которые здесь описываются, просто ищите пронумерованные команды и применяйте их в соответствующем порядке.

Включение поддержки sHype в Xen

Прежде всего нужно настроить модуль контроля доступа в Xen и проинсталлировать гипервизор с поддержкой ACM. На этом шаге устанавливаются инструменты безопасности и sHype/ACM вкомпилируется в гипервизор.

Для того чтобы включить поддержку sHype/ACM в Xen, нужно отредактировать файл Config.mk в корневом каталоге дистрибутива Xen.

  (1) In Config.mk
Change: ACM_SECURITY ?= n
To: ACM_SECURITY ?= y

После этого нужно проинсталлировать Xen обычным способом:

  (2) # make world
# make install

Продолжение...

www.opennet.ru