Citrix XenServer: xe-edit-bootloader trick

Иногда нужен доступ в FS гостевой VM (domU). В Citrix XenServer сделано много изменений и фокус, как в обычном Xen тут не проходит.
Самый простой способ (разумеется, речь идет о linux с его FS):
Логинимся на сервер. Далее:
# xe-edit-bootloader -n MyVM -p 1
где MyVM - имя виртуальной машины, 1 - номер раздела, на котором находится /boot (я обычно выношу в отдельный небольшой раздел, первый)

Данная команда позволяет загрузить в текстовый редактор (и отредактировать, конечно) меню grub гостевой VM. Это полезная фича, но есть еще не менее полезное побочное действие: появляется доступ к виртуальному диску из dom0.
Важное примечание - VM должна быть остановлена, иначе ничего не получится.

Citrix Xen: инсталляция RedHat по сети при помощи kickstart

Как известно, технология быстрой установки по сценарию (kickstart) позволяет сэкономить системному администратору массу времени. Я активно использовал эту технологию при установке виртуалок на VMware, но. к сожалению, у Citrix Xen это не совсем тривиальная задача. Проблема осложняется еще тем, что Citrix по непонятной причине не поддерживает PXE boot для PV VM.

Процедура установки по сети и использования kickstart есть в документации на Citrix XenServer. Я опишу просто способ, как наиболее быстро и легко в окружении. подобном моему, это реализовать, и некоторые тонкости.

Итак, окружение:

• в сети есть DHCP сервер


• в сети есть сторадж, доступный по NFS и FTP. Строго говоря, достаточно и FTP, просто по NFS установка происходит заметно быстрее


• есть хост с установленным Citrix XenServer версии 5.6 (я использую последнюю на текущий момент версию 5.6.100 SP2)


• есть хост, на котором запущен XenCenter (им просто удобно пользоваться)

Xen: Реинициализация загрузчика для переинсталяции VM

В Xen столкнулся с проблемой. Создаем новую VM, запускаем инсталляцию и тут по какой-то причине ее приходится прервать (ну, например, изменить параметры загрузчика или вообще не ту версию linux надо ставить). Если просто перезагрузить VM, то она уже не желает грузиться с DVD образа, а сообщает об ошибке: Failed: WARNING: /dev/xvda is not a disk image

Проблема связана с pygrub. Лечится очень просто. Нам понадобится uuid VM (можно посмотреть либо в Xencenter или другой GUI тулзе либо через команду xe). Логинимся на консоль сервера. Далее исправляем содержимое параметра PV-bootloader:

xe vm-param-set uuid=<VM UUID> PV-bootloader=eliloader

Перенос виртуальных серверов VMware на XenServer для Linux guest

Как я уже писал в предыдущей статье мне придется переезжать с VMware. А что делать с виртуалками? Не переставлять же все - у меня их десятки, я полгода переносить буду (с учетом того, что их еще проверить нужно после переинсталляции).

Более логичным и правильным было бы перенести виртуалки через экспорт-импорт. Следует обратить внимание, что, если не соблюдать процедуру, а попытаться просто сделать экпорт виртуалки а потом ее импорт через XenConvert, виртуалка запуститься в HVM-режиме (полная виртуализация). Это-во-первых, замедлит работу виртуальной машины. Во-вторых, у меня обнаружилась бага - если на эту виртуалку подать сеть, подключенную через транк (VLAN) то внутри виртуалки сетевой интерфейс работает некорректно и пользоваться им невозможно.
Поэтому категорически рекомендую использовать паравиртуализацию.

Решение задачи есть на форуме Citrix, я воспользовался именно им, с небольшим уточнением.

Итак, приступим.

Я подразумеваю, что, раз уж админ пользовался VMware, то у него обязательно есть установленный Windows-хост, расположенный где-то рядом с гипервизорами. Тем более, что для CitrixXen понадобится XenCenter, который тоже написан под Windows.

Перво-наперво нам понадобиться пойти на сайт Citrix и вытащить свежую версию XenConvert. Нюанс заключается в том, что только самая последняя версия умеет корректно импортировать виртуалки с гостевой OS Linux (да и то - там все равно нужно делять ряд действий). Подходящая версия - на ниже 2.3.1.2654. Именно эта версия позволила мне произвести конвертацию.

Изменение размеров shared storage в Citrix Xen "на лету"

Пришло время апргейда железа. И оказалось, что гипервизор VMware 3.5 не работает с новыми боксами (мы взяли ProLiant BL465c G7, а с ними работает только VMware4). Фришная лицензия от VMware vSphere 4 тоже не подошла - там держатся только 2 физических CPU максимум по 6 core и не более 4х виртуальных CPU.

И серьезно стал вопрос о выборе нового гипервизора. Реально имеем две альтернативы - Xen (Citrix и XCP) и RHEV (KVM). Свое мнение про них и сравнительный анализ я напишу позже, когда все эксперименты закончатся и будет сделан выбор.

