Saltar a contenido

Errores durante la instalación de OpenStack

Warning

Documentación en progreso.

1. Error Out of memory: Killed process al ejecutar openstack-ansible setup-openstack.yml

Al ejecutar el playbook openstack-ansible setup-openstack.yml obtenemos el error Out of memory: Killed process. La instalación se queda detenida en este paso.

TASK [os_heat : Add keystone domain] *****************************************************************************************************************************************

En el log del nodo de Control aparecen los siguientes mensajes de error:

[18336.924339] Out of memory: Killed process 148504 (mariadbd) total-vm:10194672kB, anon-rss:316400kB, file-rss:0kB, shmem-rss:0kB, UID:106 pgtables:1372kB oom_score_adj:0
[20643.129225] Out of memory: Killed process 153371 (beam.smp) total-vm:3342996kB, anon-rss:192340kB, file-rss:0kB, shmem-rss:57388kB, UID:998 pgtables:884kB oom_score_adj:0
[37998.052221] Out of memory: Killed process 228567 (beam.smp) total-vm:3231340kB, anon-rss:112264kB, file-rss:0kB, shmem-rss:57388kB, UID:998 pgtables:648kB oom_score_adj:0

Solución

Aumentar la RAM del equipo o ampliar la swap.

2. Error al ejecutar: openstack-ansible setup-hosts.yml

Durante la ejecución del playbook openstack-ansible setup-hosts.yml se puede producir un error al reiniciar el servicio nginx del contenedor infra1_repo_container porque no es posible iniciarlo en la dirección IP y puerto que se ha configurado.

Cuando ocurre este error podemos conectarnos al contenedor infra1_repo_container y revisar si el archivo de configuración de nginx es correcto ejecutando el comando:

nginx -t

Si el comando se ejecuta sin mostrar ningún mensaje de error, entonces la configuración es correcta, sin embargo si hay algún error con la dirección IP y el puerto nos aparcerá un mensaje similar a éste:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] bind() to 172.29.238.113:9191 failed (99: Cannot assign requested address)
nginx: configuration file /etc/nginx/nginx.conf test failed

Solución: Revisar la configuración del archivo openstack_user_config.yml porque puede ser que la dirección IP que se haya configurado en el parámetro external_lb_vip_address sea incorrecta. Esta dirección tiene que tener la dirección IP pública del nodo de control

3. Error al subir una imagen a OpenStack desde el panel web de Horizon

La opción de subir imágenes a OpenStack desde el panel web de Horizon está desactivada por defect, sin embargo, sí se pueden subir desde la utilidad de línea de comandos.

Habrá que conectarse al contenedor de utilidades que está en el nodo de control y hacerlo desde ahí.

4. Error al crear una instancia (En un entorno de OpenStack virtual)

Al intentar crear una instancia aparece este mensaje:

There are no Availability Zones.

root@infra1-utility-container-2282feb1:/# openstack baremetal node list
internalURL endpoint for baremetal service in RegionOne region not found

Referencia:

5. Error al crear una instancia (En un entorno de OpenStack físico)

Al intentar crear una instancia aparece este mensaje:

No valid host was found. There are not enough hosts available.

Referencia: - https://docs.openstack.org/ironic/queens/admin/troubleshooting.html

# openstack baremetal node list
public endpoint for baremetal service in RegionOne region not found
    1. Comprobar si el servicio de nova está ejecutándose.
# openstack compute service list
    1. Si el servicio no está en ejecución, entonces nos conectamos a al nodo de cómputo y comprobamos si el servicio nova-compute está en ejecución
systemctl status nova-compute

Si el servicio no está en ejecución y hay errores al intentar volver a iniciarlo comprobamos si hay algún eror al ejecutar este comando:

libvirtd -l

Si nos aparece este eror:

 error : virPidFileAcquirePath:422 : Failed to acquire pid file '/var/run/libvirtd.pid': Resource temporarily unavailable

Ejecutamos los siguientes pasos:

Check that libvirtd was running on your system using command

ps -ef | grep libvirtd

move your pid file using command

