VSphere 5.1 on Zwindler's Reflection

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur

Mon, 30 Mar 2015 21:18:12 +0000

[Edit]MAJ le 19/10 avec quelques captures d’écran[/Edit]

Une manière simple de créer et de déployer des templates sous ESXi lorsqu’on ne dispose pas du vCenter et de la licence qui va bien est d’utiliser les templates OVF/OVA (cf un de mes tous premiers articles). Je l’utilise d’ailleurs toujours aujourd’hui pour pallier le manque de licences sur certains sites distants/secondaires.

Cependant, depuis la version 5 (ou peut être 5.1), j’ai été confronté à plusieurs reprises à l’erreur suivante lors du déploiement de l’OVA :

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur

WTF ? Pas de code d’erreur, et un message pas vraiment loquasse…

J’ai eu beaucoup de mal à trouver la réponse à cette erreur en Français et il a d’ailleurs fallu que je le traduise mot pour mot en anglais pour trouver des ressources pour m’aider :

Failed to deploy OVF package: The task was canceled by a user.

[Edit] En 5.5, j’ai également rencontré le message suivant qui donne un peu plus d’informations sur le problème réel :

OVF Deployment Failed: File ds:///vmfs/volumes/uuid/_deviceImage-0.iso was not found

[/Edit]

Et là on commence à trouver un peu d’aide sur le web. Parmi les liens intéressants sur le sujet, on peut citer le KB de VMware et lukebarklimore qui rentre un peu dans le détail de l’anatomie d’un OVF/OVA de chez VMware :

KB VMware (lien mort, comme d’habitude)
lukebarklimore.wordpress.com/2012/10/25/esxi-5-1-fixing-failed-to-deploy-ovf-package-the-task-was-canceled-by-a-user/

Ce qu’il faut en retenir, c’est :

un OVA n’est en fait qu’une simple archive tar (qu’on peut donc ouvrir avec un « tar xf » ou un 7zip pour les Windowsiens
Il contient un fichier .ovf au format XML qui respecte la norme des OVF (enfin, si on peut appeler ça une norme ! troll) et qui est en fait un descripteur du matériel virtuel de votre VM
un ou plusieurs fichiers .vmdk, vos disques durs virtuels
un fichier .mf qui ne contient en fait que le hash sha1 du fichier, pour le contrôle de la cohérence

Pour en venir au problème en lui même : il se produit lorsque les VMware Tools sont mal démontés ou se sont mal installés (ou mal terminé d’installer). La machine virtuelle garde en mémoire la présence de l’ISO et celui ci reste inscrit dans le descripteur OVF. Lorsqu’on déploie la VM, l’ISO n’est plus présent sur le serveur de destination et on obtient l’erreur susnommée.

Pour résoudre le problème, il faut donc :

Extraire le fichier OVF de l’archive OVA
Editer le fichier OVF, et remplacer la mention vmware.cdrom.iso par la valeur vmware.cdrom.atapi ou vmware.cdrom.remotepassthrough
Recalculer le nouveau hash SHA1 du fichier OVF édité
Recréer une archive et y ajouter DANS CET ORDRE les fichiers .ovf PUIS .mf et .vmdk.

tar xf maVM.ova #extraction des fichiers de l'archive
rm maVM.ova
vi maVM.ovf #si vous êtes sages je vous donnerai un "sed" pour éviter d'avoir à éditer le fichier
sha1sum maVM.ovf #récupérer le retour et remplacer le hash de l'OVF par la nouvelle valeur dans le fichier maVM.mf
tar cf maVM.ova maVM.ovf #recréation de l'archive
tar uf maVM.ova *.mf *.vmdk

Si vous omettez de recalculer le checksum, VMware vous expliquera bien gentiment que le checksum n’est pas bon, et donc l’archive toute entière, donc pas de flemme !

Et si vous ne les mettez pas dans cet ordre, vous aurez une autre erreur, très explicite cette fois ci qui vous expliquera que votre OVA est invalide car les fichiers ne sont pas dans le bon ordre… Oui… Vraiment.

[IRL] RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication

Wed, 11 Feb 2015 14:58:49 +0000

Contexte

Dans un contexte professionnel, il arrive que des décisions soient prises et qu’il faille s’y tenir coute que coute. Même si on se rend compte plus tard que ce n’était pas forcément le chemin le plus facile. La facilité, c’est le côté obscur, on le sait bien ;-).

