Сегодня Понедельник, 21 Августа 2017 года

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

uptime узнать

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

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

Создание политики нагрузки в три шага с помощью ezPolicy

Для быстрого создания политик, защищающих нагрузки, мы будем использовать программу ezPolicy. Для запуска этой программы требуются Python и wxPython. Для того чтобы запускать программу из домена Domain0, можно скачать wxPython с сайта www.wxpython.org или воспользоваться командой yum install wxPython в Redhat/Fedora. Если выполнять программу ezPolicy под Windows, также нужно будет скачать пакет Python с сайта www.python.org. После того как все необходимые пакеты установлены, запустите ezPolicy с помощью команды:

  (3) # xensec_ezpolicy

На рисунке показан скриншот программы. Создать политику, показанную на рисунке, можно с помощью таких шагов. Справка доступна в любой момент с помощью комбинации <CTRL>-h. Маркеры (a), (b) и (c) на рисунке указывают на кнопки, которые используются в ход создания политики "в три шага":

  1. описание нагрузки;
  2. описание конфликтов;
  3. преобразование описания нагрузки в политику sHype/Xen.
Описание нагрузок

Нагрузки определяются для каждой организации и отделения, которое вводится в левую панель. С помощью кнопки ''New Org'' (a) создайте организации ''Avis'', ''Hertz'', ''CocaCola'' и ''PepsiCo''.

Можно доработать описание организаций -- сделать чтобы нагрузки их различных подразделений различались. Для этого нужно щёлкнуть правой кнопкой мыши на организации и выбрать "Add Department" (или выбрать организацию и нажать Ctrl-A). Создайте подразделения ''Intranet'', ''Extranet'', ''HumanResources'' и ''Payroll'' для организации ''CocaCola'' и подразделения ''Intranet'' и ''Extranet'' для организации ''PepsiCo''. Итоговый вид должен быть похожим на левую панель, показанную на рисунке.

Определение конфликтов времени исполнения

Нагрузки, которым нельзя работать одновременно на платформе с одним гипервизором, сгруппированы в ''Run-time Exclusion rules'' (Правила исключения времени исполнения) на правой панели окна.

Для того чтобы избежать одновременного исполнения нагрузок PepsiCo и CocaCola (включая нагрузки на подразделения) на одном и том же гипервизоре, выберите организацию ''PepsiCo'', а затем, с нажатой клавишей Ctrl, выберите организацию ''CocaCola''. Теперь нажмите клавишу (b) с названием ''Create run-time exclusion rule from selection'' (создать правило исключения времени выполнения основываясь на текущем выделении). Правило появится на правой панели. Имя используется только для удобства и никак не затрагивает политики гипервизора.

Повторите процесс для создания правил исключения времени исполнения для нагрузок отделений CocaCola.Extranet и CocaCola.Payroll.


Итоговый вид окна с описанием нагрузок и правилами исключения времени исполнения

Итоговое окна должно быть похоже на то, что показано на рисунке. Нужно сохранить это определение нагрузки, выбрав ''Save Workload Definition as ...'' в меню ''File'' (c). Впоследствии при необходимости это определение можно будет доработать.

Преобразование определения нагрузки в политику sHype/Xen

Для того чтобы превратить определение нагрузки в политики контроля доступа, понятную Xen, выберите пункт ''Save as Xen ACM Security Policy'' (сохранить как политику безопасности ACM) в меню ''File'' (c). Введите следующее имя политики в появившемся окне: example.chwall_ste.test-wld. Если ezPolicy работает в домене 0, итоговый файл политики test-wld_security-policy.xml автоматически попадёт в правильный каталог /etc/xen/acm-security/policies/example/chwall_ste. Если программа запущена не в домене 0, нужно вручную скопировать полученный файл в домен 0, а затем продолжить.

Внедрение политики защиты нагрузки

Для того чтобы внедрить политику, созданную выше, создаётся файл-представление политикии (test-wld.bin), который можно загрузить в гипервизор Xen. Мы именно так и сконфигурируем Xen, чтобы он загружал политику при старте.

Приведённая ниже команда преобразует исходный файл представления политики в файл, который может быть загружен в Xen с поддержкой sHype/ACM. Детали -- в man-странице по xm.

  (4) # xm makepolicy example.chwall_ste.test-wld

Самый простой способ инсталлировать политику для Xen -- это включить её в загрузочную последовательность. Это делает следующая команда:

  (5) # xm cfgbootpolicy example.chwall_ste.test-wld

Как вариант, если команда не сработает (например, из-за того, что она не сможет идентифицировать загрузочную запись Xen), можно вручную, в два шага, установить политику вручную. Во-первых, нужно скопировать бинарный файл политики в каталог /boot/:

  # cp /etc/xen/acm-security/policies/example/chwall_ste/test-wld.bin \
/boot/example.chwall_ste.test-wld.bin

Во-вторых, нужно вручную добавить строку загрузки модуля в секцию Xen конфигурационного файла загрузчика GRUB:

 title Xen (2.6.16.13)
root (hd0,0)
kernel /xen.gz dom0_mem=2000000 console=vga
module /vmlinuz-2.6.16.13-xen ro root=/dev/hda3
module /initrd-2.6.16.13-xen.img
module /example.chwall_ste.test-wld.bin

Загрузитесь по этой записи, чтобы активировать политику и использовать гипервизор Xen с повышенной безопасностью.

  (6) # reboot

После перезагрузки, проверьте, включена ли безопасность:

 # xm list --label
Name ID Mem(MiB) VCPUs State Time(s) Label
Domain-0 0 1949 4 r----- 163.9 SystemManagement

Если метка безопасности в конце строки выглядит как "INACTIV", безопасность не включена. В этом случае нужно убедиться, что предыдущие шаги были выполнены верно. Примечание: Домену Domain0 назначена метка по умолчанию. Остальные домены, должны быть помечены для того чтобы работать с гипервизором поддерживающим sHype/ACM (ниже описывается как ставить метки на домены и ресурсы).

Пометка доменов

Конфигурационный файл домена должен выглядеть как показано ниже. Этот конфигурационный файл описывает домен domain1: (Примечание. Сайты www.jailtime.org и www.xen-get.org это хорошее место, где можно поискать примеры образов domU)

 # cat domain1.xm
kernel = "/boot/vmlinuz-2.6.16.13-xen"
memory = 128
name = "domain1"
vif = [ '' ]
dhcp = "dhcp"
disk = ['file:/home/xen/dom_fc5/fedora.fc5.img,sda1,w', \
'file:/home/xen/dom_fc5/fedora.swap,sda2,w']
root = "/dev/sda1 ro"

Если попробовать запустить домен, возникнет следующее сообщение об ошибке:

 # xm create domain1.xm
Using config file "domain1.xm".
domain1: DENIED
--> Domain not labeled
Checking resources: (skipped)
Security configuration prevents domain from starting

Каждый домен, перед тем как быть запущенным на sHype/Xen, должен быть ассоциирован с меткой безопасности. Без этого sHype/Xen не сможет обеспечить целостность политики. Следующая команда показывает все метки доступные в активной политике:

 # xm labels type=dom
Avis
CocaCola
CocaCola.Extranet
CocaCola.HumanResources
CocaCola.Intranet
CocaCola.Payroll
Hertz
PepsiCo
PepsiCo.Extranet
PepsiCo.Intranet
SystemManagement