mv /var/run/libvirtd.pid /var/run/libvirtd.pid.old

stop libvirtd service using command

systemctl stop libvirtd

and start again using command

systemctl start libvirtd

Referencias:

Error en el servicio nova-compute del nodo de cómputo

Comprobamos el estado del servicio nova-compute del nodo de cómputo.

# systemctl status nova-compute

Si obtenemos un mensaje de error similar a este es que el servicio no está funcionando correctamente.

● nova-compute.service - nova-compute service
     Loaded: loaded (/etc/systemd/system/nova-compute.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Tue 2022-03-29 11:40:25 UTC; 20min ago
    Process: 5298 ExecStart=/openstack/venvs/nova-24.1.1.dev1/bin/nova-compute (code=exited, status=0/SUCCESS)
   Main PID: 5298 (code=exited, status=0/SUCCESS)
        CPU: 3.424s

mar 29 11:40:24 computo nova-compute[5298]: 2022-03-29 11:40:24.134 5298 INFO os_vif [-] Loaded VIF plugins: linux_bridge, noop, ovs
mar 29 11:40:24 computo nova-compute[5298]: 2022-03-29 11:40:24.791 5298 INFO nova.virt.driver [req-956cd3a1-9a9b-4da7-a3ff-7d27f6006ef2 - - - - -] Loading compute driver 'libvirt.LibvirtDriver'
mar 29 11:40:25 computo nova-compute[5298]: 2022-03-29 11:40:25.012 5298 INFO nova.compute.provider_config [req-956cd3a1-9a9b-4da7-a3ff-7d27f6006ef2 - - - - -] No provider configs found in /etc/nova/provider_config/. If files are present, ensure the Nova process has access.
mar 29 11:40:25 computo nova-compute[5298]: 2022-03-29 11:40:25.037 5298 WARNING oslo_config.cfg [req-956cd3a1-9a9b-4da7-a3ff-7d27f6006ef2 - - - - -] Deprecated: Option "api_servers" from group "glance" is deprecated for removal (
                                            Support for image service configuration via standard keystoneauth1 Adapter
                                            options was added in the 17.0.0 Queens release. The api_servers option was
                                            retained temporarily to allow consumers time to cut over to a real load
                                            balancing solution.
                                            ).  Its value may be silently ignored in the future.
mar 29 11:40:25 computo nova-compute[5298]: 2022-03-29 11:40:25.059 5298 INFO nova.service [-] Starting compute node (version 24.0.1)
mar 29 11:40:25 computo nova-compute[5298]: 2022-03-29 11:40:25.067 5298 ERROR nova.virt.libvirt.host [-] Connection to libvirt failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory: libvirt.libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
...
                                            2022-03-29 11:40:25.067 5298 ERROR nova.virt.libvirt.host 
mar 29 11:40:25 computo nova-compute[5298]: 2022-03-29 11:40:25.072 5298 ERROR oslo_service.service [req-5c98ee4f-020e-42cb-bbc7-c80c51814ae8 - - - - -] Error starting thread.: nova.exception.HypervisorUnavailable: Connection to the hypervisor is broken on host
...

Comprobamos el estado del servicio libvirtd.

# systemctl status libvirtd

● libvirtd.service - Virtualization daemon
     Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-03-29 11:48:53 UTC; 13min ago
TriggeredBy: ● libvirtd-ro.socket
             ● libvirtd.socket
             ● libvirtd-tls.socket
             ● libvirtd-admin.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
   Main PID: 6250 (libvirtd)
      Tasks: 17 (limit: 32768)
     Memory: 15.6M
     CGroup: /system.slice/libvirtd.service
             └─6250 /usr/sbin/libvirtd

En la salida observamos que el servicio libvirtd-tls.socket no está iniciado.

NOTA: Aquí no se aprecia, pero en la salida del terminal este servicio aparece en rojo.

Tratamos de iniciar el servicio libvirtd-tls.socket de forma manual.

# systemctl start libvirtd-tls.socket

Pero seguimos obteniendo un mensaje de error indicando que no es posible iniciarlo y nos sugiere que ejecutemos el comando journalctl -xe para obtener más información sobre el error.

Referencias: - https://manpages.ubuntu.com/manpages/focal/man8/libvirtd.8.html

Ejecutamos el comando journalctl -xe para consultar los mensajes de log de los servicios del sistema.

# journalctl -xe

Entre los mensajes de log nos encontramos con un mensaje que nos indica que no se puede iniciar un agente del servicio de neutron porque no existe la interfaz eth12 para acceder a la red física.

mar 29 11:52:46 computo neutron-linuxbridge-agent[6677]: 2022-03-29 11:52:46.459 6677 
ERROR neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] 
Interface eth12 for physical network exit does not exist. Agent terminated!

