От переводчика
Практически год назад вышла третья версия системы виртуализации 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=1terminal --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))
Взято тут