January 9th, 2012

404

kronos [14/256]

Итак, борьба за pool join. Текущее состояние: мастер (debian+xcp-xapi) работает как положено, слейв (ubuntu+xcp-xapi) принимает команды на свой порт с localhost'а, но отказывается принимать их с других IP. Видимо, отказываясь при этом ещё и исполнять команды мастера.

remote xe показывает:
Unable to contact server. Please check server and port settings.

Что делать?

Смотрю на с мастера на конфиг пула и вижу странное:

uuid ( RO)                       : 2d33730c-ccdc-9d98-4733-36fffed6f9b6
                     device ( RO): eth0
                        MAC ( RO): 00:30:48:f1:62:ec
                   physical ( RO): true
         currently-attached ( RO): false
                        MTU ( RO): 1500
                       VLAN ( RO): -1
             bond-master-of ( RO): 
              bond-slave-of ( RO): 
       tunnel-access-PIF-of ( RO): 
    tunnel-transport-PIF-of ( RO): 
                 management ( RO): true
               network-uuid ( RO): eb7932f2-2aae-cfdf-c2f3-1b88a5390a74
         network-name-label ( RO): Pool-wide network associated with eth0
                  host-uuid ( RO): ab419297-3ef2-c835-da45-0bd16758c346
            host-name-label ( RO): kronos4
      IP-configuration-mode ( RO): Static
                         IP ( RO): x.x.x.97
                    netmask ( RO): 255.255.255.0
                    gateway ( RO): x.x.x.1
                        DNS ( RO): 8.8.8.8
                io_read_kbs ( RO): 
               io_write_kbs ( RO): 
                    carrier ( RO): false
                  vendor-id ( RO): 
                vendor-name ( RO): 
                  device-id ( RO): 
                device-name ( RO): 
                      speed ( RO): 0 Mbit/s
                     duplex ( RO): half
            disallow-unplug ( RW): false
               pci-bus-path ( RO): 


Внимание на speed/duplex. Явная же хрень! Итого - ошибочный конфиг. Как поправить? Вопрос крайне любопытный...

В логах у слейва вот такое:

[20120108T09:28:01.160Z|debug|kronos4|5|dom0 networking update D:c6143b19b9f8|xapi] Signalling anyone waiting for the management IP address to change
[20120108T09:28:04.225Z|debug|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] Attempting to acquire a management IP address
[20120108T09:28:04.225Z|debug|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] Acquired management IP address: x.x.x.97
[20120108T09:28:04.225Z|debug|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] Attempting to communicate with master
[20120108T09:28:04.233Z| info|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] stunnel pid: 3018 (cached = false) connected to x.x.x.100:443
[20120108T09:28:04.233Z| info|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] with_recorded_stunnelpid task_opt=None s_pid=3018
[20120108T09:28:04.252Z| info|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] stunnel pid: 3021 (cached = false) connected to x.x.x.100:443
[20120108T09:28:04.252Z| info|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] with_recorded_stunnelpid task_opt=None s_pid=3021
[20120108T09:28:04.292Z|error|kronos4|0 thread_zero|server_init D:cf3b30d08ecc|xapi] Master claims he cannot talk back to us on IP: x.x.x.97


Это чистой воды правда, мы тоже не можем подключиться. Логи мастера можно даже не смотреть. Но в чём же дело??

Пробуем команду, которую я никогда раньше не пробовал:

xe host-emergency-management-reconfigure interface=xenbr0

Тот же самый эффект.

Вероятнее всего, проблема в предварительном xe pif-scan и принудительном объявлении одного из pif'ов management.

Что делать? Ну, попробовать ещё раз pool-join. Не уверен, что это получится. Для тех, кто не в курсе, это забавная процедура: мы останавливаем xapi, говорим на мастере host-forget, а на слейве в /etc/xcp/pool.conf говорим вместо slave:ip 'master' - и получаем БД локального xapi в том виде, каким оно было "до" принятия в чужой пул.

Теперь мы можем разобраться с management интерфейсом в спокойном режиме. Выглядит странно - оба интерфейса имеют все параметры как положено. Ну, давайте для любопытства снесём их и сделаем scan снова. scan и join не помогают. Те же симптомы.

Ок, сведём ситуацию к простой - починить remote xe.

Очень странно, логах у "неправильного хоста" всё очень хорошо и пушисто:

eated by task D:01db8f4bcfeb
[20120108T09:44:10.448Z|debug|kronos4|0 thread_zero|bringing up management interface D:3d9f803f5c04|xapi] Management IP address is: x.x.x.97
[20120108T09:44:10.448Z|debug|kronos4|0 thread_zero|bringing up management interface D:3d9f803f5c04|xapi] Shutting down the old management interface (if any)
[20120108T09:44:10.448Z|debug|kronos4|0 thread_zero|bringing up management interface D:3d9f803f5c04|xapi] Starting new server on IP: x.x.x.97
[20120108T09:44:10.448Z| info|kronos4|0 thread_zero|bringing up management interface D:3d9f803f5c04|xapi] Successfully bound socket to: INET x.x.x.97:80


Миститка????

наконец, решаюсь попробовать подключиться с совершенно левого хоста... И у меня это получается!

Вот те на. xe не работает персонально с будущего мастера на будущего слейва! iptables я проверял в наипервейшую очередь. ssh в той же конфигурации работает. Что за...

Три варианта:

1) кривая версия xe
2) Фильтрация порта (где-то). Не подтверждается, nmap http/https видит.
3) Фильтрация на программном уровне на будущем слейве (что за бред?)

Всё осложняется тем, что xapi отказывается реагировать на простой GET / на 80ый порт. Делать tcpdump сессии? Бр... И оно работает по 443ему порту, так что мечтать о tcpdump не приходится...

Наконец, мне в голову приходит идея поиграться wget'ом:

Connecting to x.x.x.97:443... connected.
ERROR: The certificate of `x.x.x.97' is not trusted.
ERROR: The certificate of `x.x.x.97' hasn't got a known issuer.

Бунт на корабле? Не похоже, т.к. на .100 (localhost) оно пишет то же самое. Насилуем wget (--no-check-certificate)

Поведение идентичное на обоих хостах (404). Почему не работает xe???

Напрягся, нашёл ещё один xe рядом (зерновой xcp) - работает во всех направлениях.

Шаг отчаяния: я сейчас туннелирую на localhost удалённый remote порт в ssh и попробую его "рабочим" xe пробить. А потом наоборот с "нерабочим".
ssh -L 7778:x.x.x.97:443 root@x.x.x.97
xe vm-list -s localhost -p 7778 -u root -pw ....
Unable to contact server. Please check server and port settings.

Ура, хоть что-то подтвердилось - туннелирование xe с debian на ubuntu не работает.

Итак, оно выходит за рамки сисадминства и переходит в рамки "несовместимость приложений". Что ж, моя ошибка. Попробуем на ubuntu переустановить стек с нуля (из дебиановских репозиториев).

PS В рассылке подсказали фичу насчёт dom0_mem и груба - в /etc/default/grub можно прописать GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M"

Традиционно, чтобы не скучать.

Квантовая истина за еду

Нашлось в гугле по запросу "квантовая истина за еду".
404

знание VS вера

Магия никогда не бывает дружественной. Она либо нейтральна (я его не трогаю, он меня не трогает), либо враждебна.

Дружественная магия (та, которую знаешь и умеешь пользоваться) - это уже не магия, а просто знание. А как его врагам и зевакам (нетрайльным зрителям) показывать - это уже дело десятое.