January 4th, 2012

404

киберпанк

Предлагаю включить "частичное моральное устаревание в течение 10 лет с момента выхода" в список формального описания киберпанка.

(Свежайший пример - GITS, в котором используют оптико-механические носители как основной оффлайновый метод передачи информации).
404

sudo - Ошибка проектирования

Кстати, команду sudo я считаю одной из очень неудачных по архитектуре.

Скажите, читающие господа-админы, кто из вас знает её синтаксис более-менее целиком? Нифига. Гугль, гугль, гугль. А ведь это инструментарий разграничения доступа! Его должен знать каждый админ?

Итог - ошибочная архитектура, слишком сложная для steady learn (сравните с элегантностью архитектуры ssh, где человек начинает с тривиального ssh user@host, а потом плавно переходит на ключики, туннели, scp, локальный и глобальные конфиги, отзывы ключей и т.д.).

Она ошибочна не по функционалу, а по human-learning-interface (такой термин вообще есть?) - то есть ожидания проектрировщиков программы отличаются от обычного learning pattern пользователей. Это ошибка. Ошибка проектирования, не кода.
404

kronos [4/256]

Итого, текущие проблемы: не работает создание дефолтных шаблонов, не подхватываются SM, неправильно сконфигурирован dom0 uuid.

/usr/lib/xen-common/xapi/libexec/create_templates
Fatal error: exception Unix.Unix_error(20, "connect", "")

Судя по сообщению, приложение не может найти сокет xapi.

xapi в пакетированном xcp слушает на
unix 2 [ ACC ] STREAM LISTENING 87007 5537/xapi /var/lib/xcp/xapi

А в цельнозерновом
unix 2 [ ACC ] STREAM LISTENING 14568 7313/xapi /var/xapi/xapi

(я не знаю, можно ли делать симлинки на сокеты...)

ln -s /var/lib/xcp/xapi /var/xapi/xapi

Ха, сработало!

Итак, одна проблема решена. xe template-list заработал.
404

kronos [5/256]

Следующая проблема - не подхватывается SM.

Для тех, кто это читает, в кратце: SM - фреймворк на питоне по управлению дисками виртуалок. Блочные устройства делает xapi (на окамле), а вот сами диски (которые цепляются к VM) вынесены в отдельную библиотеку, с мыслью, что любой вендор с лёгкостью напишет свой собственный SM. Т.к. это набор питоновских файлов, то он просто "цепляется" (кем? когда?) из каталога. В зерновом xcp, оно называется /opt/xensource/sm. В пакетированном - /usr/lib/xen-common/xapi/sm/.

Исходя из предыдущего опыта, можно говорить, что на самом деле его ищуют где-то в /usr/lib/xcp/*.

Но вот где именно - не понятно. Либо в /usr/lib/xcp/xapi/sm, либо d /usr/lib/xcp/sm.

Традиционно, играюсь с симлинками, ура, правильное местоположение - в /usr/lib/xcp/sm.

Итого - все составляющие для начала работы (создания VM) созданы. Портирование скрипта установки dom0 uuid можно чуть отложить, оно не критично.
404

kronos [6/256]

Ок, с косметикой закончили, оно стартует, sm'ы на месте, сетки есть, пифы есть, осталось создать SR:

xe sr-create type=file device-config:location=/mnt name-label=store
Error code: SR_BACKEND_FAILURE_61
Error parameters: , File SR creation error,

Выяснилось, что ему не нравится каталог lost+found. Не знаю, баг это или нет.


PS Первая машина пошла в установку! Банзай, товарищи!

ЗЗЫ Судя по тому, что я читал в рассылку, там огромные проблемы с LVMoISCSI из-за патченного LVM...
404

kronos [7/256]

А вот теперь начинается всё самое интересное...

xe vm-migrate vm=first host=kronos4
The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem.
message: INTERNAL_ERROR: [ XenguestHelper.Xenctrl_domain_restore_failure(1, " Unable to get platform info.\\\"") ]

host-list содержит все данные. Моё текущее предположение - не выставлен dom0 uuid.

Проверяем (выставим uuid вручную в питоне)

... Упс, а у нас нет "xen.lowlevel.xc" из коробки. Неприятненько...

find /usr -name "*lowlevel*"
/usr/share/pyshared/dbus/lowlevel.py
/usr/lib/python2.6/dist-packages/dbus/lowlevel.py
/usr/lib/xen-4.1/lib/python/xen/lowlevel


То есть он есть, но не установлен как питоновский модуль...
404

kronos [8/256]

... Интрига становится всё интереснее. Отсутствие в xenstore uuid'а - плохо, но у dom0 uuid выставлен.

Для этого пришлось сделать

ln -s /usr/lib/xen-4.1/lib/python/xen /usr/lib/python2.7/xen

И, вдруг,

for a in xc.domain_getinfo(0)[0]['handle']: print "%.2x"%a,

Оно совпадает с тем, что в /etc/xcp/inventory.

Таким образом, у нас обнаруживается две нетривиальные проблемы: нерегулируемая память у dom0 посредством xe и проблемы с loopback-миграцией виртуалки.

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

first 2 256 1 ---ss- 1.6

Насколько я могу понять его, это shutdown, а вот что второе 's' означает, я даже и не знаю...

Итак, локальная задача - выяснить что это за состояние.
404

kronos [9/256]

Итак, dive into sources.

cd /tmp
apt-get source xen-utils-4.1
cd /tmp/xen-4.1.1/tools/libxl

файл xl_cmdimpl.c:
                info[i].shutdown ? 's' : '-',
                (shutdown_reason >= 0 &&
                 shutdown_reason < sizeof(shutdown_reason_letters)-1
                 ? shutdown_reason_letters[shutdown_reason] : '?'),
                info[i].dying ? 'd' : '-',


Ну и shutdown_reason_letters:

xl_cmdimpl.c: static const char shutdown_reason_letters[]= "-rscw";

Итого: 's' - первая 's' shutdowned (как мы можем видеть из xc.domain_getinfo), вторая - код 's'. Что он значит - ещё выясним, но известно, что это всего лишь код, который передала гостевая машина при вызове гипервызова скедулера зена и операции скедулинга shutdown.

(кстати, заодно, выяснилось, что у xl list есть опция -v. Добавили в xen-4.x, в нашем 3.4 его нету).

Дальше, видимо, гугль нам в помощь. Гуглить такой вопрос, кстати, очень сложно.

Нашёлся сайт xen-tools.org (внезапно). Ушёл читать всё, что там есть... Сайт про какой-то перл.

Альтернативный подход - греп по reason нас наводит на SHUTDOWN_suspend