Esta interfaz se configura en el parámetro host_bind_override del archivo openstack_user_config.yml en el apartado de provider_networks. En nuestro caso habíamos configurado el parámetro host_bind_override con el valor eth12 pero el nombre real de la interfaz del nodo de cómputo que conecta con la red física externa es enp6s0.

Ejemplo:

    - network:
        container_bridge: "br-ex"         # Valor original: br-vlan
        container_type: "veth"
        container_interface: "eth12"
        host_bind_override: "eth12"       # Poner la interfaz física de la máquina de cómputo (enp6s0)
        ip_from_q: "exit"
        type: "flat"
        net_name: "exit"
        group_binds:
          - neutron_linuxbridge_agent

Referencia:

Esto hay que hacerlo en el nodo de control y cómputo

Modificamos el valor de la interfaz que aparece en el archivo /etc/neutron/plugins/ml2/linuxbridge_agent.ini.

# nano /etc/neutron/plugins/ml2/linuxbridge_agent.ini

Y aquí modificamos el valor de la interfaz eth12 por enp6s0, que es el nombre real de la interfaz del nodo de cómputo que conecta con la red física externa (en nuestro caso).

[linux_bridge]
physical_interface_mappings = vlan:br-vlan,exit:enp6s0
# Linux bridge agent VXLAN networks

Una vez que hemos modificado el archivo, reiniciamos el servicio de neutron.

# systemctl restart neutron.slice

Iniciamos el servicio libvirtd-tls.socket que era el que estába detenido, pero hay que tener en cuenta el servicio libvirtd tiene que estar detenido para poder iniciarlo.

Cuidado con el orden de los servicios.

  1. Detener el servicio libvirtd: systemctl stop libvirtd.
  2. Iniciar el servicio libvirtd-tls.socket: systemctl start libvirtd-tls.socket.
  3. Iniciar el servicio libvirtd: systemctl start libvirtd.

Referencias:

6. No se pueden crear volúmenes

Si el servicio de cinder se ha configurado para trabajar con volúmenes LVM y iSCSI hay que conectarse al nodo de almacenamiento y comprobar que el volumen de cinder está creado.

vgdisplay

Si no aparece en el listado habrá que crearlo.

Mensaje de error:

Device /dev/sdb excluded by a filter.

Editamos el archivo de configuración de LVM.

# nano /etc/lvm/lvm.conf

Revisamos los filtros activos:

devices {
   ...
   filter = [ "a/.*/" ]
   ...

Reiniciamos el servicio de LVM.

# systemctl restart lvm

Referencias:

  • https://www.thegeekdiary.com/lvm-and-multipathing-sample-lvm-filter-strings/

Cómo reiniciar el servicio libvirtd en el nodo de Cómputo

En primer lugar detenemos el servicio libvirtd:

systemctl stop libvirtd

Reiniciamos los siguientes servicios:

systemctl restart libvirtd-ro.socket
systemctl restart libvirtd-tls.socket
systemctl restart libvirtd.socket
systemctl restart libvirtd-admin.socket

Volvemos a iniciar el servicio libvirtd:

systemctl start libvirtd

Podemos comprobar el estado del servicio para verificar que todo está funcionando correctamente.

systemctl status libvirtd

Error: fwupd-refresh.service

Occasionally fwupd-refresh.service: Failed with result 'exit-code'

Referencias: