знакомство с 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. ....в работе

865

именно столько стоит новый билет в московском метрополитене на 60 поездок. покупая поглядел сколько стоит билет на 70 поездок. оказывается 850. прихуел. но разгадка нашлась в несложной калькуляции.

70 поездок
календарный месяц (да этот билет ровно на 31 день) - 850 р.(старая цена 620 рэ (???))


60 поездок
45 дней - 865 р. (старая цена 580 рэ)

обычно редко кто в ДС выкатывает за месяц 60 поездок (не говоря уже про 70 поездок). так как обычный планктонный житель белокаменной ездит 21 день с работы на работу (42 поездки) + куда нибудь заедет покутить это допустим ещё 10 поездок.

Итого: 52 поездки. 8 поездок по средней цене 14.5 рэ идут в подарок метрополитену а это 115 рублей. допустим это пол миллиона человек: получим 115 *500 000 = 57500000 рублей.

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

И вот под предлогом очередного поднятие цен метрополитеновцы сделали хитрый манёвр.
Немного подняли цену на невыгодный, для метрополитена,60 поездочный белет, до 865 рублей. Сделав его в глазах сограждан, которых обычно держат за быдло, ещё более не выгодным по сравнению с 70ти поездочным за 850. эта политика как бы кричит нам

Гражданин! посмотри что мы для тебя сделали! снизили цену на самый долгоиграющий билет. Теперь 70 поездок - Выгоднее!

за этим тихо замалчивается сколько не истраченных поездок гражданин подарит метрополитену. Кого пытаются наебать не понятно. сами себя ради что.

Full Metal Jacket

цитаты из сабжевого кино.

http://www.imdb.com/title/tt0093058/quotes

про Postfix

по работе пришлось столкнутся с Postfix. версия последняя - самая пропатченая, читай навороченная/правильная. По ходу настройки возникали разные чувства от изумления до приступов рвоты. Но самые приятные впечатления вызвало тестирование.
вот это

undisclosed_recipients_header

нахуя же оно по умолчанию включено? Ну нету у меня поля СС, и что теперь я должен в каждом письме лицезреть результат больного разума вида "undisclosed-recipients" ? мне оно ни к чему.
Вообще запоздавшее предисловие.

Я сам изначально размышляю в способах/методах Sendmail. Так получилось что узкая тропинка, как бы не петляла, но всё равно приводила меня к мысли что Sendmail проще. Проще естественно мне. Проще настраивать, Проще обслуживать. Несмотря на нетривиальную процедуру сбора с сорцов и не всегда прозрачные опции он мне нравился и продолжает нравится.

Рейт процессор anvil за него огромное спасибо. Мало того что он прекрасно делает то для чего написан так он ещё и помогает в борьбе за внутренюю чистоту сети, помогая выявить троянов, злоупотребляющих почтовым трафиком в LANах. В этом плане шлимыл ещё только идёт в школу. Но с другой стороны Sendmail не нуждается в такой камасутре как strict_rfc821_envelopes так как имеет свой мощнейший канонификационный процессор. Если у доп ПО которое вы хотите прикрутить к Postfix нету мильтера то извольте ебаться. И не просто ебаться, а виртуозно. Самописные костыли типа amavisd спасают только на слабо нагруженных системах. На системах с потоком писем более 500 000 в сутки амавис превращает работу в танцы вокруг ручечек подкручивающих всевозможные timeout. Это ни есть гуд. Постфиксу сильно не хватает мильтер API. С другой стороны, в плане фильтрации HEADER/BODY писем у Постфикса есть прекрасный набор инструментов, так называемый JUNK MAIL CONTROLS вида

header_checks = regexp:/etc/postfix/checks_header
mime_header_checks = regexp:/etc/postfix/checks_mime_header
body_checks = regexp:/etc/postfix/checks_body

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

из всего описанного сложно составить цельную картину, так как знакомство моё было первым и увы не продолжительным. У каждого из описанных МТА есть множество своих как плюсов так и минусов. каждый для себя выберет сам что ему пользовать.
...
в работе.

Google First Production Server

прелесть