Теперь domain1 получит метку CocaCola, а домен domain2 -- метку PepsiCo.Extranet. Подробности в man xen.

  (7) # xm addlabel CocaCola dom domain1.xm
# xm addlabel PepsiCo.Extranet dom domain2.xm

Если попробовать запустить домен снова:

 # xm create domain1.xm
Using config file "domain1.xm".
file:/home/xen/dom_fc5/fedora.fc5.img: DENIED
--> res:__NULL_LABEL__ (NULL)
--> dom:CocaCola (example.chwall_ste.test-wld)
file:/home/xen/dom_fc5/fedora.swap: DENIED
--> res:__NULL_LABEL__ (NULL)
--> dom:CocaCola (example.chwall_ste.test-wld)
Security configuration prevents domain from starting

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

Пометка ресурсов

Список доступных меток ресурсов можно посмотреть с помощью команды xm labels.

Назначим метку ресурса CocaCola файлы образу домена domain1, представляющему /dev/sda1, и файлу, представляющему раздел подкачки домена:

  (8) # xm addlabel CocaCola res \
file:/home/xen/dom_fc5/fedora.fc5.img
Resource file not found, creating new file at:
/etc/xen/acm-security/policies/resource_labels
# xm addlabel CocaCola res \
file:/home/xen/dom_fc5/fedora.swap

Запуск домена пройдёт успешно:

# xm create domain1.xm
# xm list --label
Name ID Mem(MiB) VCPUs State Time(s) Label
domain1 1 128 1 r----- 2.8 CocaCola
Domain-0 0 1949 4 r----- 387.7 SystemManagement

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

# xm resources
file:/home/xen/dom_fc5/fedora.swap
policy: example.chwall_ste.test-wld
label: CocaCola
file:/home/xen/dom_fc5/fedora.fc5.img
policy: example.chwall_ste.test-wld
label: CocaCola

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

  (9) Поставьте метку PepsiCo.Extranet на ресурсы домена domain2.
Пока что, не выполняйте запуск домена.

Проверка защиты нагрузки Xen

Проверить как работает защита нагрузки можно убедившись что:

  • домены с конфликтующими нагрузками не могут работать одновременно;
  • домен не может получить доступ к ресурсам других нагрузок;
  • домены не могут обмениваться сетевыми пакетами, если они не ассоциированы с нагрузками одного типа.
Test 1: Правила исключения времени выполнения

Предположим, что домен domain1 с меткой CocaCola всё ещё работает. Правила исключения времени исполнения нашей политики говорят, что пока домен domain1 работает, домен domain2 не может быть запущен, поскольку метка домена domain1 включает CHWALL тип CocaCola, а метка домена domain2 включает CHWALL тип PepsiCo. Правила исключения времени исполнения говорят, что PepsiCo и CocaCola не могут работать в одно и то же время на платформе одного и того же гипервизора. Как только домен domain1 остановлен или сохранён, можно запускать домен domain2, но теперь нельзя уже восстановить domain1. Программа ezPolicy, когда создаёт Chinese Wall типы для меток нагрузок, гарантирует то, что нагрузки подразделений наследуют типы соответствующих организаций (и вместе с этим исключения организаций).

# xm list --label
Name ID Mem(MiB) VCPUs State Time(s) Label
domain1 2 128 1 -b---- 6.9 CocaCola
Domain-0 0 1949 4 r----- 273.1 SystemManagement

# xm create domain2.xm
Using config file "domain2.xm".
Error: (1, 'Operation not permitted')

# xm destroy domain1
# xm create domain2.xm
Using config file "domain2.xm".
Started domain domain2

# xm list --label
Name ID Mem(MiB) VCPUs State Time(s) Label
domain2 4 164 1 r----- 4.3 PepsiCo.Extranet
Domain-0 0 1949 4 r----- 298.4 SystemManagement

# xm create domain1.xm
Using config file "domain1.xm".
Error: (1, 'Operation not permitted')

# xm destroy domain2
# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1949 4 r----- 391.2

Можно убедиться, что домены с меткой Avis могут работать вместе с доменами помечеными как CocaCola, PepsiCo или Hertz.

Test 2: Доступ к ресурсам

В этом тесте мы поставим на swap-файл домена domain1 ресурсную метку Avis. Домен domain1 больше не сможет даже запуститься, поскольку у него теперь нед доступа к этому ресурсу. Это тест проверяет возможности доменов по совместному доступу, которые описываются в компоненте Simple Type Enforcement.

# xm rmlabel res file:/home/xen/dom_fc5/fedora.swap
# xm addlabel Avis res file:/home/xen/dom_fc5/fedora.swap
# xm resources
file:/home/xen/dom_fc5/fedora.swap
policy: example.chwall_ste.test-wld
label: Avis
file:/home/xen/dom_fc5/fedora.fc5.img
policy: example.chwall_ste.test-wld
label: CocaCola

# xm create domain1.xm
Using config file "domain1.xm".
file:/home/xen/dom_fc4/fedora.swap: DENIED
--> res:Avis (example.chwall_ste.test-wld)
--> dom:CocaCola (example.chwall_ste.test-wld)
Security configuration prevents domain from starting

Test 3: Обмен информацией

В этом тесте выполняется такая проверка: могут ли два домена с метками Hertz и Avis обмениваться информацией по сети. Проверка делается с помощью ping. Он также имеет отношение к политике STE. Примечание: sHype/Xen не контролирует прямое взаимодействие между доменами. Однако, в настоящее время домены, ассоциированные с разными нагрузками, могут обмениваться информацией через сеть домена 0. Ведётся работа над механизмами управления sHype/ACM для локального и удалённого сетевого трафика. Дополнительная информация об этом может появитсья в списке рассылки xen-devel

.

Политика контроля доступа Xen

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

Политика управления доступом Xen состоит из двух компонентов. Первый компонент, называемый политикой Chiness Wall (CHWALL), контролирует какие домены могут работать одновременно на одной виртуализированной платформе. Второй компонент, называемой политикой Simple Type Enfotcement (STE), управляет организацией совместного доступа между доменами, т.е. обменом информацией между ними или доступом к ресурсам. Компоненты CHWALL и STE могут работать по-одиночке, но в нашем примере оба компонента политик сконфигурированы вместе, и они дополняют друг друга. XML файл политики содержит всю информацию необходимую для приведения политик в действие.

В этой политики выделены две нагрузки: CocaCola и PepsiCo, а также определены метки, необходимые для того чтобы ассоциировать домены и ресурсы c этими нагрузками. XML-политика состоит из таких частей:

  1. Заголовок политики, включая её имя;
  2. Блок Simple Type Enforcement (простого применения типов);
  3. Блок политики Chinese Wall;
  4. Блок определения меток.

Пример XML-файла политики безопасности - Часть I: Определение типов и правил
Заголовок и имя политики

Строки 1-2 включают обычный XML-заголовок. Описание политики безопасности начинается со строки 3. Оно соответствует схеме политики. XML-схема для описания политик безопасности может быть найдена в файле /etc/xen/acm-security/policies/security-policy.xsd. В каталоге examples/ c примерами есть примеры политик безопасности. Каталог acm-security/ единственный из проинсталлированных, в том случае, если безопасность ACM сконфигурирована в процессе инсталляции.

Заголовок политики покрывает строки 4-7. Он включает поле даты и определяет имя политики example.chwall_ste.test. Также он может включать необязательные поля, которые не показаны здесь, и которые предназначаются для будущего использования (см. описание схемы).