Pour un client, on m’a donc demandé de concevoir une plateforme RedHat 5.X virtualisée hautement disponible, avec une durée d’interruption de service maximale de 30 minutes en toute circonstance (jusque là tout va bien), ET la possibilité de restaurer les disques des OS virtuels avec plusieurs points de restaurations par palliers de 30 minutes (RPO/RTO). Aie!

Tel le Mac Giver des temps modernes, je dispose des outils suivants pour y parvenir :

1 licence vSphere Essential Plus
2 serveurs physiques, installés en ESXi 5.5 et reliés en SAN
2 baies de disques EMC² VNX5200
2 souscriptions RedHat Datacenter - pour disposer d’autant de VMs RHEL qu’on le souhaite sur nos deux nœuds physiques
2 souscriptions RedHat High Availability (anciennement RedHat Cluster Suite) en mode Datacenter - pour disposer d’autant de clusters RedHat qu’on le souhaite sur nos deux nœuds physiques

Clusters RHCS et VMDK partagés ou RDM

Comme vous pouvez le deviner avec la dernière ligne, on m’a demandé d’utiliser les licences qui avaient été achetées. Donc de déployer du cluster RHCS à tour de bras, pour faire des paires de VMs et simuler ce que l’on fait habituellement sur des paires de machines physiques.

Sauf qu’à tenter de faire des clusters RHCS sur des machines virtuelles VMware, on trouve vite toute sortes de petits désagréments.

Note : Je vous demanderai de bien vouloir faire abstraction du fait que c’est vraiment « bourrin » de doubler des VMs lorsqu’on dispose d’un cluster vSphere. En fait, si j’en suis arrivé là, c’est parce qu’un simple cluster VMware HA ne répond pas à l’ensemble des besoins énoncés plus haut. C’est possible, bien sûr, mais il faut aller creuser peu plus loin (cf la fin de l’article).

Prérequis

VMware et RedHat supportent l’utilisation de cluster RHCS dans sur des machines virtuelles avec les obligations suivantes :

Support de vSphere 5.1 uniquement à partir de RHEL 5u9 ou 6u4
Support de vSphere 5.5 uniquement à partir de RHEL 5u11, 6u6 ou 7
Support du partage de disques via RDM à partir RHEL 5u7
Support du partage de VMDK à partir de RHEL 5u9

(Voir ici pour plus d’infos)

Idéalement, il faut donc disposer de machines virtuelles RHEL 5u11 et de vSphere en version 5.5 (version la plus à jour si on met de côté la 6 qui va sortir), mais on peut se « contenter » d’une version RHEL 5u9 en installant une version plus ancienne de vSphere (5.1).

Le cas le plus défavorable est l’utilisation de vSphere 5.0 avec un RHEL 5u7 ou 5u8. Dans ce cas, seul le partage de disques via RDM est possible et un bug connu dans la version 5.0 de vSphere empêche le fonctionnement opérationnel du cluster (au niveau du fencing).

Au-delà, ce n’est pas supporté.

Architecture

Cas de panneS

Les disques OS sont installés en RAID 1 MDADM avec 2 VMDKs situés sur les deux baies.

Si ce n’est pas le cas, en cas de la perte de la baie de disques hébergeant l’OS du nœud maitre, le serveur deviendra instable mais ne pourra pas se saborder d’elle-même correctement, plantant le cluster et l’application.

Pire, s’il s’agit de la baie de disques qui héberge le quorum disk, le cluster ne disposera plus d’assez de votes pour fonctionner et le redémarrage devra être forcé à la main.

En cas de corruption du disque OS du nœud actif, les packages basculeront sur l’autre VM.

En cas de panne de l’ESXi, les packages actifs pourront basculer sur le nœud présent sur l’autre serveur.

En cas de perte de la baie de disques, les données seront toujours accessibles par les deux VMs grâce à l’autre membre du miroir.

Même si la baie hébergeant le quorum tombe en panne, on disposera toujours de deux votes (les deux nœuds du cluster).

Limitations et problématiques de la solution

