Tweakons cette saloperie de vCenter

Après une migration, réalisée avec succès – on oubliera la petite heure passée en mode Fin du Monde quand l’AD du clent s’est mis à déconner suite à un truc qui n’a rien à voir avec cette migration mais que Murphy… –, de vCenter, il faut remettre en place les petits paramétrages non officiels qui vous facilitent la vie en améliorant les performances et en évitant des incidents.

1- Ajouter une dépendance sur le démarrage du service VMware VirtualCenter Server
Si comme moi vous utilisez, pour une petite infrastructure, SQL Server Express livré de base avec vCenter, vous pouvez constater que, de temps en temps, quand vous redémarrez votre serveur, le service VMware VirtualCenter Server se plante au démarrage car il démarre plus vite que le service SQL Server.
C’est très con.
Donc, le but du jeu, c’est de faire en sorte que le service VMware VirtualCenter Server ne démarre que quand la partie SQL Server est fonctionnelle. Donc créer une dépendance.
Bien évidement, chez Windows, créer une dépendance sur le démarrage d’un service ne se fait pas simplement. Naaaan. Ce serait trop sympa.
Il faut donc mettre les mains dans le camboui et dans la base de registres.
Il faut donc localiser le répertoire suivant : HKLMSYSTEMCurrentControlSetServices. Puis, il faut trouver l’entrée vpxd, qui est l’entrée pour le service VMware VirtualCenter Server. Dans vpxd, localisez la clé DependOnService qui est du type REG_MULTI_SZ. Si vous éditez cette clé, vous devez normalement voir qu’elle contient déja deux entrées : ProtectedStorage et lanmanworkstation. Il faut alors ajouter une troisième ligne représentant le service SQL Server. Dans mon système, l’entrée pour SQL Server s’appelle MSSQL$SQLEXP_VIM. Vous êtes censés trouver cette entrée aussi dans HKLMSYSTEMCurrentControlSetServices. Surtout ne pas rajouter une ligne vide, vous feriez planter le service. Une fois l’entrée concernant le service SQL Server ajoutée, vous pouvez fermer la base de registres et vérifier directement que le service VMware VirtualCenter Server a bien une nouvelle dépendance.

2- Augmenter la taille du journal des transactions de la base SQL
Il arrive de temps en temps qu’il y ait un problème avec le journal de transaction de la base SQL Server. – ici dans sa version Express. – Si ce journal est plein, votre service vCenter va planter. Vous pourrez alors voir dans les logs vCenter un message assez explicite. Les logs se trouvent – sur un serveur Windows 2008 R2 – dans C:UtilisateursAll UsersVMwareVMware VirtualCenterLogs. Ce sont les fichiers vpxd-XX.log. Un nouveau fichier est créé à chaque démarrage du service VMware VirtualCenter Server.
Pour pouvoir modifier les paramétrages du journal des transactions de votre base, il faut avoir récupérer les outils d’administration de base qui ne sont pas installés par défaut. Il s’agit, pour une base en SQL Server 2005 Express, de "Microsoft SQL Server Management Studio Express". Qui vient en version 32 ou 64 bits. Il existe aussi une version pour SQL Server 2008 Express.
Une fois ces outils récupérés et installés, connectez-vous à votre base SQL correspondant à votre vCenter.Dans la partie Base de données, faites un clic droit sur la base correspondant à votre vCenter – qui s’appelle chez moi VIM_VCDB – et choisissez Propriétés. Choisissez ensuite Fichiers. Vous avez alors deux entrées. Une de type Données qui est la base et une de type Journal qui est le fameux journal de transactions. Pour résoudre les éventuels problèmes, ou pour en éviter, il faut augmenter la taille maximum du journal de transaction. Cette option est réglable dans la colonne Croissance Automatique. Il faut cliquer sur le petit bouton gris avec "…". Là, vous pourrez configurer la façon dont le journal augmente automatiquement de taille – ne pas toucher à ce paramètre – et la taille maximum du journal. Aujourd’hui, franchement, n’hésiter pas à mettre 2048 Mo. Le journal pourra ainsi grandir jusqu’à 2 Go. Et normalement, il n’y aura pas de problème.

A noter que sur une ancienne mission, le vCenter reposait sur une base Oracle et plantait régulièrement à cause d’espace insuffisant sur le tablespace temp.

KB VMware

3- Reconstruction des indexes
Quatre tables posent problème pour vCenter. Ces quatre tables receuillent les informations de statistiques des serveurs ESX, des VMs et de l’ensemble de l’architecture. Ce qui fait que leurs indexes se fragmentent extrêmement rapidement. Ce qui entraîne des baisses des performances assez sensibles quand on consulte les sections liées aux graphes de performances et autres dans vCenter.
Pour solutionner le problèmes, il faut reconstruire les indexes en question de façon régulière. Dans un système de gestion de bases de données classique, cela se ferait sans problème. Par contre, quand vous avez SQL Server Express, c’est plus problèmatique. Comme c’est la version gratuit de SQL Server, certaines choses ne sont pas présentes et notament les plans de maintenance.
Donc, pour réindexer les quatres tables en questions, il faut faire un petit script SQL – avec Management Studio, c’est très facile à faire- qui sera lancer en ligne de commande.
Le script SQL ressemble à ceci :
USE [VIM_VCDB]
GO
ALTER INDEX [PK_VPX_HIST_STAT1] ON [dbo].[VPX_HIST_STAT1] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT2] ON [dbo].[VPX_HIST_STAT2] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT3] ON [dbo].[VPX_HIST_STAT3] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO
ALTER INDEX [PK_VPX_HIST_STAT4] ON [dbo].[VPX_HIST_STAT4] REBUILD WITH
( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  =
ON, ALLOW_PAGE_LOCKS  = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY  =
OFF, ONLINE = OFF )
GO

Pour le lancer en ligne de commande, ça peut ressembler à ça :
sqlcmd -S .SQLEXP_VIM -i "D:Reconstruction_IndexReconstruction.sql" >> Log.log

Bon, c’est tout mais c’est déjà pas mal.

 

——

Après un deuxième plantage suite à une saturation du journal de transactions, il a fallu que je regarde un peu plus le pourquoi du remplissage excessif de ce fichier. Avant la migration en vCenter 4.1, je n’avais pas eu le problème.
Après quelques recherches, il apparaît que ma base n’était pas configurée correctement au niveau du Recovery Model. – Ce qui est dommage, c’est que c’est configuré automatiquement lors de l’installation de vCenter et de SQL Express. – Il faut donc, pour la base vCenter, mettre le Recovery Model à Simple.

KB VMware

Ciné Navet – la programmation estivale

Les vacances arrivent bientôt – les miennes – et donc l’exil vers un coin tranquille quelques jours. – Même si on me glisse à l’oreille que le net a débarqué dans le coin… – 

Durant ces quelques jours, un certain nombre de navets risquent d’être visionnés à des heures où des gens normaux dormiraient.

Au programme, plus ou moins, vu que ça dépendra que ce qui aura été récupéré et des éventuels outisiders :

Attention, le visionnage de ces bande-annonces peut provoquer des dommages cérébraux irréversibles.

Fatal
(Ok, il est sorti il y a peu et certaines l’ont déjà vu au ciné. Mais bon… Faut savoir que Fatal Bazooka, c’est un peu une partie de la bande-son des deux dernières années.)

Et un deuxième pour bien vous faire souffrir.

Le Mac

 

Solomon Kane

La loi de Murphy

GI Joe

Cineman

Ultimate Game

Vendredi 13

Cyprien

Lucky Luke

Alien Vs Hunter

A nightmare on Elm Street

Ninja Assassin

Universal Soldier Regeneration

Legion

Lesbian Vampire Killers

Mega Shark vs Giant Octopus

Alien Vs Pretador 2

Kung Pow

 

 The Calamari Wrestler

Sharktopus (Beirla, ça c’est de ta faute…)

Trailers à la con

Suite au visionnage du trailer de Sharktopus, et à sa diffusion à quelques amis fans de Mega Shark vs Giant Octopus, le délire est un peu reparti sur le thème "Les Navets ultimes à voir pendant les vacances" avec la proposition de Wolfhound.
Et en cherchant le trailer de Wolfhound sur Youtube, je suis tombé sur quelques trailers qui prouvent que ce genre de films existe depuis des décennies :

 

