Устранение неполадок¶

Физический узел в статусе enroll¶

Если после добавления физического узла его статус изменился на enroll, то возможны следующие варианты:

Указанный IP-адрес недоступен с узла развёртывания. Проверьте доступность адреса с узла развёртывания: надо выйти из dctui и попробовать команду

ping -c 1 2.2.2.3

Логин/пароль от BMC неверные

Чтобы изменить параметры BMC для управления узлом, нужно удалить узел и создать его заново.

Ошибка интроспекции¶

DnsmasqFilter¶

Ошибка при попытке интроспектировать узел

The PXE filter driver DnsmasqFilter, state=uninitialized: my fsm encountered an exception: Can not transition from state 'uninitialized' on event 'sync' (no defined transition)

Описание проблемы есть на сайте RedHat Solutions Причина ошибки: драйвер pxefilter не может инициализировать DNSmasq Решение: перезапустить все сервисы Ironic

for service in $(sudo systemctl | grep tripleo_ironic | cut -d " " -f3) ; do sudo systemctl restart $service ; done

Ramdisk error¶

2024-02-26 19:16:12.688 7 ERROR ironic_inspector.utils [-] [node: MAC 00:25:90:bb:0e:d8 BMC 10.100.2.33] Ramdisk repor
ted error: The following errors were encountered:
* failed to run hardware-detect utility: [Errno 2] No such file or directory: 'hardware-detect'
2024-02-26 19:16:12.688 7 ERROR ironic_inspector.process [-] [node: MAC 00:25:90:bb:0e:d8 BMC 10.100.2.33] Hook ramdis
k_error failed, delaying error report until node look up: Ramdisk reported error: The following errors were encountere
d:
* failed to run hardware-detect utility: [Errno 2] No such file or directory: 'hardware-detect': ironic_inspector.util
s.Error: Ramdisk reported error: The following errors were encountered:

Смотреть логи в /var/log/containers/ironic-inspector/ramdisk

Параметр не определён или определён неправильно в шаблоне¶

Если при создании стека не хватает какого-то параметра, но при этом, стек уже начал создаваться. Или если результат не соответствует указанному в параметре. То можно исследовать результаты создания стека в директории /home/stack/overcloud-deploy

Ошибка настройка сети¶

Если при развёртывании облака вы видете ошибку,

    "failed_when_result": true
}
2023-03-02 17:02:49.089226 | 08002710-c16f-44d5-9117-00000000029d |     TIMING | NetworkConfig stdout | monitoring-ceph-0 | 0:05:58.946554 | 0.06s

зайдите на упавший хост по ssh и выполните

sudo cat /etc/os-net-config/config.yaml

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

Если план соответствует ожидаемому, то выполните

sudo os-net-config -c /etc/os-net-config/config.yaml --verbose

И посмотрите на вывод команды и ошибки, которые команда выведет. Дальнейшая работа с проблемой зависит от ошибок в выводе команды.

После исправления всех ошибок, с узла развёртывания выполните

screen -x <deploy_name>

INTERACTIVE MODE
Enter command: c

Развёртывание продолжится дальше

Puppet cache read-only файловая система¶

Если при развёртывании падают контейнеры вида container-puppet-. То необходимо проверить логи контейнера после старта

sudo less /var/log/containers/stdouts/container-puppet-<service>.log

Если видны ошибки вида

boost::filesystem::remove: Read-only file system: "/opt/puppetlabs/facter/cache/cached_facts/kernel"

то проблема скорее всего в том, что развёртывание было начато некоторое время назад и кеш успел измениться. Необходимо пересоздать один из упавших контейнеров container-puppet- с разрешением на запись для container-volume=/var/lib/container-puppet/

sudo podman ps -a 
#использовать вывод для пересоздания контейнера
sudo podman inspect container-puppet-<service> | | jq .[0].Config.CreateCommand
sudo podman rm container-puppet-<service> 
sudo podman container run <...> --volume /var/lib/container-puppet/puppetlabs:/opt/puppetlabs:rw <...>

Остальные упавшие контейнеры вида container-puppet- можно просто перезапустить