VMware et Contrôleur Physique

Pour partager des disques durs virtuels (RDM ou VMDK), il faut ajouter à la machine virtuelle un « contrôleur de disques SCSI » en « compatibilité physique ». Ceci a pour conséquence de limiter les fonctionnalités disponibles dans VMware :

Pas de live vMotion (bascule de VM à chaud)
Pas de snapshots
Pas de sauvegarde via l’API VMware (sauvegarde des VMs via l’ESXi « clientless » et sauvegarde granulaire)

RHCS et nombre de votes

La salle primaire héberge le quorum disk qui permet de favoriser la salle primaire en cas de « split brain » (voir mon article sur le démarrage forcé sous RHCS). Ce mécanisme de sécurité permet d’empêcher d’avoir 2 salles autonomes en même temps ce qui aura pour conséquence de corrompre les données du SI.

Le cas défavorable de la perte de la salle primaire complète induit un problème important qui ne peut pas être adressé simplement. Dans ce cas de figure, il n’y a plus assez de votes pour que le cluster fonctionne, et l’application s’éteint.

Il est donc nécessaire de redémarrer manuellement les clusters. Dans l’absolu, ce n’est qu’une commande à passer, mais dans mon cas, j’ai un nombre important de clusters à gérer. La personne d’astreinte ne pourra jamais tenir les SLA de 30 minutes d’indisponibilité.

Il me parait impossible d’automatiser proprement cette relance du cluster, car c’est un mécanisme trop sensible et les risques de corruption de données sont trop important.

LVM vs MDADM

Dans la structure pour laquelle je travaille, l’utilisation du mirroring LVM est un choix technique historique héritée de nos clusters MCSG sous HP-UX.

Sous RHEL 5.X, la gestion des miroirs LVM est complexe et peu adaptée :

l’agrandissement des volumes nécessite une suppression du miroir, rendant les données temporairement non redondée et réduisant les performances.
la perte de l’interconnexion - même temporaire - a des effets de bords qui nécessitent également de tout reconstruire et de tout resynchroniser entièrement (membres de miroirs perdus mais pas tous remontés comme tels).

A l’inverse, l’agrandissement d’un disque via MDADM peut se faire à chaud (on agrandi un VMDK, puis l’autre), et la perte temporaire d’un membre ne nécessite pas de le reconstruire complètement.

Une dernière option - idéale techniquement - est l’utilisation de la réplication de « blocs devices » par DRBD (société LinBIT). Elle a été rejetée pour cause d’absence de support de la part de RedHat mais permet de faire exactement ce que l’on souhaite : répliquer des disques au niveau bloc entre deux VMs.

Réplication des VMDK via vSphere Replication

Et voilà la solution que j’aurai aimé étudier. La facilité. Le côté obscur donc.

Prérequis

Pour utiliser la fonctionnalité vSphere Réplication, il faut disposer d’une licence vSphere Essential Plus (ou mieux), d’un vCenter et de deux datastores distincts.

Architecture

Réplication du disque OS de la VM

Avec la licence vSphere Essential Plus, il est possible de réaliser un « pseudo PRA » à l’aide de la fonctionnalité vSphere Replication.

La machine virtuelle n’est pas doublée comme dans l’architecture précédente. Ici VMware réplique son VMDK en fil de l’eau vers un Datastore secondaire.

En cas de panne quelconque sur la salle primaire, on bascule la VM sur le serveur ESXi secondaire et on la redémarre sur le disque répliqué (opération manuelle).

En cas de corruption des filesystems sur le disque OS, on dispose de plusieurs points de restauration dans le temps nous permettant de revenir à un état précédent fonctionnel.

Limitations et problématiques de la solution

Malheureusement je n’ai pas eu l’occasion de le tester, la solution choisie n’étant pas cette solution. Cependant, au vu des besoins énoncés et des ressources à ma disposition, cette solution me parait être celle qui répond à tous les besoins et toutes les problématiques.

Réduire la RAM consommée par VMware vCenter Server Appliance 5.1 (vCSA 5.1)

Tue, 07 May 2013 15:49:57 +0000