Hercules

Hercules II

Starcrash – Comme quoi Lucas a rien inventé – (Correction, comme quoi, on peut faire des choses terribles en piquant des idées à Lucas)

 

 Galaxina

 

Et pis un petit chef-d’oeuvre en supplément :
Zardoz, avec Sean Connery

Upgradons un vCenter en 4.1…

… dans la joie et la bonne humeur. Enfin, non, pas vraiment dans la joie et la bonne humeur.
Comme je l’ai dit dans mon message précédent, VMware a décidé de modifier sérieusement les prérequis pour l’installation d’un vCenter et impose un OS 64 bits désormais. Pas d’OS 64 bits ? Pas de vCenter 4.1.
Aujourd’hui, même si les processeurs 64 bits et les OS 64 bits existent depuis maintenant quelques années, le besoin réel de tels architectures ne se fait pas vraiment sentir et si il n’y avait pas quelques constructeurs ou éditeurs – genre Microsoft et la dernière version de certains produits type Exchange – pour forcer plus ou moins leurs adoptions.

Pourquoi VMware force cette adoption du 64 bits pour son vCenter ? Excellente question. En recherchant sur le site de l’éditeur, vous trouverez sans doute la réponse. Une bonne grosse réponse langue de bois à n’en pas douter. Pour ma part, je pense que c’et surtout parce qu’une faible partie du vCenter a besoin, dans certaines configurations, de plus de 4 Go de RAM pour fonctionner. Et, évidement, pour gérer de telles quantités de mémoire, il faut du 64 bits. Mais bon, ça, c’est pour les grosses infrastructures. Pour les petites, comme chez mon client actuel, ce besoin n’est pas présent.

Pourquoi je m’embête à vouloir upgrader le vCenter de mon client alors que je vais bientôt le quitter, et que je pourrais laisser cela à la charge de mon successeur ?
– Parce que c’est une opération que je serais amener à faire pour mes futurs clients.
– Parce que je veux laisser une infrastructure à jour à mon client en partant. Je fais les choses correctement jusqu’à la fin.
– Parce que je n’ai aucune confiance en mon éventuel successeur pour faire les choses correctement. C’est malheureux d’en arriver là, mais bon… En l’état actuel des choses, quand on se renseigne un peu sur le marché et sur les autres boites, on constate que le taux de tocards branleurs est de plus en plus élevé en informatique. – Non, je n’ai pas honte de dire ça. –

