VMware vCenter Support Assistant 5.1

VMware met à disposition un plugin gratuit pour vCenter (4.1 et plus) permettant de créer directement des incidents (support request) auprès de VMware. vCenter Support Assistant 5.1 permet ainsi de gérer ses incidents, d’en créer de nouveaux, d’avoir des suggestions de résolution (KB) en relation avec l’incident décrit et d’envoyer également des fichiers de logs, tout ça depuis vCenter.

Plus d’informations concernant vCenter Support Assistant 5.1 : http://www.vmware.com/fr/products/datacenter-virtualization/vcenter-support-assistant/overview.html

Une petite démonstration du plugin en action :

http://www.youtube.com/watch?feature=player_embedded&v=_fDpC_YftDg

Migration d’un port vmkernel d’un virtual switch standard vers un virtual switch distribué

Aujourd’hui j’ai rencontré la problématique suivante: J’ai voulu migrer le port vmkernel dédié au management traffic d’un virtual switch standard existant vers un virtual switch distribué depuis le vSphere Client mais cela n’a pas fonctionné correctement.

La procédure en temps normal est de s’assurer d’avoir une redondance réseau (nic teaming) au niveau du vmkernel portgroup du Vss avant de procéder à la migration vers un dvportgroup d’un vDs. On rajoute le host depuis l’interface Networking (Home -> Networking) du vSphere Client en prenant le soin de sélectionner une seule des deux cartes réseaux faisant partie du nic teaming pour le port vmkernel à migrer vers le vDs. Malheureusement lors de cette phase de migration, la carte réseau à migrer avec la configuration IP du vmkernel se retrouve systématiquement sur le premier DvUplink créé sur le vDs ; or ce DvUplink1 n’a pas la bonne configuration associé pour le management traffic (Vlan ID). Le host se retrouve alors dans un état isolé et n’est plus joignable.

Pour résoudre ce problème et migrer correctement son port vmkernel sur le dvportgroup correspondant au management traffic, il faut passer par une remote console (de type KVM ou iLO) et activer le local tech support mode puis faire alt+F1 pour passer en mode support. Une fois en mode support, faites un esxcfg-vswitch -l pour lister la configuration active des switchs virtuels standard et distribués.

Vous verrez alors un DVport ID attribué pour un client de type vmk0 (qui correspond au vmkernel management traffic) et la carte réseau attribué au premier DVPort ID (attribution réalisée de façon automatique lors de la tentative précédente de migration via le vSphere Client). Il faudra alors réattribuer la carte réseau du premier DVPort ID au DVPort ID correspondant au DVportgroup du management traffic (avec la bonne configuration VLAN associée)

Procéder alors comme suit :

1) esxcfg-vswitch -Q vmnic -V DVPortID_1 dvSwitch_name (permet de retirer la carte du DVPort ID mentionnée par DVPortID_1 )

2) esxcfg-vswitch -P vmnic -V DVPortID_mgmt_traffic dvSwitch_name (permet de réattribuer la carte réseau au DVPortID correspondant au DVPortgroup du management traffic sur le vDs)

Le host ne se retrouve plus isolé et vous avez correctement réalisé la migration de votre port vmkernel d’un switch virtuel standard vers un switch virtuel distribué.

PXE Manager for vCenter

Vous cherchez la façon la plus simple pour déployer vos serveurs ESXi 4.1 ? Un serveur de déploiement administrable depuis vCenter via l’installation d’un plugin ? Tout cela est maintenant possible grâce à PXE Manager pour vCenter. Ce serveur de déploiement a été développé par Massimiliano Daneri et est téléchargeable sur la page des VMware Labs.

Au menu de ce plugin PXE Manager for vCenter :

– Automated provisioning of new ESXi hosts stateless and statefull
– ESXi host state (firmware) backup, restore, and archiving with retention
– ESXi builds repository management
– ESXi Patch management
– Multi vCenter support
– Multi network support with agents
– Hosts memtest
– vCenter plugin
– Deploy directly to VMware Cloud Director
– Deploy to Cisco UCS blades

Vcenter est maintenant totalement autonome grâce à ce plugin ; il est maintenant possible de gérer l’installation, la configuration et l’administration de la machine physique jusqu’à la machine virtuelle depuis son vSphere Client. A vous de tester !!!

Supprimer un plugin obsolète dans vCenter Server 4.1