Dans le cas où vous auriez la possibilité d’avoir un vCenter pour piloter votre/vos ESXi, vous avez probablement déjà installé vCenter sur un serveur Windows 2003/2008 qui traine (ou une VM), car ça a longtemps été le seul OS capable d’éxécuter l’installeur du vCenter.

C’était vraiment dommage, surtout quand on sait que ce n’est qu’une bête application Java derrière un Tomcat. Heureusement, après avoir vomi leur rage de Windows pendant des années sur les forums, les développeurs de chez VMware ont enfin pris le temps de penser aux Unixiens et réaliser un portage sous Linux. Il s’agit en fait d’une appliance prête à déployer (Novell Suse en l’occurrence pour l’appliance 5.1).

Après un bref passage sur le véloce (*ironie*) site de VMware, et un prompt téléchargement de ladite appliance, il est temps de la déployer sur notre hyperviseur préféré!

Une fois déployée, merci donc de jeter un petit coup d’œil sur la config de l’appliance vCSA (vCenter Server Appliance), ainsi que sur ce site :

KB VMware (lien mort, j’utilise Internet Archive)

Pourquoi je dis ça? Parce que moi lorsque je l’ai déployé et lancé sans me poser de question, j’ai entendu les disques grater. Mon ESXi s’est rapidement mis à swapper la RAM active de mes VMs… Oui, je n’ai qu’un petit lab avec 8Go de RAM, et l’appliance prend par défaut … 8Go de RAM!!!

Voyons voir ce qu’on peut faire pour y remédier…

Déjà, commencez par configurer l’appliance avec un peu moins de RAM, disons 4Go pour commencer (moi j’en suis à 3, et je pense qu’on peut encore faire mieux en désactivant certains composants).

Démarrez la. Une fois la VM lancée, configurer le vCenter en suivant le programme d’installation. Je ne couvrirai pas cette partie, de nombreux blogs le font déjà.

Une fois le serveur configuré et que nous sommes logués dessus en console, on remarque tout de suite qu’on a quand même pas mal d’espace pour swapper au cas où Java prendrait un peu trop ses aises !

free -m
total       used       free     shared    buffers     cached
Mem:          3017       2939         77          0          3        139
-/+ buffers/cache:       2797        219
Swap:        15366       1206      14160

Le seul travail qu’à fait VMware ici, c’est faire rentrer un multitude d’applications serveurs Java pour héberger les différents services qui composent la suite vSphere 5.1. Et quand on connait la gloutonnerie de Java…

Pour trouver les billes pour réduire la quantité de RAM consommée par cette appliance, je me suis basé sur une partie de la blogosphère qui traite malheureusement majoritairement de la version précédente de l’appliance (v5), et notamment cet article sur squishnet.org (lien mort, j’utilise Internet Archive).

Tuning de la base de données

Dans les préconisations des blogueurs qu’on peut y voir parler d’une base DB2. Or à priori, depuis la 5.1, VMware utilisent maintenant une base PostGreSQL

df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda3       10179904 4268324   5394460  45% /
udev             1544716     104   1544612   1% /dev
tmpfs            1544716       0   1544716   0% /dev/shm
/dev/sda1         130888   20994    103136  17% /boot
/dev/sdb1       20641788  176200  19416948   1% /storage/core
/dev/sdb2       20641788  409008  19184140   3% /storage/log
/dev/sdb3       20635732  319156  19268336   2% /storage/db