Donc comment upgrader un vCenter de la version 4.0.0 à la version 4.1 ?
Contexte : deux serveurs ESX 4, en cluster DRS et HA, avec une baie iSCSI et un vCenter virtuel sur un OS 32 bits. Le vCenter héberge la base de données, qui est sous SQL Express 2005. Peu ou pas de prod sur les VMs. Peu d’utilisation du vCenter en cette période, à part l’espèce de con qui veut le migrer. Donc possibilité de faire la migration de vCenter en pleine journée sans problème.
Le but : migrer le vCenter sur un serveur à OS 64 bits, sans perdre toute la configuration. (les pools de ressources, l’organisation de l’inventaire, le cluster, la configuration d’Update Manager, etc, etc…)
Les tests, méthodes, outils et autres utilisés :
VMware, dans sa grande générosité – j’ai vraiment envie de les pendre par les couilles avec cette histoire –, fournit un petit outil permettant de faire cette migration. "vCenter Server Data Migration Tool". Ce petit outil permet de faire un backup de la configuration du vCenter, de sa base et d’Update Manager. (même des patchs récupérés par Update Manager)
Sauf que… Ca ne migre que les bases SQL Express 2005 – là, j’ai bon – et que ça conserve le nom du serveur vCenter et son IP dans les fichiers de configuration. (Voir les gentils kbs chez VMware et ) Et là… Vous haïssez encore plus VMware… Parce que si vous migrez, c’est vers un autre serveur histoire d’avoir un downtime minimum et un minimum de sécurité en conservant l’ancien serveur le temps de la migration. Donc serveur différent, nom différent et IP différente. – dans une architecture un minimum sérieuse, avec genre un AD… –
Le backup avec leur gentil outil : arrêt des services VMware du vCenter, exécution de la ligne de commande adéquate, interaction minimum vu que la question la plus critique doit être d’indiquer si oui ou non vous voulez sauvegarder les mppppfff Go de patchs. Au final, j’ai obtenu un peu moins de 2 Go de backup, base comprise.
Que j’ai gentillement copié sur mon nouveau serveur tout neuf en Windows 2008 R2 64 bits. Et j’ai fait un snapshot – serveur virtuel, c’est mieux pour faire des tests – avant de faire l’installation, histoire de pouvoir la rejouer en cas de problème. Et j’ai bien fait.
J’ai donc lancé l’installation à l’aide du gentil outil de VMware. Qui me signale rapidement que le nom du serveur n’est pas le même que l’ancien. Mais proposer de le changer, ça doit être trop demander… L’installation / restauration se fait sans trop de problème, avec quand même pas mal de question de la part du programme. Puis arrive la restauration de la partie Update Manager. Et le drame. Il faut lui préciser si il utilise une nouvelle base ou si il doit pointer sur une ancienne. L’option 1 permettra de finir l’installation, mais si vous essayez d’utiliser Update Manager, ça ne marchera pas. L’option 2 vous permet de pointer vers votre base qui vient d’être restaurée – si vous êtes en SQL Express – ou vers une autre base si elle est déportée. Pour se faire, il faut créer un lien ODBC. Et accrochez-vous… Un lien ODBC 32 bits. Et là, la politesse n’est même plus une option la prochaine fois que vous parlerez à un représentant de VMware. Ils imposent un passage au 64 bits mais pour certains composants, il faut rester au 32 bits. Tas de *BIPS* !!!!!!
Donc, pour créer un lien ODBC sur Windows 2008 R2, il ne faut pas passer par l’exécutable habituel car il ne crée que des liens 64 bits. Il faut lancer %windir%SysWOW64odbcad32.exe. Et si votre base n’est pas déportée, il faut le faire entre le moment où vCenter et sa base sont restaurés et le moment où Update Manager s’installe.
Donc, au bout de quatre tentatives d’installation, j’ai eu un vCenter fonctionnel, reconnaissant mes serveurs ESX, reconnaissant le cluster, ayant récupéré toutes les informations nécessaires. Mais… Qui croit s’appeler du nom de l’ancien serveur, y compris pour la partie licenses. Autant dire, un truc totalement bancal et impossible à utiliser et à maintenir en production.

Après ces différentes tentatives de migration, il faut être réaliste.
Si vous avez une base déportée, vous pouvez vous en sortir assez bien, avec un downtime minimum.
Si vous avez une base SQL Express sur le même serveur que le vCenter, vous serez obligé de migrer sur un serveur du même nom avec la même IP.
C’est ce que je vais faire demain.
1- Backup du serveur vCenter 4.0, avec l’outil Data Migration de VMware, avec votre solution de sauvegarde favorite et un snapshot si votre serveur est virtuel. On est jamais trop prudent.
2- Copie du résultat du Data Migration vers le nouveau serveur.
3- Arrêt du vCenter 4.0
4- Renommage du nouveau serveur avec le nom de l’ancien. – si votre serveur est dans un AD, vous voyez les problèmes qui vont se poser si il faut faire retour arrière. – Ne surtout pas rebooter à ce moment là.
5-Changement d’IP du nouveau serveur pour celle de l’ancien.
6- Reboot.
7- Installation / restauration de vCenter, avec les galères de lien ODBC.
8- On prie, on teste et on constate.

Solution de retour arrière : vous éteignez le nouveau serveur. Vous rallumez l’ancien. Et si vous êtes en AD, ben… disjoin / join au domaine. En espérant que la base SQL Express n’explose pas pour des problèmes d’authentification…

 

Encore une fois, merci à VMware pour cette migration forcée, merci pour l’outil de migration merdique. Quand on voit ce que l’on paye en maintenance obligatoire annuelle, c’est franchement du foutage de gueule…

VMware : serait-ce le début de la fin ?

