пятница, 30 января 2009 г.

знакомство с XEN

виртуализация томно дышит в спину уже лет 7. До 2005 года, лично я, кроме VMWare других игроков на этом поле просто не замечал. не замечал до тех пор пока не пришёл тяжёлый 2008 год и оголтелая и беспощадная борьба за Лицензию или, что характерно наверное больше для России, против неё. Смертоносные рейды Отделов К, показушные акты сжигания контрафакта, многих заставили задуматься о переходе на опенсорс. вот тогда то многие и открыли для себя XEN. К сожалению в 2008, злыдни из Citrix уже наложили лапу на XEN и проект как это водится разделился на 2 ветки:
1. платная это XenServer
2. халявная это Xen. Ещё можно найти в Интернетах следы того что когда то бесплатная ветка называлась XenSources, но господа из Citrix и из неё сделали (ТМ).

Начиная знакомится с технологией XEN первое что бросается в глаза это не прозрачные намёки что как таковая виртуализация у XEN не совсем виртуальная. Паравиртуализация (а именно так называется технология применяемая в XEN) оказалась совсем не страшной, а очень даже симпатичной "тёткой". Всего то делов, скомпилить 2 Линукс ядра. Тут у многих может дрогнуть рука - "Как так ? а как же такие прекрасные ОС как FreeBSD, Sun Solaris и прочие никсы ?" да увы и ах основная ОС XEN это Линукс, а уж потом обещают всё остальное. и так немного терминологии.
dom0-привилегированное XEN ядро которое реализует паравиртуализацию. Отличается от стандартного линукс ядра наличием поддержки виртуальных блочных устройств XEN таких как: консоли, сетевые карты, диски. К этим самым устройствам в дальнейшем будет обращается Гостевая ОС. dom0 ядро загружается вместо стандартного ядра самым обычным образом из загрузчика. дополнительных телодвижений со стороны пользователя почти не требует.Взаимодействует с пользователем и гостевыми ОС посредством демона xend.

domU-непривилегированное XEN ядро Гостевой ОС. использует ресурсы предоставляемые ему нулевым доменом dom0. Собирается один раз и может быть использовано многократно для разных Гостевых ОС.

Гостевая ОС-система сформирована таким образом что бы использовать ресурсы предоставляемые domU доменом.Как правило (за исключением HVM Гостевых ОС) стартует с загрузочного рам диска предоставляемого доменом U. Хранилищем файловой системы может выступать как файл (самый простой случай) так и другой hdd или массив. Здесь и далее понятия Хост, Host (H) идентичны Гостевой ОС

HVM домен-домен использующий аппаратную виртуализацию. требует от CPU поддержки данной технологии. Благодаря HVM для XEN стала возможна загрузка Windows гостевых ОС


Начал я с того, что скачал книжку. да начал с преступления. ай яй яй яй - какой же я гад. Книжка называется "Xen Virtualization: Practical Handbook" за авторством Prabhakar Chaganti. Индия уже рядом! спросил у гугля кто это? Гугль мне в ответ

Prabhakar Chaganti
Chief Technology Officer at Ylastic
Greater Atlanta Area
нормально. шефам мы доверяем.
Надо сказать что до книжки были всосаны все выше приведённые ссылки на ресурсы про XEN и в голове творился не хилый винегрет. Не буду описывать как я фейлил при конфигурации dom0 ядра, как я его пересобирал раз 20. Это понятно от глупости.

Просто несколько замечаний.

Сборка initrd для domU
mkinitrd -v -f --with=ide-disk --with=sd_mod \
--with=ide-generic \
--with=ext3 \
--with=scsi_mod /boot/initrd-2.6.16.38-xenU.img 2.6.16.38-xenU
Собранный таким образом модуль прекрасно работает, но почему то не запускает Гостевую ОС, если диски которые уже стоят в системе именуются /dev/sda /dev/sdb /dev/sdc итд. То есть диски подключены как SCSI устройства. Эта инициатива Линукс бригады, по унификации интерфейса взаимодействия дисковой подсистемы, здесь выходит боком для XEN. При старте Гостевой ОС, XEN пытается выделить ноды в дереве устройств как /dev/sdX и очень расстраивается когда выделить ничего не может ибо они уже заняты.
Как подсказал форум разработчиков XEN. Для версии 3.*.4 достаточно так

