Plötzlich die Hypervisor-Zusammenfassung Seite im Horizon-Dashboard aktualisierte die Nutzungsstatistiken von vCPUs, RAM und lokalem Speicher für einen der Rechenknoten nicht. Ich sehe, dass neue VMs auf diesem Rechenknoten gestartet werden, aber die Statistikseite zeigte immer noch, dass alle vCPUs, RAM und Festplatten intakt/nicht verwendet wurden (obwohl die neuen VMs alle verfügbaren Ressourcen auf diesem Knoten verbraucht haben). Hier ist eine Momentaufnahme des Fehlers „nova.compute.manager Stderr:u qemu-img:Could not open ”
Unten sehen Sie den Schnappschuss der Hypervisor-Zusammenfassung Seite mit den Nutzungsstatistiken aller Compute-Hosts. In meinem Fall ist der Rechenhost (cloudsecurity4 ) hat nicht die richtigen Nutzungsstatistiken gemeldet.
Ich hatte erwartet, dass sich die Nutzungsstatistiken ändern, wenn neue VMs gestartet werden, aber das war nicht der Fall. Der folgende Snapshot zeigt die Anzahl der VMs, die auf dem Rechenknoten „cloudsecurity4“ geplant sind.
Stehen Sie in OpenStack Mitaka vor einem ähnlichen Problem? Dann habe ich das Problem wie folgt behoben.
Lösung:
Schritt 1: Achten Sie auf Fehlermeldungen im Compute-Host.
# 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
Die obige Fehlermeldung lautet „qemu-img ‘ kann kein Bild öffnen, das in /var/lib/libvirt/images gespeichert ist Ordner und überraschenderweise suchte es nach test-1.qcow2 . Mir ist nicht klar, warum Nova überhaupt versucht hat, qemu-img auszuführen auf test-1.qcow2 Datei, weil ich keine Instanz sehe, die mit dem Namen „test-1“ läuft ‘ Ich kann mich auch nicht erinnern, dass vorher einer gelaufen ist. Auch wenn eine Instanz mit dem Namen „test-1 ‘ vorher lief, warum versuchte Nova überhaupt, dieses Bild jetzt zu lesen? Nun, die Antwort auf diese Frage bleibt mir immer noch verborgen.
Der Permission-Denied-Fehler hat mich jedoch dazu verleitet, die Berechtigung des Ordners „/var/lib/libvirt/images“ zu überprüfen ‘ und es gehörte dem Benutzer ‚libvirt-qemu ‘ und gruppieren Sie ‚kvm ‘. Also, was denkst du, hätte ich getan? Natürlich habe ich den Eigentümer des Ordners auf „nova:nova“ geändert ‘ denken, dass nova-compute Der Dienst sollte keine Probleme beim Lesen der Bilddateien haben.
Schritt 2: Erteilen Sie die Berechtigung für nova um Bilder in /var/lib/libvirt/images zu lesen Ordner.
# chown nova:nova /var/lib/libvirt/images
Schritt 3: Starten Sie nova-compute neu Dienst
# /etc/init.d/nova-compute restart
Weißt du was? Die Hypervisor-Zusammenfassung begonnen, die korrekten Nutzungsstatistiken für den Compute-Host anzuzeigen (cloudsecurity4 ).
Ich bin zu nova-compute zurückgekehrt log-Datei, um zu sehen, was sie jetzt sagt.
# 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
Aus dem obigen Schnappschuss war klar, dass nova.compute.resource_tracker hat die korrekten Nutzungsstatistiken des Rechenhosts gemeldet.
Es gibt auch einen Fehlerbericht, der sich mit diesem Problem befasst.