Пока в данной статье я опишу "кусочек" экспериментов. Мне понадобилось изменить размер shared SAN partition на Citrix Xen 5.6 FP1 - на раздел не помещаются снапшоты, а без снапшотов нормально бекап не провести - нужно останавливать виртуалку, что неприемлемо.

Разумеется, изменение размера нужно делать "на лету". Забегая немного вперед, отмечу, что мне удалось сделать это, даже не останавливая виртуалку, запущенную на этом томе!. Честно говоря, дисковой активности в виртуалке не было, т.е. эксперимент не совсем "чистый". И Citrix честно предупреждают, что рекомендуют все-таки виртуалку останавливать "во избежании". Полагаю, что все-таки можно производить ресайз раздела и без остановки, если активность диска низкая. Как-нибудь при возможности попробую провести эксперимент.

Но вернемся к задаче.

Установка Mac Os X в эмуляторе virtualbox на linux

В последнее время все больше народу на просторах бывшего Союза ;) интересуются продукцией Apple. Ну, про iPhone с iPad я рассказывать ничего не буду, зато смогу немного про MacOS X. Точнее даже не про нее, а про то, как с ней познакомиться, не покупая дорогущую железку.

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

К счастью, Oracle очень сильно помог потенциальным любителям надкусанных яблок, включив в virtualbox поддержку MacOS. Официально в эмуляторе можно запустить макос только при условии, что хост-платформа тоже Mac. На деле все оказывается гораздо приятнее - можно установить оригинальный дистрибутив MacOS X в эмулятор!

Информации в сети по этому вопросу много. Однако мне не удалось найти 100%-го решения, на практике пришлось собирать информацию по частям и действовать методом научного тыка. Далее я опишу полностью рабочую последовательность. Разумеется, я не могу гарантировать, что все сработает как надо на другой машине, но у меня все получилось

VMware ESX server 3i (ESXi3)

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

Сейчас VMware раздает бесплатно (необходимо только зарегистрироваться) значительную часть своих продуктов. В частности, весьма интересный ESXi сервер, представляющий собой, по сути, RedHat EL, выпотрошенный по максимуму (убраны практически все утилиты), с прикрученным busybox и набором специфических утилит управления vmware сервером. ESXi сервер позиционируется как "почти хардверное" решение для виртуализации, вход в linux-консоль там даже не предусмотрен (хотя возможен, способ я опишу несколько далее). Управление этим сервером осуществляется посредством VMware Infrastructure Client. К сожалению, работает исключительно под Windows, даже в wine удается только установить, но не запустить, т.к. это чудо написано на .NET. Но есть и открытые perl-библиотеки (API) и набор утилит (RemoteCLI), которые позволяют управлять сервером.

VMware infrastructure 3 vs Xen - первая проба виртуализации (ч.3)

(Часть 2)

Начинаем экспериментировать с VMware:

На одной из нод vmware кластера было отключено питание через iLO карту. Сбой ноды был зафиксирован в течении 1-2х минут. После чего виртуальная машина, которая находилась на отключенной ноде, была перезапущена "с нуля" на оставшейся ноде. Т.е. при физическом падении ноды все виртуальные машины, выполняющиеся на ней, будут перезапущены. С точки зрения конечного пользователя - хост был перезагружен.

После восстановления питания нода поднялась достаточно быстро - в течении 1-2х минут, после чего начался процесс миграции виртуальной машины "на старое место". В момент миграции ОС в виртуальной машине была доступна, однако обнаружилась неприятная вещь - в какой-то из моментов миграции работа практически была остановлена, отклик на пинги вместо обычных 170-200 мс достигал 2 секунд и более! Справедливости ради стоит отметить, что такие большие задержки наблюдались только около 15-20 сек и виртуальная машина мигрировала без перезагрузок, как и было обещано производителем.

VMware infrastructure 3 vs Xen- первая проба виртуализации (ч.2)

(Часть 1я)

Как оказалось, ребята из VMware очень любят гетерогенные сети и окружение :) В том смысле, что VMware ESIx Server построен на базе клона RedHat (RHEL), что сразу же бросается в глаза в процессе установки (характерный инсталлятор - anaconda). С другой стороны - мощная привязка в Windows, т.к. управляющий кластером сервер и админовские тулзы (vmware-viclient) можно развернуть исключительно под этой ОС. Даже wine недостаточно.

Гм. Достаточно неприятный сюрприз :( Обычный vmware-server, отдаваемый бесплатно, имел клиентскую часть как под windows, так и под linux. Это вдвойне неприятно для меня лично, т.к. приходится разворачивать отдельно на своей машине в виртуалке Win XP - иначе не попробовать.

VMware infrastructure 3 vs Xen- первая проба виртуализации

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

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

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