sudo podman restart container-puppet-<service>

Wait for puppet host configuration to finish¶

Если при развёртывании сервисов Ansible падает на задаче Wait for puppet host configuration to finish, то сначала необходимо определить узел, на котором произошла ошибка

YYYY-MM-DD HH:MM:SS | 00000000-0000-0000-0000-000000000000 | WAITING | Wait for puppet host configuration to finish | acloud-controller-0

В примере выше ошибка произошла на узле acloud-controller-0. Для поиска причины ошибки необходимо зайти по ssh на этот узел и запустить puppet самостоятельно

sudo puppet apply --modulepath=/etc/puppet/modules:/opt/stack/puppet-modules:/usr/share/openstack-puppet/modules --detailed-exitcodes --summarize --color=true --verbose --debug /var/lib/tripleo-config/puppet_step_config.pp 

Дальнейший поиск проблемы зависит от вывода команды.
Если вывод команды долгий или недостаточно информативный, то добавьте флаг --debug

Pacemaker¶

Ошибка выглядит следующим образом:

Error: 'pcs status | grep -q -e "acloud-compute-30[[:blank:]].*Started"' returned 1 instead of one of [0]

Это значит, что pacemaker не смог запустить ресурс acloud-compute-30.

С любого из контроллеров выполните:

sudo pcs status

Вы увидите статус FAILED для ресурса acloud-compute-30. Проверьте правильность его настройки:

sudo pcs resource config acloud-compute-30

В выводе будет указан адрес ресурса в поле Attributes.

Проверьте доступность адреса с узла контроллера, на котором вы сейчас находитесь.

ping -c 1 <ip>

Проверьте, что на этот адрес ходят большие пакеты

ping -c 1 -s 10000 <ip>

Проверьте, что доступен порт 3121. Запрос не должен виснуть и не должен выводить ошибку Failed to connect

curl <ip>:3121

Если порт не доступен, то зайдите на проблемный узел по ssh и проверьте статус сервиса pacemaker_remote

sudo systemctl status pacemaker_remote

Этот сервис должен быть активен только на узлах виртуализации. На узлах контроллерах должен быть активен сервис pacemaker.

Если сервис активен, но имеет ошибки вида

error: TLS handshake with remote client failed: An illegal parameter has been received.

то скопируйте файл /etc/pacemaker/auth с рабочего узла. Команды с узла развёртывания

ssh tripleo-admin@<working-host>.ctlplane 'sudo cp /etc/pacemaker/auth ./'
rsync -azP tripleo-admin@<working-host>.ctlplane:authkey ./
rsync -azP authkey tripleo-admin@<failed-host>.ctlplane:
ssh tripleo-admin@<failed-host>.ctlplane 'sudo cp authkey /etc/pacemaker/'

После решения проблем зайдите на любой из контроллеров и выполните

sudo pcs resouce refresh <failed-host>

В указанном выше примере failed-host == acloud-compute-30.

Запустите повторно puppet на узле, на котором puppet упал изначально. Если puppet выполнит работу без ошибок, то продолжите работу Ansible далее без повторного выполнения задачи Ansible.

Не найден хост¶

После обновления развёртывания¶

Переведите nova-scheduler в режим debug. Для этого поменяйте параметр debug=False в True в файле /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf. Затем перезапустите nova-scheduler

sudo systemctl restart tripleo_nova_scheduler

Попробуйте создать виртуальную машину и проверьте в логах ошибку

less /var/log/containers/nova/nova-scheduler.log

Если ошибка выглядит следующим образом,

Filter AllHostsFilter returned 0 host(s)

то зайдите на любой контроллер (только один!) и выполните

sudo podman exec -ti -u root nova_compute nova-manage placement heal_allocations
sudo podman exec -ti -u root nova_compute nova-manage placement sync_aggregates

Число используемых ресурсов на гипервизорах обнулилось¶

Такое может произойти, если вы попытались поменять основной домен для имен хостов. В таком случае вы увидете следующее.

Например, вы поменяли хостнейм с localdomain на novalocal, тогда

