January 2nd, 2012

404

kronos

Ну, поехали.

начинаю исследовать kronos на стабильность и пригодность к дальнейшему запиливанию. Потому что при всём уважении к xapi, использование centos'а как базы для - реально бесит.
404

kronos

Фикшу мануалы по установке по-чуть-чуть, настраиваю.

Знаете, у меня первый раз в жизни такая ситуация - я ВПЕРВЫЕ настраиваю что-то (считай, изучаю), а за мною писец какой экспириенс и понимание того, что происходит вокруг. И в реальном мире оно происходит в полнейшей и абсолютнейшей гармонии с идеальной моделью в голове.

Круто быть гуру.

ЗЫ Я прекрасно понимаю границу собственного нубства, если я до сих пор путаюсь в refcounter'ах в SM и так и не дочитал кода миграции...

ЗЗЫ Как только споткнусь (то есть модель в голове разойдётся с реальностью, напишу).

Пока что единственный непонятный вопрос - почему после перезагрузки после установки xcp-пакетов у меня dom0 uuid:
sudo xenstore-read vm
/vm/00000000-0000-0000-0000-000000000000

В обычном XCP это делает специальный шелловый скрипт при загрузке, а тут его почему-то нет. Ща буду изучать как оно устроено в пакетах.
404

kronos [1/256]

Итак, начинаем. Предыдущий вопрос - почему uuid у dom0 не соответствует uuid'у из /etc/xcp/xensource-inventory.

Ответ: в отличие от нормального XCP у них нет в поставке скрипта /etc/init.d/xen-domain-uuid, который, собственно, из /etc/xcp/xensource-inventory его и выковыривает (и выставляет).

Заметим, выставляет он его с помощью команды /opt/xensource/bin/set-domain-uuid (которая внутри - всего лишь шелловый биндинг к xc.domain_sethandle).

В пакетированном xcp (в отличие от зернового) такого файла нет вообще.

Почему это важно? Если честно, я не знаю тонкостей взаимодействия XCP и dom0, возможно, что оно может привести к невыполнению операций класса vbd-plug для dom0 и vdi.
404

kronos [2/256]

Ну, собственно, после приятного "оно запустилось" приходит первая серьёзная проблема: у нас отсутствуют SM (storage manager'ы) и нет ни одного pif'а (и это при живой-то management network). Это уже очень серьёзная заявка на проблемы, так что я думаю, что сначала попробую покопаться в готовых "howto" и только после этого разбираться в сути проблемы.

(кстати, задумался, что я не знаю, каким образом xapi формирует pif'ы в зерновом xcp).

UPD, ок, небольшой кусочек знаний. Есть команда pif-scan, которая, собственно, и исполняется при приёме хоста в пул (ну и при первом запуске в зерновом XCP). В пакетированном это нужно делать руками.

ОК, задача с pif'ами решилась. Вопрос с SM остаётся крайне интересным...

Картинка для привлечения внимания:



UPD: Оказывается, нужно ещё исхитриться с конфигурированием сети: нужно во-первых перепрописать xe pif-configure-ip (согласно конфигурации бриджа из networking), а во-вторых назначить его как management для xapi.
404

kronos [3/256]

C sm немного не понятно - с одной стороны у нас он есть (пакет xcp-storage-managers, файлы в /usr/lib/xen-common/xapi/sm, там вполне прилично есть), с другой стороны оно не видится.

Обнаружилась ещё проблема:

/etc/init.d/xcp-xapi restart
* Restarting The XenAPI server xapi md5sum: /var/lib/xcp/templates.md5: no properly formatted MD5 checksum lines found
/etc/init.d/xcp-xapi: 198: /usr/lib/xcp/lib/regenerate-templates: not found
md5sum: /usr/lib/xcp/lib/create_templates: No such file or directory


Что наводит на мысль, что ему хочется не xen-common, а /usr/lib... Надо изучить сначала вопрос со стартом, а потом уже возиться с SM.

UPD:
проблема ерундовая - пути в init.d-скрипте, вместо /usr/lib/xcp/lib, надо /usr/lib/xen-common/xapi/libexec/

UPD#2: они там хотят /etc/xensource-inventory... С ним какой-то хаос. В зерновом XCP у нас был /etc/xensource-inventory, а в пакетирванном у нас теперь:

а) из руководства в вики - /etc/xcp/xensource-inventory
b) появившийся непонятно откуда /etc/xcp/inventory
c) требуемый в скрипте /etc/xensource-inventory

Короче, разброд, шатание и жизнь на грани термодинамической смерти.

Судя по выводу xe pool-list, xapi считает главным /etc/xcp/inventory (логично). Остальное надо симлинками, видимо, до полного исправления.
404

Гитсовое

Сел пересматривать. Восхитительно, конечно. Но, некоторые вещи не понятны. Почему, например, у них на номерах машин шрих-кодов нет?
404

криптономикон

Кстати, в исторической части (которая касается машин и шифров) до какой степени он достоверен? Особенно интересует порядок размышлений о "мета-машине" у участников... Если оно правда, то мне придётся чуть-чуть пересмотреть свои представления об эволюции компьютерных систем.
404

GITS SAC

Блин, только я его сел пересматривать, как обнаружил, что он incomplete. Торрент качается, но со скоростью 30-500кб/с, что для оставшихся 25% из 33Гб - ужасъ и смерть.

Кто имеет Rising Sun'овский релиз, посидьте, пожалуйста.