En 2003 – 2004, je découvrais un peu par hasard la virtualisation. Dans ma branche, c’est un peu LA révolution technologique de ces dernières années, qui bouleverse énormément de choses, qui s’infiltre partout, et qui permet à votre serviteur d’être payé grassement et de changer facilement de boucherie.
Depuis le début, je suis fan, à mort, des produits de VMware. Cette entreprise propose juste les solutions les plus matures de virtualisation, que ce soit avec des hyperviseurs de type 1 ou 2, dans les fonctionnalités associées, dans la qualité des produits – à part l’ignoble Bug du 15 août 2008 – ou dans la facilité d’utilisation. – Missa dumb dumb et pourtant, j’arrive parfaitement à comprendre comment ça marche, à déployer et à administrer les architectures que je conçois avec ces produits. –

Mais… Parce qu’il y a un mais. Il y a toujours un mais. Rien n’est jamais parfait.
Il y a un mais qui commence à être de taille.
Depuis Juillet 2008, la dirigeante historique – et l’une des fondatrices – de VMware Diane Greene était subitement débarquée. Son départ fut suivi de celui de Mendel Rosenblum, chief scientist de VMware, et accessoirement mari de Diane Greene. Ces deux personnes étaient parmis les pierres angulaires de VMware.
Diane Greene a été remplacée par Paul Maritz, qui a pendant 14 ans été considéré comme le troisième homme chez Microsoft, derrière Bill Gates et Steve Ballmer.
Vous commencez à saisir le malaise ?
Depuis, un certain nombre de choses ont évoluées.
Technologiquement, VMware conserve toujours, et de loin, le lead et ma préférence. Par contre, commercialement, ça devient vraiment n’importe quoi.
Déjà, renommage des produits phares qui, de VMware ESX, ESXi, VirtualCenter et Virtual Infrastructure (bundle de ESX et VirtualCenter), sont passés à  vSphere, vSphere Hypervisor, vCenter Server, vCenter, ceci à l’occasion de du passage de la version 3.5 à la 4. Tout le monde s’y perd, personne ne s’y retrouve…
Pour ajouter à la confusion, les tarifs ont changés, les fonctionnalités regroupées en différents packs qui ne veulent rien dire, le pricing des licenses a changé… – On passe de licenses pour 2 sockets à des licenses pour un socket… –
Et là… VMware vient d’annoncer la version 4.1. Je me demande sérieusement ce qu’elle apporte de plus pour mériter le .1. Et surtout j’aimerais bien arriver à comprendre si mes serveurs actuels en 4.0, il va falloir que je les upgrade – processus long et complexe où il est souvent plus simple de réinstaller le serveur en nouvelle version et de le reconfigurer – ou si je dois le mettre à jour – processus simple et automatisé –. De même, est-ce que mes licenses en 4.0 sont toujours valables pour la 4.1. Sachant qu’ils viennent encore de changer les bundles et le pricing associé…

Pour moi, aujourd’hui, VMware est en perte de vitesse. Non pas sur le plan technologique, même si je pense qu’ils vivent sur les derniers travaux de Mendel Rosenblum plus que sur de réelles nouvelles avancées, mais sur le plan commercial. On est passé de quelque chose d’assez simple à une véritable usine à gaz.
Aujourd’hui, vu la place de plus en plus importante que prend la virtualisation, de nouveaux acteurs sont apparus, pour profiter du marché en expansion. Avec des solutions qui s’améliorent de jour en jour. Avec des pricing qui peuvent être intéressants. VMware a été le leader sur les années 2000. Pour les années 2010, je crains fortement qu’il ne soient sur la pente descendante… Et qu’ils soient en train de savonner cette pente…

Et là, j’ai un message pour les actionnaires de VMware et pour EMC, sa maison mère :
Virez Paul Maritz et remettez des gens compétents à la tête de cette entreprise.

 

— Update —
J’ai commencé à faire quelques tests sur la 4.1, notamment vCenter. Je voulais upgrader mon vCenter actuel en 4.1… Comment dire… Les pré-requis ont changé… Il faut désormais que le serveur devant héberger ce service ait deux processeurs 64-bits ou un processeur double-coeur 64 bits…
Mon vCenter actuel est sur une VM avec un OS 32-bits…
JE LES HAIS !