openstack server list --all-projects --host acloud-compute-12.localdomain -f value | wc -l
20

openstack hypervisor show acloud-compute-12.novalocal -c service_host -c running_vms

+--------------+-----------------------------------------+
| Field        | Value                                   |
+--------------+-----------------------------------------+
| running_vms  | 0                                       |
| service_host | acloud-compute-12.localdomain |
+--------------+-----------------------------------------+

Причина проблемы в том, что у виртуалок запущенных на хосте acloud-compute-12.localdomain есть параметр гипервизора, который остался в значении acloud-compute-12.localdomain.

Чтобы решить проблему, необходимо на любом из контроллеров зайти в базу данных Mariadb и поменять значение для виртуалки

sudo podman ps | grep galera 

ab09fec32c4b  undercloud.ctlplane:13787/acloud/openstack-mariadb:pcmklatest                 /bin/bash /usr/lo...  9 days ago    Up 8 days ago                                       galera-bundle-podman-0

sudo podman exec -ti -u root galera-bundle-podman-0 mysql
> use nova_api
> select display_name from instances where node='acloud-compute-12.localdomain' and deleted_at is null;
> begin;
> update instances set node='acloud-compute-12.novalocal' where node='acloud-compute-12.localdomain' and deleted_at is null;
> commit ;

Бекенд для cinder недоступен¶

Если бекенд находится в статусе down при выполнении команды

openstack volume service list 

Сначала проверить доступность бекенда с узлов, пароли, МТУ сети. Затем

openstack volume service set --disable hostgroup@tripleo_ceph_reliable cinder-volume -vv
pcs resource restart openstack-cinder-volume
openstack volume service set --enable hostgroup@tripleo_ceph_reliable cinder-volume -vv

Вычислительный узел не добавлен в nova_cell¶

Если на вычислительном узле в логах /var/log/containers/nova/nova-compute.log ошибка выглядит следующим образом:

ERROR nova.cmd.common [req-4431a4a0-6789-466f-9ed1-b518a05b5771 - - - - -] No db access allo
wed in nova-compute:   File "/usr/bin/nova-compute", line 10, in <module>

То скорее всего вычислительный узел был развёрнут без undercloud узла в консоли - нужно развернуть с ним вместе.

Ошибка миграции Host key verification failed¶

Быстрый метод решения проблемы

sudo su
echo 'StrictHostKeyChecking no' >> /var/lib/config-data/puppet-generated/nova_libvirt/var/lib/nova/.ssh/config
systemctl restart tripleo_nova_compute

Виртуальная машина в статусе ERROR¶

Если виртуальная машина перешла в статус ERROR, то необходимо Выяснить на каком узле находится машина

openstack server show -c OS-EXT-SRV-ATTR:host <server_id/name>

Зайти на узел и выяснить ошибку. Варианты могут быть следующие:

Память

free -mh

Дисковая память

df -h

Статус контейнеров

sudo podman ps | grep nova

Логи контейнеров

ls /var/log/containers

После выяснения всех ошибок и исправления их проверьте существование ВМ на этом узле, а именно

ls /var/lib/nova/instances/<server_id>

Затем верните ВМ в работающее состояние

openstack server set --state active <server_id/name>
openstack server stop <server_id/name>
openstack server start <server_id/name>

Если машина снова перешла в состояние ERROR, значит ошибка не исправлена - продолжайте исследовать

Libvirt ошибка секрета¶

При создании виртуальной машине в логах узла виртуализации /var/log/containers/libvirt/ видна ошибка

Secret not found: no secret with matching uuid

Выполните на узле

sudo podman exec -ti -u root nova_virtqemud virsh secret-list
sudo podman exec -ti -u root nova_virtqemud virsh secret-undefine <secret_uuid>
sudo podman exec -ti -u root nova_virtqemud virsh secret-define /etc/nova/secret.xml
sudo podman exec -ti -u root nova_virtqemud virsh secret-set-value 

Причина ошибки - смена fsid для ceph’а, необходимо удалить старый fsid и добавить новый указанными выше командами