Archive pour la Catégorie: ‘ESXi

14 articles trouvés dans cette archive
Jan/1624
Par , Dans ESXi

Bien que l’EVC (Enhanced vMotion Compatibility) existe depuis longtemps (ESX 3.5), il y a encore beaucoup de personnes ne l’utilisent pas par peur de dégradation des performances. Mythe ou réalité, j’ai voulu en avoir le coeur net, d’où l’objet de ce post.

Pour rappel l’EVC est un fonction au niveau d’un cluster vSphere qui permet de cacher certaines fonctionnalités des processeurs et ainsi pour faire des vMotion sans problème de compatibilité processeurs. Sans EVC, il n’est pas possible de déplacer des VMs entre des hôtes ayant des génerations différentes de processeur. On définit donc mode EVC pour fixer le baseline du niveau d’instruction minimum disponible à travers le cluster, les autres instructions serons masquées. En complément un FAQ sur EVC et la compatibilité CPU (KB1005764) et aussi les modes de compatibilité EVC en fonction de processeurs et des versions vSphere (KB1003212).

EVCbaseline

Lire la suite…

Jan/1213

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.

Lire la suite…

Jan/1211
Par Dans ESXi

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.

ESXi_CLI

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 »:

  • vicfg-authconfig
  • vicfg-cfgbackup
  • vicfg-hostops
  • vicfg-ipsec
  • vicfg-ntp
  • vicfg-route
  • vicfg-snmp
  • vicfg-user

Lire la suite…

Mai/11190
Par Dans ESX, ESXi, KB

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 ».

Avr/1118

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 :

  • API vStorage
  • CBT
  • VADP (vStorage API for Data Protection)

Lire la suite…

Avr/1160

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 :

  • /var/log/messages
  • /var/log/vmware/hostd.log
  • /var/log/vmware/vpx/vpxa.log

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 :

Lire la suite…

Mar/113
Par Dans ESX, ESXi, vCenter

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:

  • Ne pas utiliser des liens inférieur 56 kbps. A partir de 128 kbps cela devient utilisable
  • Upgrader manuellement l’agent vCenter(vpxa) sur les serveurs ESX avant de les ajouter dans l’inventaire du vCenter
  • Augmenter la valeur du heartbeat TimeOut pour diminuer les pertes de connexion avec les ESXs (voir plus bas)
  • Réduire la résolution et le nombre de couleurs de toutes les VMs des sites déportés
  • Utiliser RDP pour se connecter aux VMs Windows (plutôt que la Console VM)
  • Utiliser ssh ou putty pour se connecter aux VMs Linux
  • Etre vigilant à la configuration des Firewalls entre le vCenter et les ESXs
  • Sur le site distant, utiliser VI Client en direct vers les ESXs ou du RDP vers le vCenter pour utiliser le VI Client

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:

  • Ajouter un serveur ESX à l’inventaire, si la bande passante est inférieure à 128 Kbps
  • Ouvrir la Console VM, si la bande passante est inférieure à 256 Kbps et la latence supérieur à 100 ms
  • Se positionner sur un ESX dans l’inventaire, si la bande passante est inférieure à 128 Kbps et la latence supérieur à 150 ms

Grosso modo, il faut compter:

  • 80 à 100 Kbps / ESX, pour l’administration entre un serveur ESX et le vCenter
  • 1 Mbps, pour la communication entre le VI Client et le vCenter

Lire la suite…

Déc/1014

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.

Nov/1030
Par Dans ESX, ESXi

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:

+:DOMAINesx^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 « DOMAINesx^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.

Nov/1090
Par Dans ESX, ESXi

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:

  • L’hyperviseur peut être au courant de l’hyperviseur qu’il fait tourner dans une VM (comme Hyper-VM et Xen)
  • fournir un Bios en EFI, support de l’OS Darwin (base de MacOS) et un ensemble de virtual hardware obligatoire pour MacOS-X
  • une liste d’autre OS reconnu: OpenSuse, Darwin, Windows 2008 core, Windows 2008 SBS…
  • le nombre maximum de Snapshots, Le nombre de coeur des vCPU, des paramètres spécifiques pour l’ESX dans une VM…

A noter aussi la liste détaillé des paramètres VMX & VMX avancées sur le site Sandarrow.com