Il arrive parfois que d’anciens plugins soient encore présents depuis votre plug-in manager ; ces plugins dont vous n’avez plus forcément besoin (suite à l’installation – désinstallation de diverses appliances virtuelles par exemple) peuvent très vite polluer votre plug-in manager.

template-error

Voici la méthode à suivre pour supprimer un ou plusieurs plugins obsolètes :

1. Dans un navigateur internet, accéder à l’url suivante : http://<vcenter server name ou IP>/mob (où “vcenter server name ou IP” est le nom de votre serveur vCenter ou son adresse IP)

2. Cliquer sur Content

3. Cliquer sur ExtensionManager

4. Choisisser et copier le nom du plugin que vous souhaitez supprimer

5. Cliquer sur UnregisterExtension. Une nouvelle fenêtre apparaîtra.

6. Coller le nom du plugin que vous souhaitez supprimer et cliquer sur Invoke Method. Le plugin sera alors supprimé

7. Fermer la fenêtre

8. Faites un refresh de la fenêtre :
Managed Object Type:ManagedObjectReference:ExtensionManager afin de vérifier que le plugin a été correctement supprimé

Vous n’avez plus qu’à essayer 🙂

VMware vCenter Error Call “PropertyCollector.RetrieveContents” for object “propertyCollector” on vCenter Server failed

J’ai rencontré le problème suivant aujourd’hui en tentant de modifier les paramètres d’un Template reconverti en VM pour mes besoins :

template-error

Il m’était alors impossible de modifier les paramètres de mon Template converti en VM. Voici l’astuce qui permet de pouvoir modifier à nouveau les paramètres d’un Template converti en VM suite à ce message d’erreur :

1) Il faut enlever la VM de l’inventaire depuis votre vSphere Client (clic droit puis “Remove fron inventory“)

2) Rajouter à nouveau la VM depuis le Datastore où elle se trouve (clic droit puis “Add to inventory“)

3) Editez à nouveau les paramètres de votre Template reconverti en VM (clic droit sur la VM puis “Edit Settings

Quelle est la raison de ce bug ? Après avoir cherché sur plusieurs forums sur Internet, il s’avère qu’il s’agit d’un bug affectant une migration en vSphere 4.1 depuis vSphere 4.0 (la migration vers vSphere 4.0 Update 2 cause aussi le bug apparemment). Les Templates existants, une fois migré en vSphere 4.1, présenteraient ce bug aléatoire.

Debugging de VPXD.exe (VMware Virtual Center Server service)

Cette semaine, j’ai voulu réinstaller un vCenter Server en Windows 2008 server x64 du fait que mon vCenter Server actuellement utilisé était sous Windows 2003 server 32bits. J’ai donc procéder à l’installation complète de vCenter avec les paramétrages adéquats (connexion à la base de donnée via DSN configuré, installation des modules vCenter additionnels) ; lors de la tentative de démarrage du service vCenter Server avec un compte de service possédant les droits requis, ce dernier refusait de démarrer sans plus d’infos dans le journal des évènements de Windows. Je me suis alors posé la question de savoir s’il était possible d’avoir des options de debugging pour le service vpxd.exe (VMware vCenter Server service). Il existe donc bien des options de lancement pour vpxd.exe

Le chemin d’accès à vpxd.exe est le suivant :

C:\Program Files (x86)\VMware\Infrastructure\VirtualCenter Server

Lancez donc vpxd.exe depuis ce path à l’aide d’une invite de commande cmd et rajoutez-y l’option /? ; les options possibles pour vpxd sont alors :

-r          Register VMware VirtualCenter Server
-u         Unregister VMware VirtualCenter Server
-s         Run as a standalone server rather than a Service
-c         Print vmdb schema to stdout
-o         port Listens on the specified port instead of 902
-b         Recreate database repository
-p         Reset the database password interactively
-P pwd  Reset the database password to the specified password
-v         Print the version number to stdout

J’ai donc utilisé l’option -s avec vpxd.exe pour tenter de le lancer en mode Standalone server et non en tant que service ; j’ai pu ainsi voir dans mon invite de commande que l’instance de base de donnée à laquelle vpxd voulait se connecter était en cours d’utilisation par une autre instance de VMware vCenter Server. Il suffisait juste d’arrêter le service vCenter Server présent sur l’autre machine installée en Windows 2003 serveur.

Grâce à ce problème rencontré, j’ai pu ainsi découvrir les options disponibles pour vpxd.exe ; En cas de dépannage, ceci peut donc s’avérer utile pour procéder à toute modification ou débugging du service vpxd.exe (vCenter Server service).