Apache CloudStack: Keine Vorlagen beim Hinzufügen der Instanz

Question

Ich habe den Apache Cloudstack auf CentOS 6.8 Maschine nach quick installation guide eingerichtet. Der Verwaltungsserver und der KVM werden auf demselben Computer eingerichtet. Der Management Server läuft ohne Probleme. Ich konnte Zonen-, Pod-, Cluster-, Primär- und Sekundärspeicher über die Webschnittstelle hinzufügen. Aber als ich versuchte, eine Instanz hinzufügen es keine Vorlagen in der zweiten Stufe zeigt, wie Sie im Screenshot sehen

aber ich bin in der Lage zwei Vorlagen unter Templates Link in Web-UI zu sehen.

Aber wenn ich die Vorlage und navigieren Sie zu Zone Registerkarte, ich sehe Timeout waiting for response from storage host und Ready Feld zeigt nicht.

Wenn ich die Management-Server-Protokolle zu überprüfen, so scheint es, gibt es einen Fehler, wenn versucht Cloudsekundärspeicher für den Einsatz zu montieren. Das folgende Segment aus der Datei cloudstack-management.log beschreibt diesen Fehler.

2017-03-09 23:26:43,207 DEBUG [c.c.a.t.Request] (AgentManager-Handler- 
14:null) (logid:) Seq 2-7686800138991304712: Processing: { Ans: , MgmtId: 
279278805450918, via: 2, Ver: v1, Flags: 10, [{"com.cloud.agent.api.Answer": 
{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException: 
GetRootDir for nfs://172.16.10.2/export/secondary failed due to 
com.cloud.utils.exception.CloudRuntimeException: Unable to mount 
172.16.10.2:/export/secondary at /mnt/SecStorage/6e26529d-c659-3053-8acb- 
817a77b6cfc6 due to mount.nfs: Connection timed out\n\tat 
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(Nf 
sSecondaryStorageResource.java:2080)\n\tat 
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSe 
condaryStorageResource.java:1829)\n\tat 
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeReques 
t(NfsSecondaryStorageResource.java:265)\n\tat 
com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat 
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:833)\n\tat 
com.cloud.utils.nio.Task.call(Task.java:83)\n\tat 
com.cloud.utils.nio.Task.call(Task.java:29)\n\tat 
java.util.concurrent.FutureTask.run(FutureTask.java:262)\n\tat 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\ 
n\tat 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\ 
n\tat java.lang.Thread.run(Thread.java:745)\n","wait":0}}] } 

Kann mir bitte jemand sagen, wie ich dieses Problem lösen kann? Ich habe es seit einigen Stunden versucht herauszufinden und weiß nicht weiter.
Edit 1: Bitte beachten Sie, dass meine LAN-Adresse war 10.103.72.50, die ich nehme an, ist nicht /24 Adresse. Ich habe versucht, CentOs eine statische IP, indem Sie die folgenden Einstellungen in ifcg-eth0 Datei

DEVICE=eth0 
HWADDR=52:54:00:B9:A6:C0 
NM_CONTROLLED=no 
ONBOOT=yes 
BOOTPROTO=none 
IPADDR=172.16.10.2 
NETMASK=255.255.255.0 
GATEWAY=172.16.10.1 
DNS1=8.8.8.8 
DNS2=8.8.4.4 

Aber das tun würde aufhören mein Internet zu geben. Um dieses Problem zu umgehen, habe ich diese Änderungen rückgängig gemacht und zuerst alle Pakete installiert. Dann änderte ich die IP-Adresse durch die gleichen Konfigurationseinstellungen wie oben und führte die Cloudstack-Verwaltung aus. Alles hat gut geklappt, bis ich auf dieses Template gestoßen bin. Bitte helfen Sie mir herauszufinden, was schiefgelaufen sein könnte

Answer 1

Ich weiß, ich bin spät dran, aber für Leute, die in Zukunft ausprobieren, hier geht es: Ich hoffe, Sie haben erfolgreich einen Host wie in Quick Install Guide erwähnt hinzugefügt Sie haben Ihre IP-Adresse in "statisch" geändert, da sie automatisch VLANs für unterschiedlichen Datenverkehr konfiguriert und zwei Bridges erstellt - in der Regel mit den Namen "Cloud" oder "Cloudbr". Cloudstack verwendet die VM des sekundären Speichersystems für alle speicherbezogenen Vorgänge in jeder Zone und in jedem Cluster. Das Problem scheint zu sein, dass das sekundäre Speichersystem vm (SSVM) nicht mit dem Management-Server an Port 8250 kommunizieren kann. Falls nicht, versuchen Sie, die Bereitstellungspunkte des NFS-Servers in der SSVM-Shell manuell zu mounten. Sie können in den SSVM ssh den folgenden Befehl:

ssh -i /var/cloudstack/management/.ssh/id_rsa -p 3922 root@<Private or Link local Ip address of SSVM> 

Ich schlage vor, Sie die /usr/local/cloud/systemvm/ssvm-check.sh nachlaufen VM ssh in den sekundären Speichersystem zu tun (vorausgesetzt, es läuft) und hat seine privaten, öffentlichen und verknüpfen lokale IP-Adresse . Wenn Ihnen das nicht hilft, werfen Sie einen Blick auf die secondary storage troubleshooting docs Cloudstack.

Ich würde weiter empfehlen, wenn jemand in Zukunft ähnliche Probleme auftritt, überprüfen Sie, ob der SSVM ausgeführt wird und im Abschnitt System VMs der Registerkarte Infrastruktur im Zustand "Up" ist und dass Sie eine Konsolensitzung öffnen können davon aus dem Browser. Wenn dies funktioniert, führen Sie das oben genannte Skript ssvm-check.sh aus, das systematisch jeden einzelnen von SSVM ausgeführten Vorgang überprüft. Auch wenn die Konsolensitzung nicht geöffnet werden kann, können Sie ssh weiterhin die lokale IP-Adresse des SSVM verwenden, auf die zugegriffen werden kann, indem Sie SSVM-Details öffnen und das Skript ausführen.Wenn es besagt, dass es nicht mit dem Management Server an Port 8250 kommunizieren kann, empfehle ich Ihnen, die iptables-Regeln des Management-Servers zu überprüfen und sicherzustellen, dass der gesamte Datenverkehr an Port 8250 erlaubt ist. Ein benutzerdefinierter Befehl zum Überprüfen desselben ist nc -v <mngmnt-server-ip> 8250. Sie können eine einfache Suche durchführen und erfahren, wie Sie in Ihren iptables-Regeln den Port 8250 hinzufügen, falls dieser nicht geöffnet ist. Als Nächstes haben Sie erwähnt, dass Sie CentOS 6.8 verwendet haben, daher werden wahrscheinlich ältere Versionen von nfs verwendet. Führen Sie daher in Ihrem NFS-Server exportfs -a aus, um sicherzustellen, dass alle NFS-Freigaben ordnungsgemäß exportiert werden und keine Fehler auftreten. Ich würde empfehlen, dass Sie auf den Download-Status von CentOS 5.5 warten, bevor keine GUI-KVM-Vorlage vollständig ist und ihr Bereit-Status als "Ja" angezeigt wird, bevor Sie eigene Vorlagen und ISOs zum Ausführen auf VMs importieren. Schließlich, wenn Ihr Skript ssvm-check.sh zeigt, alles ist gut und der Download immer noch nicht startet, können Sie den Befehl ausführen: service cloud restart und tatsächlich überprüfen, ob der Dienst eine PID mit service cloud status als ältere Versionen von System-VM-Vorlagen manchmal bekommen hat müssen Sie den Cloud-Dienst manuell starten, indem Sie service cloud start auch nach dem Neustart-Befehl verwenden. Der Neustart des Cloud-Dienstes in SSVM löst den Neustart des Downloads aller verbleibenden Vorlagen und ISOs aus. Randbemerkung: Die System-VMs verwenden einen Debian-Kernel, wenn Sie weitere Schritte zur Fehlerbehebung ausführen möchten. Hoffe das hilft.