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 :
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.
Il arrive que ,depuis la console (ouverte depuis vSphere Client), l’administration d’une VM sous Windows Server 2008 R2 ou encore Windows 7 soit ralentie (curseur de la souris assez lent, temps de réponse de la VM depuis la console assez long).
Ceci est assez génant, et est dû au fait que les pilotes SVGA-II installés par défaut par les VMware Tools soient buggués.
Voici la démarche à suivre pour corriger ce problème :
1) Mettre à jour ses VMware Tools avec la dernière version
2) Mettre à jour manuellement le pilote SVGA-II depuis le gestionnaire de périphérique en le remplaçant par le pilote VMware SVGA 3D (Microsoft Corporation – WDDM) ; ce dernier se trouve à l’emplacement suivant : “C:\Program Files\Common Files\VMware\Drivers\wddm_video”
3) Redémarrez la VM et retournez vérifier dans le gestionnaire de périphérique que vous avez bien le nouveau driver SVGA d’installé :
Maintenant vous ne devriez plus rencontrer ce bug affectant l’administration d’une VM sous Windows Server 2008 R2 et Windows 7 depuis la console de votre vSphere Client.
Il arrive que ,suite à la migration de votre environnement vSphere 4 vers la version 4.1, votre client vSphere soit passé entièrement dans la langue de Molière. Pour ceux qui étaient habitués à leurs menus en anglais, voici l’astuce permettant de les retrouver :
Il faut modifier le chemin cible du raccourci de votre vSphere Client avec l’élément suivant :
– Avant modification : « C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe »
Après de longs mois d’absences pour diverses raisons (personnelles et professionnelles), me voilà de retour avec tout plein de nouveaux posts pour vous 🙂
En espérant que vous allez continuer à venir nombreux sur mon blog technique dédié à la virtualisation Vmware.
Depuis Janvier 2010, VMware a sorti un produit du nom de VMware GO permettant de gérer les serveurs sous VMware ESXi 4. Il s’agit d’une console web qui permet d’initialiser et de patcher les serveurs ESXi 4, de créer et exploiter les machines virtuelles, appliquer les patchs aux VMs. Ce produit s’installe comme une application hébergée sur une machine Windows XP SP3, Vista SP2 ou encore Seven et est ensuite utilisée comme un proxy vers les serveurs VMware ESXi 4.
Les composants logiciels suivants sont nécessaires pour le bon fonctionnement de VMware GO :
– Microsoft .NET framework
– PowerShell
– VMware vSphere Power CLI
– La Remote Console
– VMware Converter Stand-Alone
Cette semaine, VMware a annoncé l’ajout de nouvelles fonctionnalités pour son produit VMware GO ; parmi ces nouvelles fonctionnalités on retrouvera :
– La possibilité de réaliser du Virtual to Virtual (V2V)
– La migration de VMware Server vers ESXi (Pour information, en juin 2011 VMware Server ne sera plus maintenu par VMware)
– Le Collective Intelligence Engine qui permettra de collecter des informations depuis la communauté des utilisateurs afin de proposer des préconisations sur les OS Guests installés sur ESXi, le nombre de VMs par ESXi, le top 5 des appliances installées,…
Pour plus d’informations sur VMware GO, n’hésitez pas à aller sur leur site.
En bonus, je vous donne également le lien vers une Training video de David Davis expliquant comment implémenter et utiliser VMware GO pour ESXi 4.0 :
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).
vSphere Management Assistant 4.0 est une machine virtuelle basée sur une distribution Linux packagée avec les vSphere CLI (command line interface) et avec le SDK vSphere pour Perl. vMA peut-être utilisé par les administrateurs pour lancer des scripts distants sur des serveurs ESX/ESXi ou encore pour administrer ces derniers. Vcenter Server 4 peut également être géré par vMA.
Pour installer vMA 4 , rien de plus simple, il suffit juste de déployer l’OVF associé sur votre infrastructure virtuelle. Voici le lien pour récupérer l’OVF de vMA 4 : vMA OVF
Voici la vidéo vous permettant de suivre en vidéo le déploiement complet de vSphere Management Assistant 4 :
Au travers de cette vidéo vous verrez également l’utilisation des commandes suivantes à travers vMA 4 :
– vifp (authentification fastpass pour management distant des hôtes ESX/ESXi et des vCenter Server) : cette commande vous permettra d’enregistrer les informations de connexion propre à chaque hôte ESX/ESXi et/ou vCenter Server ; un exemple de syntaxe pour ajouter les infos de connexion d’un serveur ESX : vifpaddserver“esx_server” —username“user” —password“mdp”
– vifpinit (activation de l’authentification fastpass) : cette commande vous permettra d’activer l’authentification fastpass sur un serveur ESX/ESXi ou un vCenter Server que vous souhaitez administrer depuis votre vMA. Il faut ,bien sûr, au préalable avoir enregistré les informations de connexion aux serveurs désirés à l’aide de vifp ; un exemple de syntaxe pour activer la connexion à un serveur particulier : vifpinit“esx_serveur”
– vicfg-xx : vicfg est un ensemble de commandes de management et d’administration utilisées une fois connecté sur le serveur souhaité depuis la vMA à l’aide de la commande vifpinit. Parmi les commandes vicfg, on retrouve la commande vswitch, la commande mpath ou encore la commande nics. Pour utiliser ces commandes, la syntaxe est la suivante : vicfg-command -arguments. Par exemple, pour lister l’ensemble des cartes réseaux physiques présentes sur un serveur ESX, la commande suivante sera exécutée : vicfg-nics -l
Il existe un grand nombre de commandes exécutables depuis la vMA. Pour avoir plus d’informations concernant toutes les possibilités offertes par vMA 4.0, vous pouvez lire le guide de vMA édité par VMware en suivant ce lien.
VMware Data Recovery , outil de sauvegarde et de restauration des VMs proposé par VMware, sort aujourd’hui dans sa version 1.2
Quelles sont les nouveautés apportées par cette version 1.2 ?
La restauration au niveau fichier (FLR, File Level Restore) est désormais disponible pour utilisation avec Linux.
Chaque instance de vCenter Server prend en charge jusqu’à dix dispositifs de sauvegarde Data Recovery.
Le plug-in vSphere Client prend en charge une commutation rapide entre les dispositifs de sauvegarde Data Recovery.
Améliorations diverses apportées à l’interface utilisateur du plug-in vSphere Client, notamment :
La possibilité de nommer les tâches de sauvegarde durant leur création.
Des informations supplémentaires portant sur le statut actuel des disques de destination, notamment l’état du disque et le gain de place réalisé grâce aux optimisations du magasin de déduplication.
Des informations sur la banque de données à partir de laquelle les disques virtuels sont sauvegardés.
Pour plus d’informations concernant la version 1.2 de VDR, cliquez sur le lien suivant : VDR 1.2 Release notes
Lors de la prochaine sortie de la version 4.1 de VMware vSphere (vers la fin de l’année normalement), de nouveaux maximums seront à prendre à compte comparativement aux valeurs que nous connaissons actuellement sur la version 4.0 de vSphere. Voici la liste des ces nouveaux maximums atteints avec vSphere 4.1 :
– 3,000 virtual machines per cluster (compared to 1,280 in vSphere 4.0)
– 1,000 hosts per vCenter Server (compared to 300)
– 15,000 registered VMs per vCenter Server (compared to 4,500)
– 10,000 concurrently powered-on VMs per vCenter Server (compared to 3,000)
– 120 concurrent Virtual Infrastructure Clients per vCenter Server (compared to 30)
– 500 hosts per virtual Datacenter object (compared to 100)
– 5,000 virtual machines per virtual Datacenter object (compared to 2,500)
Encore une fois VMware nous montre qu’il est toujours possible de repousser les limites mises en place avec sa suite vSphere avec sa prochaine version 4.1 ; Pour toutes les architectures existantes ou à venir, cela permettra encore plus de flexibilité. Merci VMware !!
