Le serveur de gestion de CloudStack consigne toutes les activités du site web, du middle tier, et de la base de données à des fins de diagnostique dans /var/log/cloudstack/management/. CloudStack enregistre une variété de messages d’erreurs. Nous recommandons cette commande pour trouver la sortie problématique parmi les enregistrements du serveur de gestion :
Note
Lors du copier/coller d’une commande, soyez certain que la commande est collée sur une seule ligne avant de l’exécuter. Certains lecteur de document peuvent introduire un saut de ligne indésirable dans le texte copié.
grep -i -E 'exception|unable|fail|invalid|leak|warn|error' /var/log/cloudstack/management/management-server.log
CloudStack traite les requêtes avec un identifiant de travail. Si vous trouver une error dans les logs et que vous êtes intéressés dans le dépannage de ce problème, vous pouvez faire un grep pour cet ID de travail dans les logs du serveur de gestion. Par example, en supposant que vous trouviez le message ERROR suivant :
2010-10-04 13:49:32,595 ERROR [cloud.vm.UserVmManagerImpl] (Job-Executor-11:job-1076) Unable to find any host for [User|i-8-42-VM-untagged]
Noter que l’identifiant du travail est 1076. Vous pouvez tracer les évènements en relation avec le travail 1076 avec le grep suivant :
grep "job-1076)" management-server.log
L’agent CloudStack enregistre ses activités dans /var/log/cloudstack/agent/.
La perte de données existante sur le stockage primaire qui a été exposé comme un export de serveur Linux NFS sur un volume ISCSI.
Il est possible qu’un client depuis l’extérieur du pool attendu ait monté le stockage. Lorsque cela arrive, le LVM est corrompu et toutes les données du volume sont perdus.
Lors de la configuration de l’exportation d’un LUN, restreindre la plage des adresses IP autorisées à y accéder en spécifiant un masque de sous réseau. Par exemple :
echo “/export 192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)” > /etc/exports
Ajuster la commande ci-dessous pour correspondre aux besoins de votre déploiement.
Voir la procédure d’exportation dans la section “Stockage secondaire” du guide d’installation de CloudStack
Un routeur virtuel fonctionne, mais l’hôte est déconnecté. Un routeur virtuel ne fonctionne plus comme attendu.
Le routeur virtuel est perdu ou stoppé.
Si vous êtes certain que le routeur est définitivement stoppé, ou qu’il ne fonctionne plus comme attendu, le détruire. Vous devez en créer un de nouveau tout en conservant le routeur de secours démarré et en fonctionnement (ceci suppose qu’il s’agit d’une configuration avec routeur redondant) :
Forcer l’arrêt du routeur. Utiliser l’API stopRouter avec le paramètre forced=true pour le faire.
Avant de continuer avec la destruction de ce routeur, assurez vous que le routeur de secours est en fonctionnement. Sinon la connexion au réseau sera perdue.
Détruire le routeur en utilisant l’API destroyRouter.
Recréer le routeur manquant en utilisant l’API restartNetwork avec le paramètre cleanup=false. Pour plus d’information à propos de la configuration redondante des routeurs, voir Créer une nouvelle offre de réseau.
Pour plus d’information sur la syntaxe de l’API, voir la Référence de l’API à l’adresse http://cloudstack.apache.org/docs/api/.
L’hôte a été placé en mode maintenance, mais apparaît toujours vivant dans le vCenter.
L’interface d’administration de CloudStack a été utilisée pour basculer l’hôte en mode de maintenance programmée. Ce mode est différent du mode de maintenance du vCenter.
Utiliser le vCenter pour basculer l’hôte en mode maintenance.
Lors de la tentative de création d’une VM, la VM ne va pas se déployer.
Si le modèle a été créé en téléchargeant un fichier OVA qui a été créé en utilisant un client vSphere, il est possible que l’OVA contienne une image ISO. Si c’est le cas, le déploiement des VMs depuis le modèle va échouer.
Ejecter l’ISO et télécharger de nouveau le modèle.
La machine virtuelle ne démarre pas. Vous devriez voir des erreurs comme :
Impossible d’ouvrir le fichier Swap
Accès impossible à un fichier avec verrou
Accès impossible à la configuration d’une machine virtuelle
Une erreur connue sur les machines VMware. Les hôtes ESX verrouille certains fichiers et systèmes de fichiers de machine virtuelle critique pour prévenir de changement concurrent. Parfois, les fichiers ne sont pas déverouillés quand la machine virtuelle est éteinte. Quand la machine virtuelle essaie de redémarrer, elle ne peut pas accéder à ces fichiers critiques, et la machine virtuelle n’est pas capable de démarrer.
Après le changement d’offre réseau sur un réseau, les règles du répartiteur de charge ne fonctionnent plus.
Les règles de répartitions de charge ont été créées lors de l’utilisation d’une offre de service qui inclue un répartiteur de charge physique externe comme un NetScaler, et plus tard l’offre de service réseau à changée pour une qui utilise un routeur virtuel CloudStack.
Créer une règle de firewall sur le routeur virtuel pour chacune de vos règles de répartition de charge afin qu’elles continuent à fonctionner.
Ci-dessous les quelques étapes de dépannage pour vérifier ce qui ne va pas avec votre réseau...
Les commutateurs doivent être configurés correctement pour laisser passer le trafic VLAN. Vous pouvez vérifier si le trafic VLAN fonctionne en montant une interface sur les hôtes et en pinguant entre eux comme ci-dessous...
Sur host1 (kvm1)
kvm1 ~$ vconfig add eth0 64
kvm1 ~$ ifconfig eth0.64 1.2.3.4 netmask 255.255.255.0 up
kvm1 ~$ ping 1.2.3.5
Sur host2 (kvm2)
kvm2 ~$ vconfig add eth0 64
kvm2 ~$ ifconfig eth0.64 1.2.3.5 netmask 255.255.255.0 up
kvm2 ~$ ping 1.2.3.4
Si les pings ne fonctionne pas, utiliser tcpdump(8) un peu partout pour vérifier qui absorbe les paquets. En définitive, si les commutateurs ne sont pas configurés correctement, le réseau CloudStack ne fonctionnera pas alors corriger les pannes réseaux physiques avant de poursuivre avec les étapes suivantes
S’assurer que les Labels Trafics sont renseignés pour cette Zone.
Les labels de trafic doivent être renseignés sur tous les hyperviseurs incluant les types XenServer, KVM et VMware. Vous pouvez configurer les labels de trafic quand vous créez une nouvelle zone depuis l’Assistant d’Ajout de Zone.
Sur une zone existante, vous pouvez modifier les labels de trafic en allant sur l’onglet Infrastructure, Zones, Réseau physique.
Lister les labels en utilisant CloudMonkey
acs-manager ~$ cloudmonkey list traffictypes physicalnetworkid=41cb7ff6-8eb2-4630-b577-1da25e0e1145
count = 4
traffictype:
id = cd0915fe-a660-4a82-9df7-34aebf90003e
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Guest
xennetworklabel = MGMT
========================================================
id = f5524b8f-6605-41e4-a982-81a356b2a196
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Management
xennetworklabel = MGMT
========================================================
id = 266bad0e-7b68-4242-b3ad-f59739346cfd
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Public
xennetworklabel = MGMT
========================================================
id = a2baad4f-7ce7-45a8-9caf-a0b9240adf04
kvmnetworklabel = cloudbr0
physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
traffictype = Storage
xennetworklabel = MGMT
=========================================================
Les labels de trafic KVM nécessitent d’être nommés comme “cloudbr0”, “cloudbr2”, “cloudbrN” etc et le pont correspondant doit exister sur les hôtes KVM. Si vous créez des labels/ponts avec n’importe quel autre nom, CloudStack (au moins les versions anciennes le font) semble les ignorer. CloudStack ne crée pas les ponts physiques sur les hôtes KVM, vous devez les créer avant d’ajouter l’hôte dans CloudStack.
kvm1 ~$ ifconfig cloudbr0
cloudbr0 Link encap:Ethernet HWaddr 00:0C:29:EF:7D:78
inet addr:192.168.44.22 Bcast:192.168.44.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:feef:7d78/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:92435 errors:0 dropped:0 overruns:0 frame:0
TX packets:50596 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:94985932 (90.5 MiB) TX bytes:61635793 (58.7 MiB)
L’interface publique du Routeur Virtuel, de la SSVM et de la CPVM doivent être attachées à l’interface physique sur l’hôte. Dans l’exemple ci-dessous, cloudbr0 est l’interface publique et CloudStack a correctement crée le pont des interfaces virtuelles. L’attachement de l’interface virtuelle à l’interface physique est automatiquement effectuée par CloudStack, en s’appuyant sur le paramètre de label du trafic pour la zone. Si vous avez fourni les paramètres correctes et que vous n’avez toujours pas de connexion Internet, vérifier la couche réseau avant de débugger plus loin. Vous pouvez vérifier le trafic en utilisant tcpdump sur les interfaces virtuelles, les interfaces physiques et les ponts.
kvm-host1 ~$ brctl show
bridge name bridge id STP enabled interfaces
breth0-64 8000.000c29ef7d78 no eth0.64
vnet2
cloud0 8000.fe00a9fe0219 no vnet0
cloudbr0 8000.000c29ef7d78 no eth0
vnet1
vnet3
virbr0 8000.5254008e321a yes virbr0-nic
xenserver1 ~$ brctl show
bridge name bridge id STP enabled interfaces
xapi0 0000.e2b76d0a1149 no vif1.0
xenbr0 0000.000c299b54dc no eth0
xapi1
vif1.1
vif1.2
Pré-créer les labels sur les hôtes XenServer. Similaire à la configuration du pont KVM, les labels de trafics doivent aussi être pré-créés sur les hôtes XenServer avant de les ajouter à CloudStack.
xenserver1 ~$ xe network-list
uuid ( RO) : aaa-bbb-ccc-ddd
name-label ( RW): MGMT
name-description ( RW):
bridge ( RO): xenbr0
Internet devrait être accessible depuis à la fois les instances SSVM et CPVM par défaut. Leurs IP publiques seront également directement pingable depuis Internet. Merci de prendre note que ces tests ne fonctionneront que si vos commutateurs et les labels de trafic sont correctement configurés dans votre environnement. Si vos SSVM/CPVM ne peuvent pas joindre Internet, il y a peu de chance que le Routeur Virtuel puisse également le faire, ce qui indique un problème de commutateur ou de labels de trafic mal attribués. Fixer les problèmes SSVM/CPVM avant de débugger les problèmes de VR.
root@s-1-VM:~# ping -c 3 google.com
PING google.com (74.125.236.164): 56 data bytes
64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=26.932 ms
64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=29.156 ms
64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=25.000 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 25.000/27.029/29.156/1.698 ms
root@v-2-VM:~# ping -c 3 google.com
PING google.com (74.125.236.164): 56 data bytes
64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=32.125 ms
64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=26.324 ms
64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=37.001 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 26.324/31.817/37.001/4.364 ms
Le routeur virtuel (VR) devrait aussi être capable d’atteindre Internet sans avoir des règles Egress. Les règles Egress contrôlent seulement le trafic transféré et pas le trafic qui provient du VR lui-même.
root@r-4-VM:~# ping -c 3 google.com
PING google.com (74.125.236.164): 56 data bytes
64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=28.098 ms
64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=34.785 ms
64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=69.179 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.098/44.021/69.179/17.998 ms
Toutefois, les adresses IP publique de Source NAT du Routeur Virtuel (VR) ne seront pas accessible tant que les règles entrantes ne sont pas en place. Vous pouvez ajouter les règles Ingress sous la page de configuration Réseau, Réseau Invité, Adresse IP, Parefeu.
Les instances de VM ne peuvent pas accéder par défaut à Internet. Ajouter les règles Egress pour permettre le trafic.
Certains utilisateurs ont rapportés qu’en réinitialisant les règles IPTables (ou en changeant les routes) sur la SSVM, CPVM ou sur le Routeur Virtuel font fonctionner internet. Ce n’est pas un comportement normal et cela suggère que vos paramètres réseaux sont incorrectes. Aucun changement de règles IPTables ou de route ne sont nécessaires sur la SSVM, CPVM ou le VR. Revenir et refaire une vérification de tous vos paramètres.
Dans une grande majorité des cas, le problème s’est avéré être un problème de commutateur où la couche 3 des commutateurs était incorrectement configurée.
Cette section est une contribution de Shanker Balan et a été publié à l’origine sur le Blog Shapeblue