January 7th, 2012

404

Kill me baby

Цукоми-комедия с sd-персонажами. На замену nichijou не катит, но пока всё-таки смотрябельно. Кстати, там в качестве закадрового голоса подружка девочки с порно-шортиками.
404

Shin Tennis no Ouji-sama

Оно ещё более нездорово-яойное (такой сёдзе-стиль, в котором основным устремлением всех male-персонажей является е..ля мозга). Ну и типовое для такого стиля самолюбование персонажами.

С одной стороны у нас нет споконов, с другой стороны, не факт, что я это выдержу сколь-либо долго.

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

Пожалуй, оно будет замечательным примером сёдзе-мозгое..ва.
404

dragon half

Случайно включил. Там больше постмодерна, чем я думал. Один chougouki Z чего стоит.
404

High School DxD

Иногда краткие рецензии бывают самыми яркими. Меня поразила глубина и точность этой рецензии с anidb: Boing, Ecchi, High School, Novel, Pantsu, School Life, Shounen.

Или это был список категорий? В любом случае, рецензия получилась исчерпывающей.
404

онгоинг Senki Zesshou Symphogear

макросс не даёт спать спокойно - очередное "пою-сражаюсь", на этот раз с моеблобностью. Бои настолько нелепы, насколько их можно было сделать.

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

Короче, если Макросс был неожиданным, но имеющим право на существование, то это - выхолощенный треш.
404

kronos [13/256]

Новая смешная проблема: чрезмерный баллунинг традиционно сносит всё на своём пути. Особенно печально, если это "всё" - dom0.

Решение очевидно - dom0_mem в конфиге загрузки зена. Но, блин, хоть кто-нибудь способен читать этот кошмар в /etc/grub.d/? Я в курсе про /etc/default/grub, и он не является ответом на вопрос "куда писать опции зена". Пока временно прописал напрямую в /boot/grub/gbrub.cfg, но оно мне очень не нравится. Точнее, "он", то бишь grub2, то бишь система с генерацией из grub.d на шелле.

Итак, главное священнодействие: pool-join. Про страшные вещи вида "автоматическое создание pbd для существующих SR" мы пока не будем говорить, программа минимум - объединить два хоста в один пул, создать там любое shared SR и провести там первую миграцию на открытом сердце.

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


... Впрочем, это, кажется, не сработало. Не смотря на dom0_mem в grub.cfg память пала до 200Мб и снесла всё живое.

Единственное разумное оправдание - странные настройки dom0 в xapi, которые приводят к неадекватному балунингу.

Решение?

1) Ручками в конфиг
2) Успеть после загрузки поправить (балунинг с некоторой задержкой происходит).

Правильно два - но я не люблю гоняться, так что будем править конфиг (aka state.db). Любопытно или нет, но там написано:

('memory_overhead' '225443840') ('memory_target' '1680867328') ('memory_static_max' '27644755968') ('memory_dynamic_max' '1680867328') ('memory_dynamic_min' '1680867328') ('memory_static_min' '1576009728')

И это нехороший признак. Ок, поиграем в детективов. Выключим xapi (update-rc.d xcp-xapi disable), перегрузимся в xen-based конфигурацию...

Наблюдаю типовую проблему всех pv_ops ядер: dom0_mem=2048M, а free показывает
1689072k (300Мб спи..ли!)

Стартуем вручную xcp-xapi, наблюдаем... 1233392k свободной. И это при том, что у нас memory-dynamic-min ( RW): 1680867328.

У меня появляется ощущение, что Единая Россия стала спонсором pv_ops в линуксе - так изящно воровать целевым образом расходовать средства умеют только они (из 1680867328 байт сделать 1233392k - на это даже производители жёстких дисков не способны).

В любом случае, проблема решилась. Итак, легендарный и давно ожидаемый pool-join...

There was an error connecting to the host. the service contacted didn't reply properly.

Причина? Ну, включаем гуру-мод, и сразу говорим причину: не до конца (или неправильно) сконфигурированы management интерфейсы. Причём, вероятнее всего, причина в management-интерфейсе того хоста, который я хочу в пул вогнать (он не знает, через какой ип ходить к будущему мастеру).

Проверяем:

device ( RO) : eth0
management ( RO): true

Хм... мы не правы. ок, смотрим на будущем мастере: аналогично.

Так, проблема интереснее... Стоп, а прописан ли ip в свойствах у pif'а в базе xapi? Вопрос глупый, поскольку я на сервер по этому IP зашёл, но он не такой глупый, если предположить, что xapi не занимается самостоятельным сбором адресов, сконфигурированных из посторонних источников (ака /etc/networking/interfaces).

Проверяем:

Так и есть - мастере адрес прописан (см предыдущие посты), а вот на будущем слейве - поленились. Ок, прописываем.

Упс, с обоих сторон всё прописано, но не работает. Why? (xapi перезапущен был на всякий случай).

Начинаем дебаг:

xapi слушает на нужном IP на обоих хостах.

... На всякий случай попробовал в обратную сторону - прокатило. Обидно, что не отладил, но фиг с ним...

Проверяем живость:

xe host-list
The master reports that it cannot talk back to the slave on the supplied management IP address.
ip: x.x.x.97

Вот те на. Мастер (тот, кого мы пытались сделать слейвом) таки не может подключиться к слейву (которого мы хотели сделать мастером), на котором мы эту команду делаем.

Заметим, на мастере всё хорошо (xe host-list показывает два хоста).

JFYI я сделал маленькое кровосмесительное преступление - один xapi у меня бубунтовский, второй - дебиановский. Возможно, дело в этом.