mkinitrd -v -f --with=xennet \
--with=xenblk \
--omit-scsi-modules \
/boot/initrd-2.6.16.38-xenU.img 2.6.16.38-xenU
Обьясняется просто. Начиная с версии 3.0.4 разработчики XEN рекомендует использовать следующий устройства:xvc,xvd
# If you're using a newer version of the Xen guest kernel you will
# need to make sure that you use 'xvc0' for the guest serial device,
# and 'xvdX' instead of 'sdX' for serial devices.
#
# You may specify the things to use here:
#
# serial_device = tty1 #default
serial_device = xvc0
#
# disk_device = sda #default
disk_device = xvda
#

это кусок конфигурационного файла проекта xen-tools. Тулзы этого проекта очень помогают в оперативном создании новых Гостевых ОС. К сожалению именно в этом случае, простота хуже воровства, она скрывает от пользователя XEN ряд моментов связанных с созданием дерева устройств и копирование библиотек ядра domU в дерево Гостевой ОС и настройку её сетевых интерфейсов. Тут главное во всю применят правило "на тулзу надейся а сам не плошай" и хотя бы раз создать Гостевую ОС руками.
С задействованием новых блочных устройств не забываем поправить конфиг H

root = '/dev/xvda2 ro'
disk = [
'file:/var/vm/domains/debian/debian.swap,xvda1,w',
'file:/var/vm/domains/debian/debian.4-0.img,xvda2,w',
]



И так ОС завелась? но не всё так гладко. Достаточно часто на форумах встречается проблема что Гостевая ОС не "высаживает" консоль. Это имеет место быть с H CentOS 5.* . Лично мне не хватило ни терпения не времени это победить (даже описанный мною ниже метод с прописыванием xvc0 в нужные места для CentOS 5.* не сработал). В этом случае у вас способов достучатся до Гостевой ОС ровно один - удалённый терминал: ssh, telnetd, vnc. НО! и тут может быть не всё так гладко.у H на базе Debian Etch 4.0 rc3 достаточно устойчива проблема вида PRNG is not seeded. Генератору случайных чисел не может достучатся до источника случ. последовательностей (энтропии??? не уверен что это понятие здесь уместно). Источники следующие:
/dev/random
/dev/urandom
/etc/entropy
Казалось бы в чём проблема? увы для меня оказалось открытием что SSH даже после генерации ключей плотно завязан на эти источники и если они не доступны SSH просто не запустится. И если так совпало что консоль не высадилась и SSH не запустился (looooooozer) остался telnetd, vnc. задача тривиальная и силь ву пле вы уже в гостях. те в Гостевой ОС. Для того что бы побороть PRNG is not seeded достаточно выполнить в H следующие команды
/dev/MAKEDEV generic
/dev/MAKEDEV std
вторую команду выполняет и Xen-Tools но её почему то не хватает.

Проблема с высадкой консоли решается достаточно просто. getty пытается выводить информация через устройство /dev/tty1 которое не доступно. смотрим в /etc/inittab
1:2345:respawn:/sbin/mingetty tty1
Достаточно заменить tty1 на xvc0 и вписать еёже в /etc/securetty
echo xvc0 >> /etc/securetty
И консоль после рестарта не заставит вас ждать.


Вот так коротко о том на чём я споткнулся. Понятно что если разворачивать хостинг на основе XEN то удобно сделать некий универсальный образ H + конфиг к нему и потом по необходимости его множить. Постоянно собирать/обновлять основу для этого образа можно и с помощью Xen-Tools но я бы рекомендовал присмотреться к ресурсу JailTime я попробовал - остался доволен. Единственное что нужно поправить это настройки сети H да и то только в случае если у вас не DHCP.

Что понравилось.
1. Скорость работч Гостевых ОС.
2. Скорость перезагрузки Гостевых ОС.
3. перспекивы проекта.



Проблемы XEN. сугубо личный список.
1.поддержка Win OS исключительно в HVM домене.
2.масса проблем с запуском BSD based OS. или это проблемы этих ОС ? хз
3. ....в работе

Комментариев нет: