Cómo arreglar "nova.compute.manager Stderr:u"qemu-img:no se pudo abrir"

De repente, el Resumen del hipervisor La página en el panel de Horizon no actualizaba las estadísticas de uso de vCPU, RAM y almacenamiento local para uno de los nodos de cómputo. Veo que se lanzan nuevas VM en ese nodo de cómputo, pero la página de estadísticas aún mostraba que todas las CPU virtuales, la RAM y el disco estaban intactos o no se usaban (aunque las nuevas VM consumieron todos los recursos disponibles en ese nodo). Aquí hay una instantánea del error "nova.compute.manager Stderr:u qemu-img:no se pudo abrir ”

A continuación se muestra la instantánea de Resumen del hipervisor página que muestra las estadísticas de uso de todos los hosts informáticos. En mi caso, el host de cómputo (cloudsecurity4 ) no informaba las estadísticas de uso correctas.

Esperaba que las estadísticas de uso cambiaran cuando se lanzaran nuevas máquinas virtuales, pero ese no fue el caso. La siguiente instantánea muestra la cantidad de máquinas virtuales que están programadas en el nodo de cómputo "cloudsecurity4".

¿Se enfrenta a un problema similar en OpenStack Mitaka? Luego, así es como solucioné el problema.

Solución:

Paso 1: Esté atento a cualquier mensaje de error en el host de cómputo.

# tailf /var/log/nova/nova-compute.log

ERROR nova.compute.manager Stderr: u"qemu-img: Could not open '/var/lib/libvirt/images/test-1.qcow2': Could not open '/var/lib/libvirt/images/test-1.qcow2': Permission denied\n"
INFO nova.compute.resource_tracker [req-5e1d0cdf-216b-4ca8-bdb4-c178825784ba - - - - -] Auditing locally available compute resources for node cloudsecurity4
ERROR nova.compute.manager [req-5e1d0cdf-216b-4ca8-bdb4-c178825784ba - - - - -] Error updating resources for node cloudsecurity4

El mensaje de error anterior dice 'qemu-img ‘ no puede abrir una imagen que está almacenada en /var/lib/libvirt/images y sorprendentemente, estaba buscando test-1.qcow2 . No tengo claro por qué Nova intentaba ejecutar qemu-img en prueba-1.qcow2 archivo, porque no veo ninguna instancia ejecutándose en el nombre de 'test-1 ' ni recuerdo haber corrido uno antes. Incluso si una instancia llamada 'test-1 ' se estaba ejecutando antes, ¿por qué Nova incluso estaba intentando leer esa imagen ahora? Bueno, la respuesta a esa pregunta sigue en blanco para mí.

Sin embargo, el error de permiso denegado me tentó a verificar el permiso de la carpeta '/var/lib/libvirt/images ‘ y era propiedad del usuario ‘libvirt-qemu ‘  y grupo ‘kvm '. Entonces, ¿qué crees que hubiera hecho? Por supuesto, cambié la propiedad de la carpeta a 'nova:nova ' pensando que nova-compute el servicio no debería tener problemas para leer los archivos de imagen.

Paso 2: Proporcionar permiso para nova para leer imágenes en /var/lib/libvirt/images carpeta.

# chown nova:nova /var/lib/libvirt/images

Paso 3: Reiniciar nova-compute servicio

# /etc/init.d/nova-compute restart

¿Sabes que? El resumen del hipervisor comenzó a mostrar las estadísticas de uso correctas para el host informático (cloudsecurity4 ).

Volví a nova-compute archivo de registro para ver lo que dice ahora.

# tailf /var/log/nova/nova-compute.log

WARNING nova.virt.libvirt.driver [req-9305df9b-d716-4c3c-bc3e-b75945f85ed8 - - - - -] Periodic task is updating the host stat, it is trying to get disk test, but disk file was removed by concurrent operations such as resize.
2017-06-01 22:35:59.818 97322 INFO nova.compute.resource_tracker [req-9305df9b-d716-4c3c-bc3e-b75945f85ed8 - - - - -] Total usable vcpus: 16, total allocated vcpus: 13

De la instantánea anterior, quedó claro que nova.compute.resource_tracker estaba informando las estadísticas de uso correctas del host de cómputo.

También hay un informe de error que habla sobre este problema.