Pour faire suite à l'article sur ESXCLI, voici un article regroupant un ensemble de commandes (pas seulement "esxcli") qui peuvent être grandement utiles en cas d'urgence (typiquement quand on a plus l'accès par l'interface graphique) ou alors pour scripter une configuration (exemple: kickstart).
Note: L'ensemble de ces commandes sont pour ESXi 5.0, elles varient pour d'autres versions.
Avec vSphere 5, les commandes de management en ligne de commande ont quelque peu changé. En effet, la commande "esxcli" existait déjà en vSphere 4 mais la syntaxe des commandes a changé et il y a plus de commandes disponibles. Par habitude, on utilisait le plus souvent les anciennes commandes, en vSphere 5, "esxcli" est l'outil de commande principal.
Les commandes en "esxcfg-*" sont encore disponibles en vSphere 5 mais la plupart sont obsolètes et disparaîtront dans les futures versions. De même, les commandes en "vicfg-*" utilisable à distance avec le package vCLI, ne sont pas encore obsolète mais le deviendront également avec le temps. Il faut donc déjà prendre le pli de les remplacer par "esxcli". Cependant, les commandes suivantes n'ont pas équivalent en "esxcli":
Attention, VMware vient d'annoncer que pour continuer d'utiliser les patchs sur les ESX 3.5, il fallait avoir installé un pacth avant le 1 juin 2011.
Cette annonce est faite par l’intermédiaire de 2 KBs (KB1030001 pour ESX 3.5 et KB1030002 pour ESXi 3.5). Au 1 juin 2011, la sécurité de la base contenant les correctif ESX va changer. Un correctif (sorti en décembre 2010) qui met à jour la clé de sécurité d'ESX/ESXi 3.5 est nécessaire pour pouvoir appliquer les mises à jour postérieures au 1er juin. Il est nécessaire d’appliquer le patch critique spécifique suivant sur les serveurs ESX/ESXi en version 3.5 uniquement, avant le 1er juin.
Pour les ESX 3.5, il faut le correctif "ESX350-201012410-BG.zip".
Pour les ESXi 3.5, il faut le correctif "ESXe350-201012401-O-BG.zip".
Ou sinon aller sur http://www.vmware.com/patch/download/ et sélectionner la version 3.5 et la classification "Critical".
L'API vStorage de VMware est arrivée avec vSphere, tout comme bien d'autres. Cette API permet la mise en place d'un suivi des blocs modifiés (change block tracking ou CBT) de fichiers VMDK dans le but d'améliorer les performances liées au stockage. C'est utilisé, entre autres, par les outils de sauvegarde et de réplication. Le "Storage vMotion" tire aussi pleinement profit de cette avancée pour réduire la charge système d'une opération de relocalisation d'une machine virtuelle. Cela permet notamment d'effectuer plusieurs opérations de ce type en simultané.
On parle bien d'une fonctionnalité récente, ne pouvant être activée que sur des machines virtuelles au niveau matériel égal à 7. Tout comme la journalisation Windows 2003 et plus, c'est le système qui héberge les données qui logue les modifications et qui les restitue à l'outil qui les demande. L'hyperviseur (ESX ou ESXi) garde une trace des blocs modifiés d'un VMDK par l'activité même de la VM depuis la dernière sauvegarde. Au moment de la sauvegarde, cette table est relue par le VMKernel (interrogé par l'outil via l'API) et les données sont transmises à l'outil qui effectue la sécurisation. Les logiciels qui tolèrent ce mode de fonctionnement (utilisation du CBT), en lieu et place du bon VCB (VMware Consolidated Backup) ne le peuvent qu'au travers de l'API et utilisent les termes suivants :
La gestion des logs des systèmes ESXi doit être adaptées au fait que sur un reboot de cet hyperviseur, les logs ne restent pas. Et dans le cas d'un appel au support suite à un incident important ayant nécessité un redémarrage d'ESX, l'analyse sera infructueuse.
La recommandation est par conséquent de passer par une collecte externalisée et centralisée des logs générés par les ESXi. Sur ces systèmes, les fichiers de logs sont moins nombreux que sur les ESX et sont les suivants :
Le fichier "messages" est le plus important. Il contient l'équivalant des fichiers vmkernel et vmkwarning et une copie de l'activité stockée dans le hostd.log. Pour récupérer les informations de ce fichier, plusieurs possibilités :
Pour une administration en centrale sur une infra séparée géographiquement, il se pose souvent la question sur la bande-passante qu'il faut pour administrer des serveurs ESX à travers le WAN. Il y a bien une solution évidente: déporter le vCenter en Linked-Mode mais encore faut-il avoir plus de 3 ESXs sur ce site pour que ca soit intéressant au niveau des licences ou avoir plus de 10 sites déporté pour partir sur des packs Essentials ROBO. Sinon, on garde un seul vCenter en central et là, il faut avoir assez de bande passante.
Recommandations pour administrer des ESXs à travers le WAN:
La bande passante et la latence peuvent provoquer quelques problèmes d'affichage pour la majorité des actions. Par contre pour les taches suivantes, cela peut provoquer des TimeOuts ou des figeages du VI Client:
Grosso modo, il faut compter:
J'ai rencontré un problème de réseau assez étrange sur une de mes déploiement dont voici les détails.
Configuration :
Serveurs : IBM x3850 première génération,
VMware : ESXi4.1 à jour (+2 Patchs)
Cartes Réseaux : Broadcom intégré + Intel 82571EB
Switch virtuel vSwoitch0 contenant les cartes Broadcom : Réseau de management
Switch virtuel contenant les cartes Intel : Réseau des VM
Symptôme :
Les machines virtuelles sur le Switch de production ne communiquaient pas sur le réseau et au fur et à mesure les cartes réseaux (vmnic) tombaient une à une alors que sur le Switch physique, elles étaient bien UP.
J'ai donc tout d’abord essayé la KB http://kb.vmware.com/kb/1030265 même si mes serveurs ESX étaient assez anciens, mais sans effet.
Le problème a été résolu en appliquant la KB http://kb.vmware.com/kb/1010313 et tout fonctionne normalement, par contre aucune trace de messages d’erreurs dans les logs.
Si comme dans les bonnes pratiques VMware, on utilise un compte autre que "root" pour ce connecter en SSH sur un ESX. Après le passage en 4.1, on a un "acces denied" lorsque que l'on essaye une connection SSH. Pourtant le port est toujours ouvert sur le Firewall et le compte à bien la case "Grant Shell access to this user" cochée dans les permissions des utilisateurs locaux de l'ESX. La sécurité à été augmentée en 4.1 et les droits de ce compte n'a pas été conservé.
Ce qui faut faire, c'est ce connecter en console sur l'ESX et éditer le fichier /etc/security/access.conf qui doit contenir les lignes suivantes:
+:DOMAIN\esx^admins:ALL
+:root:ALL
+:vpxuser:ALL
+:vslauser:ALL
-:ALL:ALL
Il faut donc ajouter une ligne avec +:username:ALL pour de nouveau authorisé le SSH pour cet utilisateur.
On peut voir aussi dans ce fichier, une ligne "DOMAIN\esx^admins". Elle correspond à l'intégration avec les comptes AD disponible depuis ESX 4.1. Pour pouvoir ce connecter à un ESX, en plus de la configuration sur l'ESX, il faut créer un groupe AD nommé "ESX Admins" qui contient la liste des utilisateurs autorisés à administrer les serveurs ESX.
Attention: Il y a un bug, si vous vous connectez en SSH avec utilisateur qui fait parti de plus de 32 groupes cela crash l'ESX. Un correctif est sorti depuis le 15/11/2010 (Cf. lien en bas de la KB1026321) qui repousse la limite à 128 groupes.
Est-ce VMware prépare le support des Hyperviseur et de MacOS-X? Ces la questions que l'on peut ce poser, en effet William Lam a découvert en fouillant dans les chaines de paramètre disponible dans "/usr/lib/vmware/bin/vmware-vmx" plus de 1200 paramètres pour les fichiers .vmx, on peut les trouver ici.
Et dans cette page, il explique qu'une partie des paramètres non-documentés permettraient les points suivants:
A noter aussi la liste détaillé des paramètres VMX & VMX avancées sur le site Sandarrow.com
VMware vSphere 4.1 est sorti !!!
Les nouveautés de cette version sont détaillées à l'adresse suivante :
http://www.vmware.com/support/vsphere4/doc/vsp_41_new_feat.html
Et en francais:
http://www.vmware.com/fr/support/vsphere4/doc/vsp_41_new_feat.html
Voici les quelques changements de cette nouvelle version.
