OpenStack Icehouse Installationsfehler und Lösungen – CentOS

Ich versuche seit fast einer Woche, OpenStack Icehouse auf CentOS zu installieren (Da ich das zum ersten Mal mache, hat es eine Woche gedauert, bis die gesamte Installation und Konfiguration abgeschlossen war). Obwohl ich die offizielle Dokumentation befolgt habe, musste ich immer noch auf verschiedene Foren verweisen, einschließlich der Openstack-Support-Website, um Fehler zu beheben, die mich während des Installationsvorgangs gestört haben. Also dachte ich daran, all diese Fehler und Lösungen, die für mich funktioniert haben, in diesem Artikel zu erfassen. Sie können direkt einige Fehler und Lösungen sehen, auf die ich während der Installation der Keystone-, Glance- und Nova-Dienste gestoßen bin. Hoffentlich könnte es für jemanden hilfreich sein.

Nun, hier sind die paar mehr …

Fehler:neutron-server konnte nicht gestartet werden und nein Protokoll wurde geschrieben –  Neutron tot, aber PID-Datei existiert

# service neutron-server start
# service neutron-server status
neutron dead but pid file exists

Lösung:

Im Allgemeinen müssen Sie nach der Installation der Keystone-, Glow- und Nova-Dienste eine entsprechende Datenbank in MySQL erstellen (normalerweise werden die Datenbanken manuell erstellt). Der Neutronendienst benötigt dies jedoch nicht, da der Dienst die Datenbank automatisch füllt. Es verhielt sich jedoch nicht so und ich musste "neutron-db-manage" manuell ausführen ' vor dem Start von 'neutron-server'.

Hinweis: Laut offizieller Dokumentation wird empfohlen, den Neutron-Server vor dem Synchronisieren der Datenbank manuell zu starten. Sie sollten die folgenden Schritte nur ausführen, wenn der Dienst nicht gestartet werden kann.

Führen Sie die folgenden Befehle aus, um die Netzwerk-Plugins zu konfigurieren

# openstack-config --set /etc/neutron/neutron.conf DEFAULT core_plugin neutron.plugins.ml2.plugin.Ml2Plugin
# openstack-config --set /etc/neutron/neutron.conf DEFAULT service_plugins neutron.services.l3_router.l3_router_plugin.L3RouterPlugin

Füllen Sie jetzt die Neutronendatenbank…

# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head" neutron

Versuchen Sie, Neutron-Server zu starten. Bei mir hat es funktioniert.

FEHLER:Der Server hat entweder einen Fehler gemacht oder ist nicht in der Lage, die Ausführung durchzuführen die angeforderte Operation. (HTTP 500)

Der obige Fehler wurde ausgelöst, als ich den Netzwerk- und Boot-Befehl von nova ausführte.

[root@gcontroller]#nova --debug network-create tg-network --bridge br100 --multi-host T --fixed-range-v4 10.180.14.160/27

Lösung:
Versuchen Sie, den folgenden Befehl auszuführen…

[root@gcontroller]#nova-manage network create tg-network --multi_host=T --fixed_range_v4=10.180.14.160/27 --bridge=br100 --num_networks=1 --network_size=256

Fehler:NetworkNotCreated:Bridge ist erforderlich, um ein Netzwerk zu erstellen

[root@gcontroller]# nova-manage network create tg-network --multi_host=T --bridge_interface=br100 --fixed_range_v4=10.180.14.160/27
Command failed, please check log for more info

Weitere Informationen finden Sie im Fehlerprotokoll …

[root@gcontroller]#tailf /var/log/nova/nova-manage.log
2015-02-06 18:33:07.656 5080 CRITICAL nova [req-750edab1-9736-4cff-9395-e596f316e596 None None] NetworkNotCreated: bridge is required to create a network.

Lösung:

Wie die obige Fehlermeldung besagt, sollten Sie die bridge_interface zum Erstellen eines Netzwerks angeben. Der Befehl lautet also wie folgt. Suchen Sie nach „–bridge_interface=br100 ‘

[root@gcontroller]#nova-manage network create tg-network --multi_host=T --fixed_range_v4=10.180.14.160/27 --bridge_interface=br100 --num_networks=1 --network_size=256

[root@gcontroller]# nova net-list
+--------------------------------------+---------+------------------+
| ID                                   | Label   | CIDR             |
+--------------------------------------+---------+------------------+
| 60dfd46a-4649-4758-8b8d-88cc562b9b39 | tg-network | 10.180.14.160/27 |
+--------------------------------------+---------+------------------+

Fehler:Höhere Version von pyparsing erforderlich – Requirement.parse('pyparsing>=2.0.1')

# neutron net-create ext-net --shared --router:external=True (pyparsing 1.5.6 (/usr/lib/python2.6/site-packages), Requirement.parse('pyparsing>=2.0.1')) 
'Namespace' object has no attribute 'debug'

Lösung:

Es ist klar, dass Sie eine höhere Version von pyparsing installieren sollten. Der einfachste Weg, ein Python-Modul zu installieren, ist die Verwendung von 'pip ‘ oder ‚easy_install ‘.

easy_install pyparsing

Aber wissen Sie, manchmal funktioniert es nur, das Modul zu kompilieren und zu installieren. In solchen Fällen können Sie hier die neueste Version von pyparsing herunterladen.

[root@gcontroller pyparsing-2.0.1]# python setup.py build
running build
running build_py
creating build
creating build/lib
copying pyparsing.py -> build/lib
[root@gcontroller pyparsing-2.0.1]# python setup.py install
running install
running build
running build_py
running install_lib
copying build/lib/pyparsing.py -> /usr/lib/python2.6/site-packages
byte-compiling /usr/lib/python2.6/site-packages/pyparsing.py to pyparsing.pyc
running install_egg_info
Writing /usr/lib/python2.6/site-packages/pyparsing-2.0.1-py2.6.egg-info

