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

Зачем оно надо? Ну, к примеру, хочется иметь привычный Linux в качестве основной операционной системы, а вокруг полно всяких устройств, которые хотят либо Windows, либо Mac, а под Linux наотрез отказываются работать.

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

К счастью, Intel дала нам возможность создавать не просто виртуальные машины, а такие "полувиртуальные", когда ОС может работать напрямую с теми железками, котоые ей определит пользователь.  Называется такая технология "виртуализацией вводв-вывода" (Virtualization Technology for directed I/O), и доступна не только в Hi-End сегментах рынка, как можно бы было подумать, но и на самых обычных бюджетных китайско-тайваньских "мамках" наподобие Gigabyte GA-Q35M-S2.

В плане софта дело обстоит несколько хуже: не так уж много ОС поддерживают нормальную работу такого "зоопапрка" на одном компьютере. Из свободного ПО можно на данный момент выделить 2 продукта:

• Linux KVM - встроенная система виртуализации Linux. Начиная с версии 2.6.28 ядро научилось работать с отображением DMA, являющимся основой виртуалтизации периферии.
• Xen - гипервизор с открытыми исходными кодами, отличие от KVM не требующий т.н. "хостовой ОС", а работает непосредственно на аппаратном обеспечении, разделяя ресурсы одного физического компьютера на несколько виртуальных машин, называемых доменами.

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

Домены бывают двух типов: ведущий (Dom0, он всегда один в системе) и ведомые (DomU, их может быть несколько). Ведущий домен загружается в первую очередь и управляет ведомыми доменами, а также самим Xen, содержит драйвера устройств, которыми пользуется Xen, чтобы выделять ведомым доменам часть ресурсов, предоставляемых ведущим доменом. Поэтому, зачастую, ведущий домен отождествляется с хост-системой в традиционных системах виртуализации, хотя на самом деле, он представляет собой виртуальную машину.

Xen поддерживает две технологии виртуализации:

• Паравиртуализация, это когда операционные системы специально адаптируются для работы в Xen. На сегодня имеются Xen-версии ОС Linux, NetBSD и Solaris (OpenSolaris) и ведутся работы по переносу других свободных ОС.
• Аппаратная виртуализация, это виртуализация на уровне самого "железа". Большинство современных компьютеров имеют процессоры с встроенной поддержкой виртуальных машин, но материнских плат с поддержкой виртуализации периферии пока немного. Но, при желании, такую  всегда можно найти даже, как было сказано выше, среди бюджетных моделей.

Ведущий домен в Xen всегда паравиртуален. Могут использоваться ОС Linux, NetBSD и Solaris (OpenSolaris), но большинство интересных возможностей доступно только под Linux.

• Компьютер с материнской платой, поддерживающей технологию Intel VT-d. Без VT-d также все будет работать, но не будет возможности разделять физические устройства между доменами. Будут доступны только виртуальные устройства, эмулируемые qemu-dm, эмулятором периферии, входящим в поставку Xen. AMD IOMMU не тестировался, но официально поддерживается Xen. В нашем примере использовалась материнка Gigabyte GA-Q35M-S2 с последней версией BIOS (F7). Версии ниже F4 не содержат таблиц DMAR, соответственно, виртуализация периферии недоступна.
• Процессор Intel с поддержкой технологии VT (Vanderpool). Без VT не будет возможности устанавливать "обычные" ОС (типа Mac OS X или Windows), а только паравиртуальные машины. AMD Pacifica не тестировалась, возможно и будет работать.
• Установленный дистрибутив ОС Linux. По вашему вкусу. В данном примере будем использовать Arch Linux x86-64 (Arch64).

7) Собираем ядро. Если все прошло удачно, устанавливаем модули командой "make modules-install". Файл ядра arch/boot/x86/bzImage кладем в папку /boot под именем vmlinuz-xen.

8) Настраиваем GRUB:
Разумеется, настройки файловых систем, и параметров ядра нужно поставить свои .

9) По умолчанию при старте xend упорно пытается перевести сетевую карту в режим моста,но, при наличии нескольких сетевушек, делает это довольно криво. Запретим эту возможность, заменив содержимое скриптов network-bridge, network-nat, network-route, vif-bridge, vif-nat, vif-route в /etc/xen/scripts на строки:

Впоследствии мы cможем наполнить их чем-нибудь полезным, а сеть настроим собственными силами с помощь все тех же bridge-utils.

10) В обязательном порядке запрещаем автозапуск любой графической оболочки при загрузке ОС. Это необходимо, чтобы избежать возможных проблем с переключением в графический режим под Xen (актуально для некоторых бортовых карт Intel).

