XEN 4 vs KVM

Это был CentOS 5.5 - сегодня у меня совершенно нет желания с ней связываться еще раз. Они сильные изменения внесли в rhel 5.7, однако, судя по всему, моей проблемы это не решает (лимитирования CPU так и не появилось, а это для меня недопустимо, правда, может упустил, если не прав - поправьте).

Raistlin добавил 24.07.2011 в 20:25

Гм, гм... Ну как же.

Так что как бы... Именно ксен будет нативно в ядре вкомпилен.

в 6, кстати, появилось лимитирование CPU. Про лимитирование IO сейчас сказать не могу, ещё не пробовал. В F15 есть и лимитирование IO, и лимитирование CPU.

Вы, фактически, только что подтвердили то, что я написал. В mainline добавлены драйверы для того, чтобы linux без изменений мог запускаться в dom0, но dom0 -- это тоже виртуальная машина, которую запускает ядро XEN, которое в mainline не войдёт потому что это -- отдельное ядро отдельной операционной системы.

Boris A Dolgov, F15 очень глючная штучка на ином оборудовании. По-крайней мере, десктопная часть - просто ужас (серверную я тестить и не стал, там поглядел, что дефолтные конфиги неадекватны местами).

Я, конечно, извиняюсь, но Dom0 и DomU это будет одно и то же ядро. И, кроме того, это будет само ядро линукса, БЕЗ изменений. Т.е. для конечного пользователя это будет одно ядро. Администратору же следует знать, что Dom0 все же частично виртуализирован.

Т.е. сейчас мы как Xen подключаем? Собираем ядро с нужными модулями и запускаем его.

Будем подключать: тупо собирать ядро без включения сторонних модулей в исходники, на Debian и ему подобных ядро собирать не придется вообще - тупо ставить гипервизор, etc. Касательно РедХат - они будут выпиливать Xen, насколько это возможно. Они отказались поддерживать XEN в 6.0 потому, что "слишком сложно мейнтейнить пакеты двух виртуализаций, мы сосредотачиваемся на одной". Т.е. их заломало по сути собирать ядра и тестировать пакеты и под ядрами с ксеном, и под ядрами без ксена. Но третье ядро исправит ситуацию, однако, RedHat уже похоронил XEN. По сути, они, возможно, и включат его в будущем (правда, я в этом сомневаюсь, так как у RedHat цель похоронить технологию, а не развивать ее).

Raistlin добавил 24.07.2011 в 20:48

З.Ы, в F15 приходилось после ее выхода слишком много допиливать, в том числе и selinux-policy, ибо оно не имело правил для части поставляемого софта в дистрибутиве. да и в остальном - выход ее был продиктован, скорее необходимостью выпустить дистрибутив, чем полной его готовностью (мне известны баги, которые так и небыли закрыты, хотя они имели статус "release blockers")

Raistlin добавил 24.07.2011 в 20:49

И еще проблема: обновить существующую установку 5 ветки не представляется возможным ввиду технических причин. Это сильно осложняет перевод серверов на новую ОС.

Ну не знаю. У меня на ноуте FC15 стоит с alpha-версии (правда, с кастомным более свежим ядром), на трёх нодах стоит та же FC15. Пока все живы. Возможно, некоторый софт там неадекватен, но для виртуализации нужно всего три пакета, которые работают хорошо.

Я, конечно, извиняюсь, но Dom0 и DomU это будет одно и то же ядро. И, кроме того, это будет само ядро линукса, БЕЗ изменений. Т.е. для конечного пользователя это будет одно ядро. Администратору же следует знать, что Dom0 все же частично виртуализирован.

Суть примерно в том, что

Нет. Сейчас мы собираем ядро линукса с нужным патчем/модулем, собираем микроядро xen, запускаем его, запускаем в нём наше собранное ядро Linux. От первого шага мы избавились. Но всю работу по первичному взаимодействию с устройствами, управлению памятью, миграции, приоретизации и шедулингу виртуальных машин по прежнему выполняет микроядно xen, которое не в mainline и поддерживается гораздо меньшим сообществом. Это всё равно что назвать возможность человека нажимать на выключатель возможностью зажигать лампочку, хотя на самом деле возможность эту даёт стороняя электростанция и труд инжинеров.

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

Сказали про одного из крупнейших контрибуторов в линукс :)

Ну соберите qemu+kmod_kvm из F15 для C6, получите примерно то же самое, но без десктопных багов.

Ну, тут уже centos виноват. Могли бы ещё полгода назад ставить сервера на новой платформе :) Но с этой проблемой я достаточно сильно согласен и тоже не представляю, что буду делать с кучей машин на c5 через 2.6 года, когда у него закончится основная поддержка.