Je commence donc par tuner la mémoire kernel pour PostgreSQL (plus d’infos sur http://www.postgresql.org/docs/9.2/static/kernel-resources.html)

vi /etc/sysctl.conf
kernel.shmall = 524288
kernel.shmmax = 2147483648
sysctl -w kernel.shmmax=2147483648
sysctl -w kernel.shmall=524288

Tuning des JVM

Une fois que c’est fait, on peut maintenant s’attaquer au plus gros problème de cette appliance, les réservations ridicules de mémoires pour l’ensemble des composants Java

vi /usr/lib/vmware-vsphere-client/server/bin/dmk.sh
JAVA_OPTS="$JAVA_OPTS -Xmx512m -Xms512m -XX:PermSize-128m"

En plus des tweaks qui sont proposés, j’ai regardé les processus Java en cours de fonctionnement, et ai remarqué que le serveur VMware SSO consomme 2Go à lui seul.

ps -ef | grep ssod
[...] -Xms2048m -Xmx2048m [...]
2Go! -_- Même pas en rêve... Personnellement je ne l'utilise même pas dans mon lab, il faudrait que le trouve comme le couper carrément mais en attendant j'ai mis
vi /usr/lib/vmware-sso/bin/setenv.sh
[...] -Xms256m -Xmx512m [...]

Une fois que c’est fait, j’ai aussi remarqué qu’on pouvait modifier le fichier de conf de l’Inventory Service (dans le cadre d’un petit parc d’ESXi et de VMs), ainsi que le composant SPS (VMware vSphere Profile-Driven Storage Service) et les options par défaut des composants vpx.

vi /usr/lib/vmware-vpx/inventoryservice/wrapper/conf/wrapper.conf
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024
vi /usr/lib/vmware-vpx/sps/wrapper/conf/wrapper.conf
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512
vi /etc/vmware-vpx/tomcat-java-opts.cfg
-Xmx512m -XX:MaxPermSize=256m -Dvim.logdir=/var/log/vmware/vpx

Aftermath (littéralement “après les maths”)

Après un redémarrage complet (un reboot est le plus crade mais le plus simple), les JVM devraient se tenir un peu plus à carreau. Je ne dis pas que tout fonctionne, car je n’ai pas tout testé (notamment le VMwareSSO pour lequel j’ai de sérieux doutes vu la quantité de RAM demandé à la base et le peu que je lui ai mis), mais le client VMware lourd ainsi que la version web répondent très bien.

Voici donc la liste des process java/vmware qui tournent sur la machine après tuning/reboot

/usr/lib/vmware-vpx/sps/wrapper/bin/./wrapper /usr/lib/vmware-vpx/sps/wrapper/bin/../conf/wrapper.conf (wrapper de vmware-sps)
/usr/java/jre-vmware/bin/java -Xms256m -Xmx512m (vmware-sps)
/usr/lib/vmware-vpx/inventoryservice/wrapper/bin/./wrapper /usr/lib/vmware-vpx/inventoryservice/wrapper/bin/../conf/wrapper.conf (wrapper de vpx/inventoryservice)
/usr/java/jre-vmware/bin/java -XX:PermSize=128m -XX:MaxPermSize=256m -Xms256m -Xmx1024m (vpx/inventoryservice)
/usr/java/jre-vmware/bin/java -Xmx512m -Xms512m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:MaxPermSize=256m (vmware-vsphere-client/server dans /usr/lib/vmware-vsphere-client/server/bin/dmk.sh)
/usr/java/jre-vmware/bin/java -XX:MaxPermSize=256M -Xms512m -Xmx512m (vmware-sso/webapps  dans /usr/lib/vmware-sso/bin/setenv.sh)

Processus auquels je n’ai pas touché car je ne suis pas vraiment certain de l’eur utilité et que ça ne mange pas beaucoup de RAM

/usr/java/jre-vmware/bin/java -Xms128m -Xmx512m (vmware-logbrowser ou com.vmware.vide.ws.server ?)
/usr/java/jre-vmware/bin/java -XX:PermSize=64M -Xmx512m -XX:MaxPermSize=256m (vfabric-tc-server-standard et son watchdog perso)

En tout cas dans mon lab, c’est indéniablement mieux que lorsque j’avais la RAM de mon host en train de swapper ;-)

BONUS TRACK : VMware Tools

Pour finir de tuner cette appliance, j’en profite pour référencer la solution permettant de résoudre le soucis “vmware tools non reconnus” de la machine virtuelle par l’hôte, à l’aide des précieuses instructions de virtuallyghetto http://www.virtuallyghetto.com/2011/07/tips-and-tricks-for-vma-5.html

/etc/init.d/vmware-tools-services stop
cp VMwareTools-9.0.0-782409.tar.gz /tmp/
cd /tmp
tar xzf VMwareTools-9.0.0-782409.tar.gz
cd vmware-tools-distrib
./vmware-install.pl

Accepter toutes les valeurs par défaut, et ignorer l’erreur lorsque l’installeur indique que gcc n’est pas présent car il n’est pas nécessaire. Après ça, le client VMware Tools sera bien affiché comme à jour dans l’interface vSphere.