Tout à coup, le résumé de l'hyperviseur La page du tableau de bord Horizon ne mettait pas à jour les statistiques d'utilisation des vCPU, de la RAM et du stockage local pour l'un des nœuds de calcul. Je vois que de nouvelles VM sont lancées sur ce nœud de calcul, mais la page de statistiques indiquait toujours que tous les vCPU, la RAM et le disque étaient intacts/non utilisés (bien que les nouvelles VM aient consommé toutes les ressources disponibles sur ce nœud). Voici un instantané de l'erreur "nova.compute.manager Stderr :u qemu-img :Impossible d'ouvrir ”
Vous trouverez ci-dessous l'instantané du résumé de l'hyperviseur page affichant les statistiques d'utilisation de tous les hôtes de calcul. Dans mon cas, l'hôte de calcul (cloudsecurity4 ) ne rapportait pas les bonnes statistiques d'utilisation.
Je m'attendais à ce que les statistiques d'utilisation changent lors du lancement de nouvelles VM, mais ce n'était pas le cas. L'instantané ci-dessous montre le nombre de machines virtuelles planifiées sur le nœud de calcul "cloudsecurity4".
Rencontrez-vous un problème similaire dans OpenStack Mitaka ? Ensuite, voici comment j'ai résolu le problème.
Solution :
Étape 1 : Recherchez tout message d'erreur dans l'hôte de calcul.
# 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
Le message d'erreur ci-dessus indique "qemu-img ' n'est pas en mesure d'ouvrir une image stockée dans /var/lib/libvirt/images dossier et étonnamment, il cherchait test-1.qcow2 . Je ne comprends pas pourquoi Nova essayait même d'exécuter qemu-img sur test-1.qcow2 file, car je ne vois aucune instance s'exécuter au nom de 'test-1 ' ni je me souviens qu'il y en avait un qui courait avant. Même si une instance nommée 'test-1 ' était en cours d'exécution avant, pourquoi Nova essayait même de lire cette image maintenant ? Eh bien, la réponse à cette question reste encore vide pour moi.
Cependant, l'erreur d'autorisation refusée m'a tenté de vérifier l'autorisation du dossier '/var/lib/libvirt/images ' et il appartenait à l'utilisateur 'libvirt-qemu ‘ et le groupe ‘kvm ‘. Alors qu'est-ce que tu penses que j'aurais fait ? Bien sûr, j'ai changé le propriétaire du dossier en 'nova:nova ‘ pensant que nova-compute le service ne devrait pas avoir de problème pour lire les fichiers image.
Étape 2 : Accorder l'autorisation pour nova pour lire les images dans /var/lib/libvirt/images dossier.
# chown nova:nova /var/lib/libvirt/images
Étape 3 : Redémarrez nova-compute services
# /etc/init.d/nova-compute restart
Vous savez quoi? Le résumé de l'hyperviseur a commencé à afficher les statistiques d'utilisation correctes pour l'hôte de calcul (cloudsecurity4 ).
Je suis retourné à nova-compute log pour voir ce qu'il dit maintenant.
# 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
À partir de l'instantané ci-dessus, il était clair que nova.compute.resource_tracker rapportait les statistiques d'utilisation correctes de l'hôte de calcul.
Il y a aussi un rapport de bogue qui parle de ce problème.