Стояла с Rawhide. Потом, когда вышел релиз - перематерился. Например, проблемы в иксах (на Intel GMA, причем на уровне самих иксов, правкой конфига не решаются), проблемы вообще с производительностью на N455 присутствовали иногда, вылет софта (в частности, cheese) ну и по мелочи накопилось. Тоже на ноуте...

Естественно. Поэтому рано или поздно, у ксена жутко пошатнутся позиции. И это время наступит скоро.

Ничего не имею против. Впринципе, для них это корректно.

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

Ух, ух. Вот этого я делать совсем не хочу. Там понадобится обновлять еще компилятор, ну его лесом... Плавал разок. А собирать RPM по всем канонам - ломает, потом еще и поддерживать их - не имею столько времени.

Лимитирование процессора есть в RH 6, впрочем, как и лимитирование (если быть точным - приоретизация) ввода-вывода: http://www.linuxtopia.org/online_books/rhel6/rhel_6_resource_management/rhel_6_resource_management_ch-Subsystems_and_Tunable_Parameters.html#sec-blkio

Касательно Ксена в ядре. Т.е. я так понимаю, это значит, что в 3.0 появились важные компоненты, которые классифицированы как работающий dom0. Т.о. я понимаю, что отдельно переносить ядро на Dom0, как это было ранее не требуется. С ядра 2.6.39 для работоспособности ядра как DomU достаточно включить в конфиге XEN=Y (полная поддержка, без дополнительных танцев в ванильном ядре). Т.е. я так понимаю, ваниль теперь сама по себе может быть скопилирована без дополнительных патчей как работающий Dom0, остается воткнуть в Dom0 пакеты гипервизора и все...

Raistlin добавил 24.07.2011 в 21:36

И, да. У ксена гораздо более интересным является CloudXEN, это более интересная в перспективе технология. KVM никаким Cloud пока похвастаться не может.

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

У меня с i915 тоже были сильные проблемы, но это дистронезависимо -- они его то ломали, то чинили в intel-drm-next, и только в 2.6.39 он по-нормальному заработал в mainline. А Ваша проблема была связана именно с дистрибутивом, или апстримовая?

Да и systemd с приоритетами при параллельной загрузке для старых init-скриптов очень печально поступает.

Согласен, идея была странная. Но компилятор обновлять в данном случае не придётся.

Кстати, моим аргументом может служить кусочек wiki по поводу просто загрузки гипервизора:

title Xen 4.0 with Linux 2.6.32.25 dom0

        root (hd0,0)

        kernel /xen.gz dom0_mem=1024M loglvl=all guest_loglvl=all

        module /vmlinuz-2.6.32.25 ro root=/dev/mapper/vg00-lvroot rd_LVM_LV=vg00/lvroot nomodeset

        module /initramfs-2.6.32.25.img

Boris A Dolgov добавил 24.07.2011 в 21:44

Да, с этим я согласен. Но это оставляет у XEN все его минусы как отдельного микроядра.

Прочитал сайт, не особо понял, что он делает. Умеет мигрировать впску между нодами и динамически нарезать для неё ресурсы? KVM это давно умеет.

Апстримовая. Дистро-независимо, но очень напрягает, когда в дистрибутив впихивают негодный софт. Та же песня в Убунте, а вот дебиан и Центось такими "детскими" болезнями не страдают, но в них приходится пересобирать ядро на что-то по свежее... Сейчас поставил центось, но мне понадобится портировать модули для ENE USB и ATHEROS L1 :(. Правда, пока хватает USB-модема, а кард-ридером просто не пользуюсь, но факт остается фактом. Да, еще на многих ноутах у F15 до сих пор болезнь со спящим режимом (уходит только раз, потом тупо виснет), меня тоже коснулось - довольно неудобно, так как старт всех сервисо достаточно затяжным может быть по времени, а еще иногда я люблю просто захлопнуть крышку ноута и бежать с ним по делам...

Убедили. Правда, я думаю, нужно все же дождаться статуса stable у 3.0, прежде чем делать окончательные выводы. Документации по этим вещам нормальной нет, а читать списки рассылки просто самоубийство по времени.

Raistlin добавил 24.07.2011 в 22:01

Для сборки gnash мне пришлось в свое время пересобрать дофига чего (там куча требований во зависимостям, навроде boost, agg, gstreamer нужен был по свежее, etc). В данном случае, может и правда, прокатит, но сборка нового софта под ЦентОС, даже шестой ветки - вполне весела (ну, я попробовал собрать usb_modeswitch последнюю, в результате сразу же нарвался на грабли с gcc, после этого просто подключил rpmforge).

Это болезнь RHEL дистрибутивов, т.к. у них не предусмотрен более простой переход с одной мажорной версии на другую и обновлять рекомендуют методом полной переустановки дистрибутива. :(

Тоже вот думаю, что делать с серверами на CentOS 5.x и единственная мысль, это всех переселить на новые сервера, а на старых обновить (читать переустановить) ось до шестой версии.