Имя политики нужно для двух вещей. Во-первых, оно собственно задаёт уникальное имя для политики безопасности. Это имя экспортируется гипервизором в управляющие утилиты Xen для того чтобы быть уверенным, что во всех случаях речь идёт об одном и том же. Планируется расширение имени политики цифровым отпечатком содержимого политики для лучшей защиты связи имени и содержимого. Во-вторых, оно неявно указывает утилите xm местоположение, где в системе хранится XML-политика. Заменив в названии политики двоеточия (точки?) на символы /, можно получить полный путь к файлу политики относительно каталога /etc/xen/acm-security/policies. Последняя часть имени политки это префикс для XML-файла политики, за которым следует -security_policy.xml. Например, политика с именем example.chwall_ste.test будет находиться в файле test-security_policy.xml, который находится в каталоге example/chwall_ste/ в каталоге политик.

Компонент политики Simple Type Enforcement

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

Xen управляет совместным доступом доменов на уровне доменов и ресурсов, посколько эта абстракция, является для гипервизора и управляющих утилит естественной. И хотя управляемые элементы получаются весьма крупными, такой подход оказывается достаточно надёжным и требует минимальный изменений гипервизора для внедрения в него возможностей принудительного контроля доступа (mandatory access control). Он включает возможность организации многоуровневой безопасности, не зависящей от платформы и операционной системы.

Строки 9-15 определяют компонент политики Simple Type Enforcement. По сути, они определяют типы нагрузок SystemManagement, PepsiCo и CocaCola, доступные в компоненте STE политики. Правила политики неявные: Xen позволяет доменам обмениваться информацией между собой только в том случае, если домены имеют одинаковый тип STE. Xen позволяет домену обращаться к ресурсу только в том случае, если метка домена и ресурса имеют одинаковый тип нагрузки STE.

Компонент политики Chinese Wall