Fehler:INFO nova.wsgi [-] Stoppen des WSGI-Servers | INFO nova.openstack.common.service [-] SIGTERM abgefangen, beim Beenden von | [Errno 111] Verbindung abgelehnt

Ich habe den obigen Fehler erhalten, als ich einen der nova-Befehle ausgeführt habe.

[root@gcontroller]# nova net-list
ERROR: [Errno 111] Connection refused

Die Protokolldateien unter /var/log/nova hat den obigen Fehler aufgedeckt.

INFO nova.wsgi [-] Stopping WSGI server.
INFO nova.wsgi [-] WSGI server has stopped.
INFO nova.wsgi [-] WSGI server has stopped.
INFO nova.wsgi [-] WSGI server has stopped.
INFO nova.openstack.common.service [-] Caught SIGTERM, exiting

Lösung:

Wenn Sie den Fehler „Verbindung abgelehnt“ sehen, ist es klar, dass einer der erforderlichen Dienste nicht ordnungsgemäß ausgeführt wird. Nach dem Debuggen habe ich verstanden, dass beim Start von „openstack-nova-metadata-api ‘, es beendet ‚openstack-nova-api ' Service. Der Grund dafür war, dass openstack-nova-api bereits „metadata-api“ zusammen mit ihm ausführte und wenn ich „openstack-nova-metadata-api“ separat starte, beendete es den anderen Dienst.

Um das Problem zu beheben,

• $vi /etc/nova/nova.conf
• Suchen Sie nach „enabled_apis ‘ und dessen Wert ‘ec2,osapi_compute,metadata ‘
• Entfernen Sie „Metadaten“ aus „enabled_apis“
• Nun können Sie beide 'openstack-nova-api starten ‘ und ‘openstack-nova-metadata-api ‘. Beide Dienste werden einzeln ausgeführt.

Falls Sie „metadata-api“ zusammen mit „openstack-nova-api“ starten möchten, lassen Sie „enabled_apis“ mit Werten wie „ec2,osapi_compute,metadata“ und stoppen Sie „openstack-nova-metadata-api“. ‘ vom Starten während des Systemstarts. Dazu können Sie einfach die folgenden Befehle ausführen:

$ chkconfig openstack-nova-metadata-api off
$ chkconfig openstack-nova-api on

Fehler:iptables-restore v1.4.6:Bad IP address „gcompute“

Das Obige ist aufgetreten, als ich versucht habe, nova-network auf meinem Rechenknoten zu starten. Die Protokolldateien unter /var/log/nova offenbarte die obige Nachricht.

Lösung:

• Öffnen Sie /etc/nova/nova.conf und suchen Sie nach „my_ip ‘-Attribut.
• Stellen Sie sicher, dass „my_ip ‘ enthält IP-Adresse als Wert und nicht Hostname oder FQDN oder localhost . In meinem Fall war es der FQDN des Rechenknotens. Ich habe es in IP-Adresse geändert.
• Starten Sie jetzt openstack-nova-network neu Service und es sollte wie erwartet funktionieren.

FEHLER:Quote überschritten für Instanzen:1 angefordert, aber bereits 10 von 10 Instanzen verwendet (HTTP 413)

Nun, Sie sollten das standardmäßige Kontingentlimit für das Booten der neuen Instanz ändern. Führen Sie den folgenden Befehl aus, um die standardmäßigen Kontingentgrenzen anzuzeigen.

[root@gcontroller]# nova quota-defaults
+-----------------------------+-------+
| Quota | Limit |
+-----------------------------+-------+
| instances | 10 |
| cores | 20 |
| ram | 51200 |
| floating_ips | 10 |
| fixed_ips | -1 |
| metadata_items | 128 |
| injected_files | 5 |
| injected_file_content_bytes | 10240 |
| injected_file_path_bytes | 255 |
| key_pairs | 100 |
| security_groups | 10 |
| security_group_rules | 20 |
+-----------------------------+-------+

Mit dem folgenden Befehl können Sie ein neues Kontingentlimit festlegen.

[root@gcontroller]# nova quota-class-update --instances 35 default
[root@gcontroller]# nova quota-defaults
+-----------------------------+-------+
| Quota                       | Limit |
+-----------------------------+-------+
| instances                   | 35    |
| cores                       | 20    |
| ram                         | 51200 |
| floating_ips                | 10    |
| fixed_ips                   | -1    |
| metadata_items              | 128   |
| injected_files              | 5     |
| injected_file_content_bytes | 10240 |
| injected_file_path_bytes    | 255   |
| key_pairs                   | 100   |
| security_groups             | 10    |
| security_group_rules        | 20    |
+-----------------------------+-------+

Cirros Image ist gebootet und aktiv, aber Wie lautet der Benutzername und das Passwort, um sich am Terminal anzumelden?

Wenn Sie eine Instanz mit dem Cirros-Image gestartet haben (das ist das einfachste, um Ihr Setup zu testen) und auf das Terminal der neuen Instanz zugreifen möchten, senden Sie eine SSH-Verbindung mit dem Benutzernamen „cirros“ und dem Passwort „cubswin:)“.

#ssh [email protected]

Anmeldung beim Openstack-Dashboard nicht möglich

Sehen Sie „Etwas ist schief gelaufen! Ein unerwarteter Fehler ist aufgetreten. Versuchen Sie, die Seite zu aktualisieren“, wenn auf das Openstack-Dashboard zugegriffen wird?

OPENSTACK_HOST = "gcontroller.org.in"
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v2.0" % OPENSTACK_HOST
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "admin"

ALLOWED_HOSTS = ['10.180.5.50', '10.180.5.49', '10.180.10.132']