11) Перезагружаемся. Если все пройдет удачно, то наш Linux работает под управлением Xen в ведущем домене, и у нас появилась возможность создавать ведомые домены.

12) Если вы используете бортовую видеокарту от Intel, то, возможно, столкнетесь со следующей проблемой: после загрузки Xen с iommu=1 экран становится зелено-полосатым  (или показывает любой другой мусор) и будет настойчиво отказываться показывать что-либо еще (в адресах 0B8000h-0BFFFFh обнаруживаются неизменяемые байты 0FFh, что говорит о том, что видеопямять отобразили куда-то "не туда"). В этом случае придется патчить Xen на предмет запрета отображения DMA для бортовой видеокарты. Будем использовать то же метод, что и использует обычный Linux, поддерживающий DMAR.

Берем вот этот патч. Прежде чем применять его к дереву исходников Xen, ищем в нем строку "/* UGLY HACK */", и,  в строке ниже if ((bus == X) && (path->dev == Y) && (path->fn == Z)) вместо X:Y.Z вписываем номера шины, слота и функции нашей видеокарты, которые можно узнать с помощью утилиты lspci. Там стоят 0:2.0, ибо бортовая карта почти всегда размещена во втором слоте, тогда заменять ничего не нужно . После этого применяем патч и пересобираем Xen. Проблема должна исчезнуть, и Linux должен нормально загрузиться.

13) Пытаемся запустить X Window и графическую оболочку. Если она запустилось нормально, то у нас все замечательно, восстановим автозагрузку, и можно переходить к пункту 17. Если нет, то пытаемся запустить иксы в режиме VESA. Разумеется, со всеми аппаратными ускорениями придется расстаться, но, если вы пользуетесь набортной картой, то, вероятнее всего, они вам и не особо нужны.

14) Если у вас бортовая карта от Intel, а монитор широкоформатный и иксы никак не желают стартовать, а в режиме VESA наблюдаются диспропорции экрана, то ищем утилиту 915resolution.  К сожалению, автор ее забросил, но есть сторонние патчи для поддержки новых чипсетов. Уже пропатченную версию можно взять тут. Собираем утилиту.

15) Возможно, потребуется удалить драйвер intel-agp. Если он собран модулем, просто удаляем файл модуля, иначе исключаем драйвер из конфигурации и пересобираем ядро.

16) Запускаем "915resolution -l".  Видим список режимов, поддерживаемых BIOS. Теперь выбираем наиболее близкий режим к желаемому и выполняем команду "915resolution <режим> <ширина> <высота>".   Пропатчатся также все остальные режимы с разрешением изменяемого режима на выбранное. Ничего бояться не следует, ибо эта утилита патчит не саму BIOS, а ее образ в ОЗУ. Соответственно, и запускать ее надо всякий раз при загрузке компьютера. Запускаем иксы, и проверяем, что все работает как надо.

17) Настраиваем список устройств для основного домена (нашего Arch Linux).  По умолчанию основному домену выделяются все ресурсы компьютера. Часть их можно исключить. Во-первых, можно лимитировать Linux по памяти, передав Xen параметр "dom0_mem=XXXX". Во-вторых можно отключить часть PCI(-E) устройств, передав ядру Linux (именно ядру, а не Xen!) параметр "pciback.hide=(B1:D1.F1)(B2:D2.F2)...", эти устройства Linux будет игнорировать и драйвера для них не загрузит. В последствии мы можем их отдать другим доменам. Итак, смотрим список PCI-устройств командой "lspci" и правим конфигурацию GRUB:

В данном примере мы скрыли от Linux сетевую карту (0:19.0), один из контроллеров USB (0:1a.0, 0:1a.1, 0:1a.2 и 0:1a.7), и бортовую звуковую карту (0:1b.0). Второй же контроллер USB, звуковая карта, стоящая в слоте PCI и вся остальная периферия осталась в ведении Linux. Для удобства вывод бортового звука можно направить на ввод основной звуковой карты, как это раньше делали с TV-тюнерами, имеющими только аналоговый звуковой выход и слушать в одних наушниках звук от всех доменов. Память урезать не будем, положимся на balloon-драйвер, динамически отдающий память от Dom0 к Xen по запросу.

18) Перезагружаемся, и видим, что отключенные устройства в системе не видны (хотя их по-прежнему можно посмотреть командой lspci).

19) Настраиваем на Linux интерфейсы-мосты с помощью bridge-utils. Делаем основной интерфейс мостом. Скрипты Xen будут работать с ним автоматически, достаточно прописать имя интерфейса (br0, к примеру) в файле конфигурации домена.

20) Монтируем файловую систему /proc/xen (а как все настроим, пропишем в /etc/fstab) и запускаем xend:



Все. Наш Xen готов к работе!