Политики Chinese Wall (Китайская стена) в интерпретации sHype позволяет пользователяем предотвратить одновременное выполнение нагрузок от одновременного исполнения на платформе одного гипервизора. Правила исключения времени выполнения (Runtime Exclusion Rules, RER), также называемые множествами конфликтов (Conflict Sets), определяют множество типов нагрузок, которым нельзя выполняться одновременно. Из всех нагрузок, определённых в правилах исключения времени выполнения, максимум одна может выполняться на платформе одного и того же гипервизора в любой момент времени. RER реализуют менее жёсткий вариант оригинального компонента безопасности Chinese Wall. В них не реализовано *-свойство политики, которое потребовало бы ограничить типы, которые не являются частью правила исключения, как только они задействованы вместе с типами в правиле исключения (дополнительную информацию о том, что такое политика Chinese Wall вообще.

Xen при выполнении правил исключений времени исполнения учитывает ту часть метки, которая относится к ChineseWallTypes. Будет некорректно определять метки, включающие конфликтующие типы Chinese Wall'ов.

Строки 17-30 определяют компонент политики Chinese Wall. Строки 17-22 описывают известные типы Chinese Wall, которые здесь совпадают с STE типами, определёнными выше. Так бывает, если критерии для совместного использования доменами и совместного использования аппаратной платформы одинаковы. Строки 24-29 определяют одно правило исключения времени выполнения:

        <Conflict name="RER1">
<Type>CocaCola</Type>
<Type>PepsiCo</Type>
</Conflict>

Основываясь на этом правиле, Xen разрешит домену только одного типа, CocaCola или PepsiCo, работать с одним гипервизором в каждый момент времени. Например, как только запущен домен с назначенным ему типом нагрузки CocaCola, домен с типом нагрузки PepsiCo стартовать не сможет. Когда предыдущий домен завершится, а других доменов такого типа запущено не будет, сможет стартовать домен PepsiCo.

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

Причины, из-за которых может потребоваться ограничить список разрешённого к использованию доменом или нагрузкой оборудования:

  • Несовершенство механизмов управления ресурсами может привести к тому, что из-за одного некорректно ведущего себя домена ресурсов не будет другим домена и нагрузкам, работающим в них.
  • Запасные домены могут выполнять ту же нагрузку для повышения отказоустойчивости. Такие домены не должны работать на одном и том же оборудовании, чтобы избежать узких мест.
  • Из-за несовершенной изоляции доменов два злонамеренных домена могут обмениваться мужде собой данными. Таким образом, они обходят механизмы контроля доступа Xen. Эта проблема не может быть устранена полностью. Она является результатом компромисса между безопасностью и другими требованиями архитектуры. Такие же скрытые каналы могут быть между нагрузками, выполняющимися на различных платформах, при условии, что они соединены с помощью сети. Политика Xen Chinese Wall обеспечивает приблизительную реализацию этого несовершенного "зазора" между выбранными типами нагрузок.
Метки безопасности

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


Пример XML-файла политики безопасности - Часть II: Определение меток

Строки 32-89 определяют шаблон SecurityLabelTemplate, включающий метки, которые могут быть прикреплены к доменам и ресурсам, когда политика активна. Доменные метки включают в свой состав типы Chinese Wall, а метки ресурсов -- нет. Строки 33-65 определяют метки SubjectLabels, которые могут быть назначены доменам. Например, метка виртуальной машины CocaCola (строки 56-64) ассоциируют соответствующий домен с типом нагрузки CocaCola.

Атрибут bootstrap именует метку SystemManagement. Xen во время загрузки назначает эту метку домену Domain0. Метки для всех остальных доменов назначаются в соответствии с конфигурационным файлом домена. Строки 67-88 определяются метки объектов ObjectLabels. Когда политика активна, эти метки могут назначаться ресурсам.

Вообще, пользовательским доменам можно назначать метки, у которых есть только один тип нагрузки SimpleTypeEnforcement. В таком случае, нагрузка оказывается ограниченной, даже если пользовательский домен начинает вести себя некорректно. В любом домене, которому назначена метка с несколькими типами STE, можно доверять в том смысле, что информация принадлежащая различным STE типам будет разделена. Например, домен Domain0 имеет метку SystemsManagement, которая включает все известные STE типы. Это означает, что домен должен беспокоиться о том чтобы не допускать неавторизованного обмена информацией (например, через блочные устройства или виртуальную сеть) между доменами или ресурсами, которым назначены разные типы STE.

Для того чтобы ассоциировать метку с доменом, администратор безопасности просто использует имя метки, указанное в поле <Name>. Типы внутри метки испольщуются Xen'ом для выполнения контроля доступа. Имя метки может быть каким-угодно (главное, чтобы оно было уникальным), но рекомендуется выбирать его так, чтобы оно соответствовало включенным в метку типам безопасности. XML-представление показанной выше метки может показаться излишне гибким, как мы увидим в примере ниже, в общем случае метки могут состоять из множества типов.

Предположим, что нагрузки PepsiCo и CocaCola пользуются виртуальными дисками, которые предоставляет виртуальный домен ввода/вывода, использующий физическое устройство хранения, и у этого домена такая метка:

        <VirtualMachineLabel>
<Name>VIO</Name>
<SimpleTypeEnforcementTypes>
<Type>CocaCola</Type>
<Type>PepsiCo</Type>
</SimpleTypeEnforcementTypes>
<ChineseWallTypes>
<Type>VIOServer</Type>
</ChineseWallTypes>
</VirtualMachineLabel>

Этот виртуальный домен ввода/вывода (Virtual I/O domain, VIO) экспортирует свои виртуализированные диски общаясь с обоими доменами: с меткой PepsiCo и с меткой CocaCola. Для этого нужно чтобы у VIO домена были обе метки: PepsiCo и CocaCola. В этом примере разграничения нагрузок PepsiCo и CocaCola зависит от домена, который должен держать данные этих двух разных нагрузок разделёнными. Виртуальные диски тоже помечены и enforcement функции VIO домена должны гарантировать, что метки виртуального диска и домена, монтирующего виртуальный диск, имеют одинаковый тип STE. VIO метка со своим CHWALL типом VIOServer позволяет VIO серверу, к которому есть доверие, выполнять одновременно нагрузки PepsiCo и CocaCola.

Как вариант, система у которой есть два жестких диска может не использовать VIO домен, а может непосредственно назначить каждое устройство отдельным нагрузкам (если у платформы есть IO-MMU). Организация совместного использования железа с помощью виртуализации это компромисс между объёмом безопасного (trusted) кода (т.е. размером trusted computing base) и допустимой величиной дополнительных мер предосторожности. Это относится как периферии, так и к самой системной платформе.

Инструменты для создания политик безопасности sHype/Xen

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

  • ezPolicy GUI tool - начало написания политик;
  • xensec_gen tool - доводка политик, созданных с помощью ezPolicy;
  • текстовый или XML-редактор.

В этом примере для того чтобы быстро создать политику защиты нагрузки использозвался ezPolicy. При желании можно загрузить полученный файл в xensec_gen и доработать его. Его же можно непосредственно доработать с помощью редактора XML. Каждый XML-файл при трансляции проверяется на соответствие схеме политики безопасности.

Существующие ограничения

Работа над sHype/ACM для Xen продолжается. Сейчас идёт работа по организации защиты виртуализированных ресурсов и планируется организация защиты удалённых ресурсов и доменов. Ниже описываются ограничения существующие ограничения механизма управления доступом, над устранением которых ведётся работа.

Сетевой трафик

Локальный и удалённый сетевой трафик не контролируется. Существуют решения по наложению ограничений sHype/ACM на виртуальную сеть, но их нужно обсудить прежде чем сделать частью Xen. Ведётся разработка возможности подчинения внешнего сетевого трафика политикам ACM. Сейчас требуется ручная установка фильтров в домене 0, но этот подход не очень хорошо масштабируется.

Контроль доступа и использования ресурсов

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

На отдельной Xen-системе информация о связи ресурсов и меток безопасности хранится в файле /etc/xen/acm-security/policy/resource_labels. В этом файле полным путям к ресурсам поставлены в соответствие метки. Связь является слабой, и она разрывается в том случае, если ресурсы перемещаются или перименовываются без соответствующих изменений в файле. Работы над механизмами управления и ограничения на использование ресурсов в Xen продолжаются.

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

Метки доменов сохраняются при миграции. Гипервизор-получатель прежде чем разрешить ми миграцию должен убедиться, что метка правильная, и домен имеет право работать (с учётом правил политики Chinese Wall). Тем не менее, сеть между гипервизорами должна быть безопасной. Существуют архитектуры и прототипы, обеспечивающие защиту сети и гарантирующие целостность политик контроля доступа, однако соответствующие патчи пока не включены в основной дистрибутив.

Скрытые каналы

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

Справочная информация

Опции сборки и загрузки

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

Конфигурационные опции верхнего уровня

Конфигурирование выполняется путём редактирования файлов: Config.mk и Makefile.

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

Файл Makefile используется главным образом для настройки набора собираемых ядер. Это делается с помощью строки:

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

Допускается указывать здесь любые ядра, для которых есть соответствующий конфигурационный файл в каталоге buildconfigs/.

Опции сборки Xen

verbose=y
Включить отладочные сообщения, когда Xen обнаруживает неожиданное состояние. Также включает консольный вывод из всех доменов.

debug=y
Включить отладочные сообщения. Подразумевает verbose=y. (Главным образом используется для отлавливания ошибок в Xen).

debugger=y
Включить отладчик Xen. Может использоваться для отладки Xen, гостевых ОС и приложений.

perfc=y
Включает счётчики производительности внутри Xen для важных событий. Счётчики можно сбросить или просмотреть с консоли Xen с помощью специальных управляющих комбинаций клавиш.

Опции загрузки Xen

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


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

nosmp
Выключить поддержку SMP. Эта опция подразумевается опцией `ignorebiostables'.

watchdog
Включить watchdog NMI. Он может сообщать об определённых сбоях.

noirqbalance
Отключить software IRQ balancing and affinity. Это может понадобиться в системах таких как Dell 1850/2850 в которых используются хитрые железные решения для обхода проблем с маршрутизацией IRQ.

~badpage=<page number>,<page number>,...~
Список страниц, которые нельзя использовать из-за того что они содержат плохие байты. Например, если в результате тестирования памяти установлено что байт с адресом 0x12345678 сбойный, в командной строке Xen нужно указать "badpage=0x12345".

~com1=<baud>,DPS,<io_base>,<irq> com2=<baud>,DPS,<io_base>,<irq>~
Xen поддерживает до двух 16550-совместимых последовательных портов. Например: `com1=9600, 8n1, 0x408, 5' обозначает COM1, на скорости 9600, 8 битов данных, без четности, адрес базы ввода/вывода 0x408, IRQ 5. Если какие-то конфигурационные опции имеют значение по умолчанию (например, адрес базы ввода/вывода или IRQ), тогда нужно указывать только часть конфигурационной строки. Если скорость порта сконфигурирована (например, с помощью загрузчика), тогда вместо численного значения можно указать auto.

~console=<specifier list>~
Указать получателя консольного ввода/вывода. Список состоит из значений, разделенных запятыми:

; vga
: Использовать консоль VGA (до тех пор пока не загрузится домен 0, за исключением тех случаев, когда указан vga=keep).
; com1
: Использовать последовательный порт com1.
; com2H
: Использовать последовательный порт com2. У передаваемых символов будет установлен MSB. У принимаемых символов должен быть установлен MSB.
; com2L
: Использовать последовательный порт com2. У передаваемых символов будет сброшен MSB. У принимаемых символов должен быть сброшен MSB.

Последние два позволяют организовать совместное использование порта двумя подсистемами (например, консолью и отладчиком). Совместное использование контролируется MSB каждого передаваемого/принимаемого символа. Значение по умолчанию 'com1,vga'.

vga=<options>
Список опций, разделённых с помощью ;.
; text-<mode>
: Выбрать разрешение текстового режима, где режим может иметь такие значения: 80x25, 80x28, 80x30, 80x34, 80x43, 80x50, 80x60.
; keep
: Сохранять консоль в VGA режиме даже после того как загрузится домен 0.

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

conswitch=<switch-char><auto-switch-char>
Указывает, как переключать последовательную консоль между Xen и доменом 0. Требуемая последовательность -- Ctrl-<switch-char> нажатый три раза подряд. Для того чтобы отключить переключение, нужно в качестве символа переключения указать обратную кавычку. Символ <auto-switch-char> указывает, должен ли Xen автоматически переключать ввод на домен 0, когда загрузка Xen завершится. Символ "x" означает, что автоматическое переключение отключено. Автоматическое переключение включено во всех остальных случаях. Символ переключения по умолчанию это "a".

nmi=xxx
Указывает, что делать с чётностью NMI и ошибками ввода/вывода.
*"nmi=fatal": Xen выводит диагностическое сообщение после чего зависает.
*"nmi=dom0": Уведомить домен 0 NMI.
*"nmi=ignore": Игнорировать NMI.

mem=xxx
Установить предел адресации физической памяти. Память, находящаяся за пределами указанного значения, будет игнорироваться. Параметр может быть указан с суффиксом B, K, M или G, обозначающим байты, килобайты, мегабайты и гигабайты соответственно.

dom0_mem=xxx
Указывает объём памяти, выделяемый домену 0. В Xen 3.0 параметр может быть указан с суффиксом B, K, M или G, обозначающим байты, килобайты, мегабайты и гигабайты соответственно. Если суффикс не указан, подразумеваются килобайты. В предыдущих версих Xen суффикс не поддерживался, и все значения интерпретировались как значения в килобайтах.

dom0_vcpus_pin
Закрепить виртуальные процессоры домена 0 за соответствующими им физическими процессорами (по умолчанию =false).

tbuf_size=xxx
Размер буферов трассировки для каждого процессора, в страницах. По умолчанию 0.

sched=xxx
Выбрать какой планировшик процессора будет использовать Xen. Возможные значения "credit" (по умолчанию) и "sedf".

apic_verbosity=debug,verbose
Выводить более развёрнутую информацию о конфигурации локального APIC и IOAPIC.

lapic
Использовать локальный APIC, даже если он отключен однопроцессорным BIOS'ом.

nolapic
Не использовать локальный APIC в однопроцессорной системе, даже если он включён в BIOS.

apic=bigsmp,default,es7000,summit
Указать платформу NUMA. Обычно она определяется автоматически.

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


acpi=off,force,strict,ht,noirq,...
Указать как Xen (и домен 0) обрабатывают таблицы ACPI BIOS.

acpi_skip_timer_override
Указать Xen'у (и домену 0) игнорировать перекрывающие прерывание теаймера инструкции определённые таблицами ACPI BIOS.

noapic
Указать Xen (и домену 0) игнорировать IOAPIC'и присутствующие в системе и вместо них использовать обычный PIC.

Опции загрузки XenLinux

В дополнение к стандартным опциям Linux поддерживается:


xencons=xxx
Устройство, к которому подключается драйвер виртуальной консоли Xen. Поддерживаются следующие варианты:
* xencons=off: отключить виртуальную консоль
* xencons=tty: подключить консоль к /dev/tty1 (tty0 при загрузке)
* xencons=ttyS: подключить консоль к /dev/ttyS0

Дальнейшая поддержка

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

Другая документация

Разработчикам, интересующими портированием другим операционных систем на Xen, может оказаться полезным руководство Xen Interface Manual, находящееся в каталоге docs/ дистрибутива Xen.

Конфигурационный файл немодифицированных гостевых VMX систем

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

kernel
Загрузчик VMX, /usr/lib/xen/boot/vmxloader

builder
build-функция домена. Домен VMX использует vmx builder.

acpi
Включить ACPI в гостевой системе VMX, по умолчанию =0 (выключено)

apic
Включить APIC в гостевой системе VMX, по умолчанию =0 (выключено)

pae
Включить PAE в гостевой системе VMX, по умолчанию =0 (выключено)

vif
Опционально указывает MAC-адрес и/или бридж для сетевого интерфейса. Если MAC-адрес не указан, он выбирается случайно. Если указать type=ioemu, для виртуализации сетевой карты машины используется эмулятор ioemu. Если тип не указан, используется виртуализация с помощью vbd, как и в паравиртуализированных гостевых системах.

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

phy:UNAME,ioemu:DEV,MODE  ,

где UNAME - это имя устройства в домене 0; DEV - это имя устройства, которое будет видется в пользовательском домен; MODE - это r, обозначающий режим только-для-чтения, или w, обозначающий режим чтение-запись; ioemu означает, что для виртуализации VMX-дисков будет использоваться ioemu. Если не добавлять ioemu, используются vbd как в паравиртуализированных гостевых системах.

Если используется файл с образом диска, применяется такая форма:

file:FILEPATH,ioemu:DEV,MODE

Если используется больше чем один диск, записи, соотвествующие дискам, должны разделяться запятыми. Например:

disk = ['file:/var/images/image1.img,ioemu:hda,w', 'file:/var/images/image2.img,ioemu:hdb,w']

cdrom
Образ диска для CD-ROM'а. По умолчанию это /dev/cdrom в домене 0. Внутри домена VMX, CD-ROM будет виден как устройство /dev/hdc. Эта запись также может указывать на ISO-файл.
boot Загружаться с флоппи-дисковода(a), жёсткого диска (c) или CD-ROM'а (d). Например, для того чтобы загружаться с CD-ROM'а, запись должна выглядеть так:

boot='d'

device_model
Инструмент для эмуляции оборудования для гостевых систем. Этот параметр менять не нужно.

sdl
Включить библиотеку SDL для графики, по умолчанию = 0 (выключено)

vnc
Включить библиотеку VNC для графики, по умолчанию = 1 (включено)

vncviewer
Включить запуск vncviewer (допустимо только при vnc=1), по умолчанию = 1 (enabled)

Если vnc=1 и vncviewer=0, можно подключаться к экрану VMX домена с помощью удалённого vncviewer'а. Например:

$ vncviewer domain0_IP_address:VMX_domain_id

ne2000
Включить ne2000, по умолчанию = 0 (выключено; использовать pcnet)

serial
Включить перенаправление вывода на последовательный порт гостевой VMX-системой на pty-устройство

usb
Включить поддержку USB без включения какого-то конкретного USB-устройства. По умолчанию эта опция равна 0 (выключена), за исключением случая, когда включена опция usbdevice - в этом случае опция равна 1 (включена).

usbdevice
Включить поддержку USB и включить поддержку заданного устройства. Устройства, которые можно здесь указывать это mouse (мышь PS/2), tablet (планшет - устройство абсолютного позиционирования) и host:id1:id2 (физическое USB-устройство на хост-машине с идентификаторами id1 и id2). Преимущество планшета в том, что Windows автоматически его распознаёт и включает его поддержку, поэтому достаточно только указать строку

    usbdevice='tablet'

и в виртуальной системе появится мышь, которая прозрачно работает под VNC. В Linux пока что отстуствует поддержка USB-планшета, поэтому в Linux нужно использовать эмуляцию Summagraphics.

localtime
Установить часы в локальное время (по умолчанию =0, что означает - установить в UTC).

enable-audio
Включить поддержку аудио. Находится в процессе разработки.

full-screen
Запускаться в полноэкранном режиме. Находится в процессе разработки.

nographic
Другой способ перенаправления последовательного вывода. Если включён, не будет работать ни 'sdl', ни 'vnc'. Не рекомендуется.

Создание виртуальных дисков с нуля

На основе физических дисков

В том случае, если используется физический диск или дисковый раздел, сначала нужно установить ОС Linux. После этого нужно в правильное место установить загрузчик. Например, в /dev/sda в случае загрузки со всего диска, или в /dev/sda1 при загрузке с раздела 1.

На основе файлов-образов

Сначала нужно создать большой пустой файл-образ. После этого, нужно установить в него ОС Linux. Есть два метода сделать это:

  1. Непосредственная инсталляция и виртуальной машины VMX. Выполняется загрузка и инсталляция с CD-ROM'а.
  2. Копирование в файл установленной операционной системы. Кроме этого придётся проинсталлировать загрузчик.

Для создания файла-образа: Размер образа должен быть достаточно большим, для того чтобы в него влезла целая ОС. В данном примере предполагается, что размер образа - 1G (что, по-видимому, будет маловато для большинства современных ОС).

# dd if=/dev/zero of=hd.img bs=1M count=1 seek=1023

Для того чтобы непосредственно установить ОС Linux в файл-образ с помощью гостевой VMX-системы:

Установите Xen и создайте гостевую VMX-систему с файлом-образом и загрузкой с CD-ROM. Дальше всё будет как в обычной инсталляции Linux. В конфигурационном файле должны быть такие записи:

cdrom='/dev/cdrom'
boot='d'

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

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

1. Установите обычную ОС Linux на хост-машину. Инсталляцию можно производить любым способом, например, с помощью yum (для Red Hat Linux) или YaST (для Novell SuSE Linux). В дальнейшем предполагается, что операционная система установлена в каталог /var/guestos/.

2. Создайте таблицу разделов. Образ в файле будет восприниматься как жёсткий диск, поэтому нужно сделать таблицу разделов в файле образа. Например:

# losetup /dev/loop0 hd.img
# fdisk -b 512 -C 4096 -H 16 -S 32 /dev/loop0
press 'n' to add new partition
press 'p' to choose primary partition
press '1' to set partition number
press "Enter" keys to choose default value of "First Cylinder" parameter.
press "Enter" keys to choose default value of "Last Cylinder" parameter.
press 'w' to write partition table and exit
# losetup -d /dev/loop0

3. Создайте файловую систему и установите в неё загрузчик GRUB.

# ln -s /dev/loop0 /dev/loop
# losetup /dev/loop0 hd.img
# losetup -o 16384 /dev/loop1 hd.img
# mkfs.ext3 /dev/loop1
# mount /dev/loop1 /mnt
# mkdir -p /mnt/boot/grub
# cp /boot/grub/stage* /boot/grub/e2fs_stage1_5 /mnt/boot/grub
# umount /mnt
# grub
grub> device (hd0) /dev/loop
grub> root (hd0,0)
grub> setup (hd0)
grub> quit
# rm /dev/loop
# losetup -d /dev/loop0
# losetup -d /dev/loop1

Опция -o 16384 программы losetup показывает, что нужно пропустить таблицу разделов в образе. Число равно количеству секторов для пропуска умноженное на 512. Пришлось создать файл /dev/loop, поскольку GRUB'у нужно именно имя диска, которое обозначает весь диск, а имя с номером обозначает раздел; имя1 - первый раздел.

4. Скопируйте файлы операционной системы на образ. Если Xen уже установлен, при копировании файлов на разделы можно использовать программу lomount вместо losetup и mount. Программе lomount просто нужна информация о разделах.

# lomount -t ext3 -diskimage hd.img -partition 1 /mnt/guest
# cp -ax /var/guestos/{root,dev,var,etc,usr,bin,sbin,lib} /mnt/guest
# mkdir /mnt/guest/{proc,sys,home,tmp}

5. Отредактируйте файл /etc/fstab в образе гостевой системы. Файл fstab должен выглядеть так:

# vim /mnt/guest/etc/fstab
/dev/hda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs efaults 0 0

6. Размонтируйте файл-образ:

# umount /mnt/guest

Образ гостевой системы hd.img готов. При их использовании обязательно убедитесь в том, что в них установлен загрузчик.

Инсталляция Windows в файл образа в VMX

Для того чтобы установить Windows нужно указать в конфигурационном файле acpi=0.

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

Редактирование конфигурационного файла Xen VMX

Создайте копию примера конфигурационного файла VMX /etc/xen/xmexample.vmx и отредектируйте строку:

disk = [ 'file:/var/images/guest.img,ioemu:hda,w' ]

в которой замените guest.img на имя файла с образом гостевой ОС, который вы создали.

Создание гостевых систем VMX

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

# xend start
# xm create /etc/xen/vmxguest.vmx

В конфигурации по умолчанию, если VNC включён, SDL выключен. В этом случае для доступа к гостевой системе нужно создавать окна VNC. Если вы хотите использовать SDL, включите его в конфигурационном файле с помощью параметра sdl=1. В этом случае vnc можно выключить, установив параметр vnc=0.

Проблемы с мышью, особенно под VNC

при доступе к виртуальным машинам через VNC существует небольшая проблема с мышью. Проблема связана с тем, что VNC viewer предоставляет виртуальный указатель, для которого известны только его абсолютные координаты. VMX device model преобразует эти абсолютные координаты в приращения движения, которые гостевая система ждёт от драйвера мыши PS/2, работающего в гостевой системе. К сожалению, невозможно сделать так чтобы вычисленные приращения для гостевого курсора точно соответствовали движению указателя VNC. Это может привести к ситуации, когда курсор гостевой системы находится в центре экрана, а курсор VNC уже на краю, и нет возможности подвинуть гостевой курсор левее или правее (в зависимости от того, где находится VNC-курсор).

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

Мышь PS/2 подключённая через порт PS/2.

Эта модель мыши используется по умолчанию. Она прекрасно работает под SDL, однако при доступе через VNC указатель мыши в гостевой системе рассинхронизируется с указателем VNC. Когда это происходит, можно синхронизировать указатели одновременным нажатием левого Ctrl и левого Alt. Когда нажаты эти кнопки, движение указателя VNC не передаётся в гостевую систему, и можно переместить указатель к тому месту, где он совместится с курсором гостевой системы.

Мышь Summagraphics подключённая через последовательный порт.

В device model есть поддержка для планшета Summagraphics, устройства абсолютного позиционирования. Эмуляция выполнятся на втором последовательном порту, /dev/ttyS1 в Linux или COM2 в Windows. К сожалению, ни в Linux, ни в Windows по умолчанию нет поддержки планшета Summagraphics, поэтому гостевую систему вручную нужно сконфигурировать для поддержки этого устройства.

Конфигурация Linux.

Во-первых, настройте службу GPM на использование Summagraphics. В зависимости от дистрибутива, возможно, придётся делать другие действия, но обычно нужно отредактировать /etc/sysconfig/mouse, так чтобы в нём были строки:

MOUSETYPE="summa"
XMOUSETYPE="SUMMA"
DEVICE=/dev/ttyS1

Затем нужно перезапустить демон GPM.

После этого нужно изменить конфигурационный файл /etc/X11/xorg.conf, так чтобы в X появилась поддержка Summagraphics. Нужно добавить строки:

Section "InputDevice"
Identifier "Mouse0"
Driver "summa"
Option "Device" "/dev/ttyS1"
Option "InputFashion" "Tablet"
Option "Mode" "Absolute"
Option "Name" "EasyPen"
Option "Compatible" "True"
Option "Protocol" "Auto"
Option "SendCoreEvents" "on"
Option "Vendor" "GENIUS"
EndSection

После перезапуска X-системы, курсор X должен работать синхронно с указателем VNC.

Конфигурация Windows.

На вопросы нужно отвечать так:

  1. Когда программа спросит model (модель), прокрутите ответы и выберите SummaSketch (MM Compatible).
  2. Когда программа спросит COM Port, укажите com2.
  3. Когда программа спросит Cursor Type (тип курсора), укажите 4 button cursor (4 кнопочный курсор).
  4. Затем гостевая система перезагрузится и, после того когда она снова загрузится, курсор в гостевой системе будет совпадаеть с указателем VNC.

Мышь PS/2 подключённая через USB.

Это точно такая же эмуляция PS/2, за тем исключением, что она выполняется через порт USB.

Эмуляция включается конфигурационным флагом:

    usbdevice='mouse'

Планшет USB подключённый через USB.

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

Эмуляция включается конфигурационным флагом:

    usbdevice='tablet'

Конфигурация Linux.

К сожалению, в настоящий момент поддержка USB-планшетов в GPM отсутствует. Если вы хотите использовать GPM под VNC, нужно настраивать эмуляцию Summagraphics в гостевой системе.

Как настроить поддержку в X11 описывается на странице http://stz-softwaretechnik.com/~ke/touchscreen/evtouch.html только с одним небольшим изменением. В файле xorg.conf на той странице указаны неправильные значения минимумов и максимумов X и Y. Лучше использовать данную секцию:

    Section "InputDevice"
Identifier "Tablet"
Driver "evtouch"
Option "Device" "/dev/input/event2"
Option "DeviceName" "touchscreen"
Option "MinX" "0"
Option "MinY" "0"
Option "MaxX" "32256"
Option "MaxY" "32256"
Option "ReportingMode" "Raw"
Option "Emulate3Buttons"
Option "Emulate3Timeout" "50"
Option "SendCoreEvents" "On"
EndSection

Конфигурация Windows.

Достаточно включить USB-планшет в гостевом конфигурационном файле. Windows автоматически распознает устройство и сконфигурирует драйверы для него.

Поддержка USB

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

Мышь USB PS/2

Для того чтобы включить поддержку мыши USB PS/2, нужно добавить строку в конфигурационный файл:

    usbdevice='mouse'
Планшет USB

Для того чтобы включить поддержку USB-планшета, нужно добавить строку в конфигурационный файл:

    usbdevice='tablet'
Физическое USB-устройство

Доступ к физическому (низкоскоростному) USB-устройству включается путём добавления строки

    usbdevice='host:vid:pid'

в конфигурационный файл. Параметры vid и pid - это vendor id (идентификатор производителя) и product id (идентификатор устройства), уникальным образом идентифицирующие устройство. Эти идентификаторы можно определить двумя способами:

(Существует альтернативный способ указать USB-устройство:

	host:bus.addr

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

1. С помощью управляющего окна. Как сказано ниже, перейти у правляющему окну можно с помощью комбинации клавиш Ctrl-Alt-2 в VGA-окне гостевой системы. Если в конфигурационном файле с помощью строки включена поддержка USB

    usb=1

тогда вызов команды

    info usbhost

в управляющей консоли покажет список всех USB-устройств и их идентификаторов. Например, этот вывод:

    Device 1.3, speed 1.5 Mb/s
Class 00: USB device 04b3:310b

соответствует USB-мыши с идентификатором производителя (vendor id) 04b3 и идентификатором устройства (product id) 310b. Это устройство можно сделать доступным гостевой VMX-системе, если включить в конфигурационный файл строку

	usbdevice='host:04be:310b'

Также можно включить доступ к USB-устройству динамически, с помощью управляющего окна. Управляющая команда

usb_add host:vid:pid

даёт доступ к USB-устройству с идентификатором вендора (vendor id) = vid и идентификатором продукта (product id) = pid.

2. С помощью файловой системы /proc. При определении идентификаторов vendor id и product id можно воспользоваться содержимым псевдофайла /proc/bus/usb/devices. В этом файле в строке, начинающейся с P:, есть поля Vendor= и ProdID= -- это vendor id и product ID соответственно. Например, для мыши файл будет выглядеть так:

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=04b3 ProdID=310b Rev= 1.60
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10ms

Обратите внимание, что строка P: идентифицирует vendor id и product id для мыши как 04b3:310b.

Существует ещё одна проблема, о которой нужно знать, при доступе к физическому USB-устройству из гостевой системы. Ядро домена Dom0 не должно загружать драйвер для устройств с которыми будет работать гостевой домен. Это означает, что драйвер не должен быть вкомпилирован в ядро, а в том случае, если используются модули ядра, модуль драйвера не должен загружаться. Речь идёт только о драйверах устройств. Драйверы контроллеров UHCI и OHCI должны загружаться.

Возвращаясь к примеру c USB-мышью, в том случае, если lsmod выводит текст:

Module                  Size  Used by
usbmouse 4128 0
usbhid 28996 0
uhci_hcd 35409 0

USB мышь используется ядром домена 0, и не доступна гостевым системам. Удалить драйвер мыши из ядра домена 0 и сделать мышь доступной гостевым доменам можно командой

rmmod usbhid

. которая удалит драйвер мыши из домена 0 -- мышь станет доступной в гостевом домене.

Имейте в виду, что система hotplug в Linux перезагружает драйверы, если USB-устройство удаляется, а затем возвращается в систему. Таким образом, простое удаление модуля драйвера будет не эффективно в этом случае. Более надёжный способ: удалить драйвер с помощью команды rmmod и затем переименовать его в /lib/modules, дабы быть уверенным, что он не будет загружаться.

Завершение гостевых VMX-систем

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

poweroff

в консоли гостевой системы. После этого нужно выполнить команду:

xm destroy vmx_guest_id

в консоли домена 0.

Горячие клавиши окна VMX (X или VNC)

Если вы в момент запуска виртуальной машины работаете в среде X, создаётся окно. В этом окне доступно несколько горячих клавиш.

Ctrl+Alt+2 переключает из экрана гостевой системы в управляющее окно. По команде help можно посмотреть справочную информацию о командах доступных в консоли. Например, команда q прекращает работу гостевой системы. Ctrl+Alt+1 переключает обратно на экран гостевой системы. Ctrl+Alt+3 переключает на окно вывода на последовательный порт. В этом окне показаны перехваченные данные, которые гостевая система выводит на последовательный порт. Работает только в том случае, если гостевая VMX-система настроена на использование последовательного порта.

Сохранение/восстановление и миграция

Гостевые системы VMX в настоящий момент нельзя сохранять, восстанавливать и переносить. Эти возможности сейчас находятся в состоянии активного развития.

Vnets - виртуальные сети доменов

Xen опционально предоставляет поддержку сетей для доменов с помощью vnets. Они эмулируют частные сети доменов. Домены, находящиеся в одном vnet'е, могут размещаться на одной машине или на отдельных машинах, и vnet'ы остаются подсоединёнными во время миграции доменов. Ethernet-трафик внутри vnet'а туннелируется внутрь IP-пакетов передающихся по физической сети. Vnet - это виртуальная сеть и адресация внутри этой сети не имеет никакого отношения к адресации в физической сети. Отдельные vnet'ы или vnet'ы и физическую сеть можно соединить с помощью доменов с более чем одним сетевым интерфейсом и включённой поддержкой forwarding'а или bridging'а.

Поддержка vnet включена в xm и в xend. Команда

# xm vnet-create <config>

создаёт vnet на основе конфигурационного файла <config>. После того как vnet создан, его конфигурация сохраняется xend, vnet становится постоянным, и он будет существовать до тех пор пока он не будет удалён с помощью команды:

# xm vnet-delete 

Список vnets, о которых знает xend, можно получить командой:

# xm vnet-list

Другие команды по управлению vnet'ами доступны через программу vn, входящую в дистрибутив vnet.

Формат конфигурационного файла vnet такой:

(vnet (id       )
(bridge )
(vnetif )
(security ))

Пробелы не имеют существенного значения.

Параметры:

  • <vnetid>: vnet id, 128-битный идентификатор vnet. Он может быть задан как 8 4х-разрядных шестнадцатеричных числа, разделенных двоеточиями или, в сокращённой форме, как одно 4х-разрядное число. В последнем случае 7 первых полей заполняется нулями. Идентификаторы vnet id должны быть ненулевыми и идентификатор 1 зарезервирован.
  • <bridge>: имя моста для vnet'а. Домены подсоединяются к vnet'у путём подсоединения виртуального интерфейса к этому мосту. Длина имени моста ограничивается ядром до 14 символов.
  • <vnetif>: имя виртуального интерфейса vnet (опционально). Интерфейс инкапсулирует и декапсулирует трафик vnet в сеть. Он подсоединён к мосту vnet. Длина имени интерфейса ограничивается ядром до 14 символов.
  • <level>: уровень безопасности для vnet (опционально). Уровень может принимать одно из следующих значений
  • * none: нет безопасности (по умолчанию). Трафик vnet передаётся в открытом виде.
  • * auth: аутентификация. Трафик vnet аутентифицируется с помощью IPSEC ESP hmac96.
  • * conf: конфиденциальность. Трафик vnet аутентифицируется и шифруется IPSEC ESP hmac96 и AES-128.

Аутентификация и конфиденциальность поддерживаются в экспериментальном режиме; сейчас в них используются hard-wired ключи.

Когда vnet создаётся, его конфигурация сохраняется xend -- vnet существует до тех пор, пока его не удалят командой:

# xm vnet-delete <vnetid>

Интерфейсы и мосты, которые использует vnet, видны по командам ifconfig и brctl show.

Пример

Предположим, содержимое файла vnet97.sxp выглядит так:

(vnet (id 97) (bridge vnet97) (vnetif vnif97)
(security none))

После этого команда xm vnet-create vnet97.sxp определяет vnet с идентификатором 97 и без обеспечения безопасности. Мост для vnet'а называется vnet97, а виртуальный интерфейс -- vnif97. Для того чтобы добавить интерфейс домена в этот vnet, нужно установить в конфигурационном файле мост соответствующего интерфейса равным vnet97.

В python'е:

vif="bridge=vnet97"

В sxp:

(dev (vif (mac aa:00:00:01:02:03) (bridge vnet97)))

Как только домен стартанул, его интерфейс должен быть виден в выводе команды brctl show в портах vnet97.

Для получения наивысшей производительности стоит уменьшить MTU доменных интерфейсов, смотрящих в vnet, до 1400. Это можно сделать, например, с помощью команды ifconfig eth0 mtu 1400 или установив строку MTU=1400 в файле ifcfg-eth0. После этого может понадобиться удалить кэшированные файлы для интерфейса eth0 в каталоге /etc/sysconfig/networking. Vnet'ы будут работать в любом случае, но производительность может пострадать от IP-фрагментации, вызванной инкапсуляцией vnet'ов и выходом за пределы аппаратного MTU.

Инсталляция поддержки vnet

Vnet реализуется модулем ядра, и модуль должен быть загружен до того как буду использоваться vnet'ы. Это можно сделать до старта xend вручную с помощью команды vn insmod или же настроить xend вызывать скрипт network-vnet, указав в конфигурационном файле /etc/xend/xend-config.sxp строку:

(network-script        network-vnet)

Этот скрипт загружает модуль ядра с помощью insmod, а затем вызывает скрипт network-bridge.

Код vnet по умолчанию не компилируется и не устанавливается. Для того чтобы откомпилировать код и установить его на текущей системе, нужно вызвать make install в корне дерева исходников vnet, tools/vnet/. Также можно установить vnet в инсталляционный каталог с помощью make dist. Подробности об этом можно найти в Makefile в каталоге исходных текстов.

По умолчанию модуль vnet создаёт интерфейсы vnif0002, vnif0003 и vnif0004. Проверить работают vnet'ы или нет можно так: настроить на них IP-адреса и попробовать их с помощью ping. Например, для машин hostA и hostB:

hostA# ifconfig vnif0004 10.0.0.100 up
hostB# ifconfig vnif0004 10.0.0.101 up
hostB# ping 10.0.0.100

Реализация vnet использует IP-multicast для обнаружения интерфейсов vnet, поэтому все машины, на которых есть vnet'ы, должны быть доступны по multicast'у. Сетевые коммутаторы часто сконфигурированы так, что бы не ретранслировать multicast пакеты, это означает что все машины, использующие vnet, должны быть в том же сегменте сети на канальном уровне, за исключением случая, когда сконфигурирован vnet forwarding.

Проверить покрытие multicast можно пропинговав multicast-адрес vnet:

# ping -b 224.10.0.1

Должны прийти ответы от всех машин, на которых работает модуль vnet. Посмотреть передаются ли и принимаются ли пакеты vnet можно просматривая трафик UDP на порту vnet:

# tcpdump udp port 1798

Если многоадресные (multicast) пакеты не передаются между хостами, multicast forwarding можно настроить с помощью vn. Предположим, есть хост hostA с адресом 10.10.0.100 и hostB с адресом 10.11.0.100, и multicast forwarding между ними не выполняется. Настройка передачи между хостами выполняется с помощью vn:

hostA# vn peer-add hostB
hostB# vn peer-add hostA

Multicast forwarding нужно использовать очень осторожно -- нужно избегать петель. Как правило, только одну машину в сети нужно настраивать на передачу (forward), x она будет передавать многоадресные пакеты, полученные от других машин в сети.

Глоссарий

Домен
Домен это контекст исполнения, содержащий работающую виртуальную машину. Отношение между доменом и виртуальной машиной в Xen приблизительно такое же как между процессом и программой в операционной системе: виртуальная машина это постоянная сущность, находящаяся на диске (как программа). Когда она запущена на исполнение, она работает в домене. У каждого домена есть идентификатор домена.

Домен 0
Первый домен, который запускается на Xen-системе. Домен 0 отвечает за управление системой.

Идентификатор домена (Domain ID)
Уникальный идентификатор домена, аналогичный идентификатору процесса (PID) в операционной системе.

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

Гипервизор
Альтернативное название для монитора виртуальных машин, означающее "над супервизором". Термин подчеркивает что монитор виртуальных машин управляет множеством ядер системы, супервизоров.

Живая миграция (Live Migration)
Техника, позволяющая переносить работающую виртуальную машину с одного хоста на другой без её остановки.

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

Теневая таблица страниц (Shadow pagetables)
Техника, с помощью которой расположение страниц в оперативной памяти скрывается от гостевой системы. Используется некоторыми мониторами для создания иллюзии непрерывной физической памяти. В Xen использутся при выполнении живой миграции.

Виртуальное блочное устройство (Virtual Block Device, VBD)
Постоянное хранилище информации, доступное виртуальной машине, представляющее абстракцию блочного устройства хранения. Виртуальным блочным устройством может быть настоящее блочное устройство, образ файловой системы в файле или удалённое/сетевое хранилище.

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

Монитор виртуальных машин (Virtual Machine Monitor, VMM)
Программное обеспечение, позволяющее множеству виртуальных машин одновременно выполняться на одной физической машине.

Xen
Монитор виртуальных машин, использующий паравиртуализацию, разработанный преимущественно исследовательской группой System Research Group Компьютерной лаборатории Кембриджского Университета.

XenLinux
Название порта ядра Linux, работающего под Xen

www.opennet.ru