Posted by NiTRo | Filed under Kb, VMware
Si vous planifiez d’utiliser l’appliance vMA de VMware pour collecter les log des ESX (on parle évidement d’ESXi car il semble qu’ESX vienne de tirer prématurément sa révérence) et de vCenter, limitez vous aux ESX si le vCenter est en 4.1 car un bug viendra littéralement flooder les tables VPX_EVENT et VPX_EVENT_ARG de la VCDB.
Si c’est déjà trop tard, ou pire si comme sur notre lab votre VCDB est full (à cause de la limitation à 4Go de la version SQL Express 2005, poussé à 10Go sur la version 2008R2 au passage), il vous faudra faire un truncate de VPX_EVENT et si besoin utiliser le script posté par Frank Brix Pedersen sur son blog pour purger la table VPX_EVENT_ARG (en raison de contraintes sur la table).
Pour vous donner un ordre d’idée, on parle de plusieurs Go par jour :
Ce bug est d’autant plus sournois qu’il n’apparaît pas immédiatement et semble attendre que la victime soit en confiance avant d’agir (et difficile à reproduire de surcroît)…
Tags: bug, vCenter, VIMA, vMa
Posted by NiTRo | Filed under HowTo, Kb, Tips & Tricks, VMware
Si malgré tous vos efforts vous vous manger encore des horribles messages en français qui piquent les yeux dans la console PowerCLI, dans le vSphere Client ou par mail, il ne vous reste qu’une seule solution inspiré d’une kb anodine : How to change the language of vSphere email alerts
Pour échapper au massacre (en partie seulement car malheureusement certain éléments comme les alarmes ne changent pas), il faut recopier le contenu du répertoire ”C:\Program Files\VMware\Infrastructure\VirtualCenter Server\locale\en” dans “C:\Program Files\VMware\Infrastructure\VirtualCenter Server\locale\fr” (sans faire de backup car vous n’en voulez VRAIMENT plus) et de suivre le même mode opératoire pour les sous répertoires “C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions” où sont stockés les plugins du vCenter.
Par contre :
VMware does not officially support this method and must be done at your own risk.
Tags: vCenter
Posted by NiTRo | Filed under HowTo, VMware
Voici un petit oneliner (inspiré d’un post de LucD) qui vous permettra de changer la politique de placement du fichier swap des VM membres des resource pool dont le nom contient le mot “qualif” :
Get-View -ViewType ResourcePool|?{$_.name -match "qualif"}|?{$_.Vm.count -gt 0}|%{(Get-View $_.vm)|?{$_.Config.SwapPlacement -ne "vmDirectory"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{SwapPlacement="vmDirectory"}))}}
Dans notre cas, pour économiser l’espace disque sur notre SAN, les fichiers .vswp sont redirigés sur les disques locaux des ESX mais la consolidation allant bon train nous nous sommes retrouvés dans une situation où l’espace disque local n’est plus suffisant. Les VM membres des resource pool de qualif/test/dev étant stockées sur des partages NFS, nous avons pris la décision de bypasser la politique pour ces dernières et de laisser le fichier dans le répertoire de la vm.
Par contre, n’oubliez pas que sur du stockage “thin provisioné” l’espace du fichier de swap n’étant pas reservé, l’admition control est faussé. Mais j’espère pour vous que n’en êtes pas au point de remplir les fichiers swap de vos VM (même si un jour cela pourrai devenir une option grâce aux SSD) 
Tags: oneliner, PowerCLI, powershell, scripting, swap
Posted by NiTRo | Filed under HowTo, Kb, Tips & Tricks, VMware
Pour pouvoir bénéficier des avantages d’ESX 4.1 il faut un vCenter 4.1 ; mais entre la nécessité d’une migration en 64 bit et la mauvaise réputation de la 4.1 qui nous a fait attendre la 4.1 U1, nous avons patientez. Mais surtout nous avons maquetté ! Car l’un des avantages indiscutables d’avoir un vCenter+VCDB en VM est de pouvoir en faire un clone (isolé de votre réseau surtout) et d’effectuer une fausse vraie migration à blanc sans perturber la production et surtout cela vous laisse tout le temps pour éviter de gros problèmes et vous épargnera une nuit blanche + sueurs froides.
Pour commencer, il faut suivre la KB1017390 pour démarrer le service vpxd lorsqu’il est isolé du domaine AD auquel il est rattaché. Ensuite, pour s’assurer que le vcenter fonctionne bien en “mode isolé” vous avez tout intérêt à rattacher quelques nested ESX dans le même Virtual Intranet. Vous pouvez maintenant faire autant de snapshot et de revert que nécessaire pour valider chaque étape de la migration et surtout décortiquer chaque problème que vous pourrez rencontrer. Vous aurez également le loisir de tester vos scripts et procédures afin de pouvoir les adapter à l’avance. En bref, c’est 100 fois plus productif que de maquetter une migration d’un vcenter fraîchement installer pour l’occasion (ce que nous faisons tous de toute façon).
Pour vous donner une idée de ce que cela nous a évité, voici la liste des kb et liens qui nous ont été indispensables pour venir à bout de cette migration :
Au final, en plus d’avoir pu faire une migration en production (avec l’aide de notre poto vmDude) sans le moindre problème, nous avons également encore beaucoup appris sur le fonctionnement du vCenter et de la VCDB. Du win-win en gros 
Tags: vCenter
Loading ...
