[PowerCLI] Changer mot de passe root avec power CLI

Voici un petit script PowerCLI qui va vous aider à modifier le mot de passe, ici du compte "root", mais vous pouvez l'utiliser pour n'importe quel autre compte, en modifiant le nom du compte.

Votre ESX peut même être déjà connecté à un vCenter

Script disponible ici

Cas d'usage :

1) Votre mot de passe est compromis, et vous avez besoin de le modifier rapidement
2) Vous avez installé l'ESX avec un mot de passe standard et peu complexe, il est maintenant temps de le rendre compliant avec la politique de sécurité des mots de passe de l'entreprise !

Read More

Gestion des templates de VMs et synchronisation des Content Librairies locales et distantes

 Je vais ici vous proposer une solution 100% VMware vCenter pour gérer le stockage, le déploiement, la mise à disposition et la mise à jour d'un template de VM (quelque soit son OS) dans un Content Librarie vers un ensemble de sites distants.

Imaginons donc un environnement avec un vCenter central, de nombreux sites distants hébergeant chacun des ESXi avec chacun leur propre stockage partagé, mais des bandes passantes hétérogènes d'un site à l'autre.

=> L'idée est donc ici de trouver une solution permettant de créer en central une image de référence de VM (template) et de la pousser vers chacun des sites. Ainsi au moment du déploiement d'une VM à partir de ce template, l'image est déjà stockée en local sur le site sur lequel on en a besoin.

L'avantage par rapport à un déploiement classique sur base de template, c'est que l'image de la VM n'est plus dépendante de la qualité de la bande passante inter-site : elle a déjà été streamée en avance de phase.

Création de la Content Librarie centrale

Sélectionner "CREATE", et remplissez les champs ainsi :

Puis:

Dans notre exemple, considérons qu'il n'y a pas besoin d'authentification pour accéder au Content Librarie:

Sélectionner le datastore local où sera stocké le template :

Finish.
Une fois le template de la VM créé, clonez le vers le Content Librarie :

Puis, sélectionner "New Template" et le Content Librarie central.

Aller vérifier dans Content Library que le template y apparait bien :

Maintenant, nous allons créer un Content librairie distant "abonné" au Content Librairie central.
Le content Librairie distant se synchroniser automatiquement au Content Librairie Central.

Création du Content Librairie distant

Editer le Content Librairie central, et copier l'URL

Créer un nouveau Content Librairie, et y spécifier l'URL précédemment copiée :

Sélectionner le datastore localisé sur le site distant:

A sa création, on constate que le Content Librairie distant est vide :

Mais au bout de quelques secondes, il se synchronise avec le Content Librairie Central pour atteindre la même taille.

Mise à jour du template

Nous allons enfin ,ici, mettre à jour le template du Content Librairie central, et observer la mise à jour automatique du template sur le site distant.

(Pour l'exemple, j'ajoute des CPU / RAM et controleurs SCSI + cartes réseau à mon template)

RAPPEL : Pour cela, il faut donc:

1. Retransformer le template en VM
2. Editer la VM et y ajouter les éléments nécessaires (ou modifications logicielles à l'intérieur de l'OS)
3. Retransformer la VM en template

Sélectionner le template:

 

Sélectionner "Update existing template" et le template à mettre à jour:

On constate que le template s'est mis à jour dans le Content Librairie Central :

et au bout de quelques secondes, la mise à jour a été poussé automatiquement vers le (ou les) Content Librairies distants (ce ne sont que les blocs modifiés qui sont poussés vers le site distant):

=> Il est également possible de forcer la synchronisation manuellement.

Si 15 sites sont abonnés au Content Librairie central, la mise à jour du ou des templates est AUTOMATIQUEMENT poussée vers chacun de ce 15 sites: C'est un gain de temps énorme !

Le template mis à jour est donc maintenant disponible sur le site distant, prêt à être utilisé pour déployer des VMs !

Read More

vSphere assessment calculator

 Je vous propose ici un petit outil visant à vous aider à définir "grosse maille" une infrastructure cible comportant aussi bien des serveurs physiques que des VMs déjà existantes.

Vous trouverez sur le premier onglet le mode d'emploi de l'outil.

Je fais évoluer régulièrement ce petit outil.

Libre à vous de le modifier à votre guise.

Bonne utilisation !

 C'est ICI que ça se passe !

Read More

Remplacement certificats autosignés du vCenter

Je vous propose ici un petit mode opératoire vous aidant à remplacer les certificats autosignés par défaut lors de l'installation du VMware vCenter par ceux issus de votre autorité de certification.

=> Faire un snapshot à froid du vCenter ( se connecter sur l'ESXi qui héberge la VM vCenter pour cela)

1- Demandez le fichier PFX au service compétent, en fournissant les éléments suivants :

Le FQDN du vCenter
Email (celle d'un compte de service)
IP du vCenter

2- Installer OpenSSL

Disponible ici : https://slproweb.com/products/Win32OpenSSL.html

3- Extraire la clé

Dans un CMD, exécuter la commande suivante :

C:\Program Files\OpenSSL-Win64\bin>openssl pkcs12 -in blablabla.pfx -out c:\temp\key.txt -nocerts -nodes

Renseigner le mot de passe fourni avec le PFX

4- Extraire les chaines de cert

Dans un CMD, exécuter la commande suivante :

C:\Program Files\OpenSSL-Win64\bin>openssl pkcs12 -in blablabla .pfx -out c:\temp\cert.txt -nokeys

• Renseigner le mot de passe fourni avec le PFX

5- Modification des fichiers

• Fichier key.txt

Aller dans c:\temp (ou là ou vous avez sauvegardé le fichier de l'étape 3)

Editer le fichier key.txt et supprimer ce qui est en jaune 

Enregistrer

• Fichier cert.txt

Faire une copie du fichier cert.txt et le nommer ca.txt

Editer le fichier cert.txt
Supprimer tout ce qui est en jaune


Supprimer également tout ce qui est sous le premier “-----END CERTIFICATE-----”

Enregistrez

• Fichier ca.txt

Editer le fichier ca.txt

Supprimer tout le début jusqu’au début du second “-----BEGIN CERTIFICATE-----”

Supprimer également la partie jaune entre les blocs :

Enregistrez

6- Copie des fichiers créés au point 5 sur le vCenter

En utilisant WinSCP, copier sur /tmp les fichiers :

• ca.txt

• cert.txt 

• key.txt

7- Mise à jour du certificat

• Se connecter avec putty sur le vcenter

• Executer :  /usr/lib/vmware-vmca/bin/certificate-manager

• Selectionner 1

 => Appuyer sur Entrée

=> mot de passe du compte administrator@vsphere.local

=> 2

 => y

En vous reconnectant sur l'interface web de votre vCenter, vous pouvez constater que votre certificat s'est bien mis à jour

Si tout est OK, n'oubliez pas de supprimer le snapshot pris au début ;-)

Read More

[PowerCLI] Cross vCenter vMotion

Je vous propose ici une évolution d'un script qui permet de lancer un vMotion sur une VM d'un vCenter à un autre.

Les pré requis sont :
- Que le stockage soit partagé entre les 2 environnements.
- Avoir un compte unique avec des droits sur les 2 vCenters
- Remplir le fichier "List_VM.csv" ainsi : "Name;Cluster;Datastore;DstPortGroup1;DstPortGroup2" 

Le script sais donc gérer les VMs qui ont plusieurs cartes réseaux, et assurer la "reconnexion" de chacune des carte au bon port group à destination.

En vous connectant sur les 2 vcenters, vous pourrez observer les VMs disparaître du premier, et s'inventorier sur le second.

Script disponible ici : https://github.com/GuillaumeDamien/crossvcentervmotion

Have fun !

Read More

[PowerCLI] Rapport Veeam

Bonjour à tous,

Aujourd’hui je souhaite partager avec vous une manière d’envoyer automatiquement par mail des rapports très synthétiques de vos sauvegardes Veeam. Ce mail contiendra uniquement la liste des VMs non sauvegardées depuis X jours.

Bien sûr Veeam propose déjà d’envoyer des mails avec le résultat de chaque job. Mais vous recevrez un mail par job. Donc si vous avez une grosse infra, avec plusieurs dizaines de jobs Veeam, vous risquez de littéralement vous faire spammer et ne plus prêter attention à ces mails. De plus, rien ne garantit que certaines VMs ne soient contenues dans aucun job, et donc ne soient jamais sauvegardées. Pour ce 2^e point, il existe "Veeam One", mais encore faut-il acheter le produit.

La méthode que je propose s’appuie sur les attributs personnalisés des VMs. Comme vous le savez peut-être, Veeam est capable de mettre à jour ces attributs en cas de sauvegarde réussie d’une VM (et uniquement en cas de sauvegarde réussie). Donc si une VM n'a pas été sauvegardée depuis plus d'une semaine, son attribut personnalisé datera de plus d'une semaine. Pour configurer cela, il suffit de cocher la case « Set successful backup details to this VM attribute », et d’indiquer le nom de l’attribut personnalisé comme ceci :

Lorsque vos VMs seront correctement sauvegardées, leur attribut sera mis à jour avec la date de la dernière sauvegarde réussie :

Dans le champ « Valeur » vous pourrez trouver le nom du Job ainsi que la date et l’heure de la dernière bonne sauvegarde. L’idée est donc de créer un script afin de  :

--> Lister toutes les VMs du vCenter
--> Récupérer l’attribut personnalisé de chacune d’entre elles
--> Parser le champ « valeur » afin de récupérer la date de dernière bonne sauvegarde
--> Créer un tableau avec toutes les VMs dont la dernière sauvegarde date de plus de X jours (3 jours dans mon cas), ou dont le champ est vide (ce qui signifie qu’elles n’ont jamais été sauvegardées).
--> Envoyer ce tableau par mail

Dans mon cas, j’exécute ce script tous les matins du lundi au vendredi. Vu que la sauvegarde Full se lance le vendredi soir et tourne tout le weekend, il peut se passer 3 jours entre le lancement du script du lundi matin et la dernière sauvegarde du vendredi soir. C’est pour cette raison que, dans mon cas, j’ai configuré le script pour qu’il ne liste que les VMs n’ayant pas été sauvegardées depuis plus de 3 jours. A vous d'adapter selon votre besoin.

Vous pourrez trouver mon script ici:  https://github.com/charivel/VeeamReport

Enjoy  😊

Read More

[Proxy Veeam] Design Réseau

Bonjour à tous,

Je voulais partager avec vous un petit retour d’expérience concernant l’architecture réseau des proxies Veeam. Chez mon client, nous avons plusieurs clusters VMware 6.5. Chaque cluster possède des VLANs différents pour ses VMs, mais aussi pour le réseau de management des ESXi. Donc le réseau de management d’un ESXi de DEV n’est pas le même que celui d’un ESXi de PROD.

Afin de répartir la charge, nous avons créé un proxy virtuel par cluster. Chaque proxy virtuel est positionné au plus proche des ESXi, c’est-à-dire dans le même VLAN de management des ESXi du cluster qui l’héberge. Afin de faire simple, nous avons créé un job de sauvegarde par cluster. Voici un schéma simplifié afin d’illustrer la situation :

Malheureusement, nous avions beau avoir plusieurs VMs proxy déployées, nous avions souvent des jobs en attente durant plusieurs heures fiasant dépasser la fenêtre de sauvegarde. Le message était le suivant :

En regardant de plus près, plusieurs de nos VMs proxy n’étaient pas utilisées. Ceci est dû au fait que Veeam cherche à utiliser le proxy optimal en priorité. Et pour lui, le proxy optimal c’est celui qui est dans le même réseau que les ESXi hébergeant les VMs à sauvegarder. Pour résumer, avec cette architecture, si je lance la sauvegarde de plusieurs clusters en même temps, je vais utiliser plusieurs proxies donc tout va bien. Mais si je ne sauvegarde qu’un seul cluster, ou si un cluster est plus gros et donc se termine après les autres, je n’utiliserai qu’un seul proxy, donc les perfs vont s’écrouler.

Afin de vérifier cette idée, pour chaque cluster, j’ai autorisé l’utilisation de tous les proxies sauf celui hébergé sur le cluster en question. Et là, pour chaque Backup Job, j’obtiens le message d’avertissement suivant :

Ce qui est normal puisqu'on vient d'exclure le seul proxy se trouvant dans le même sous-réseau. Attention, si vous avez un parefeu entre vos VLANs, cela peut effectivement impacter les performances et le temps de vos sauvegardes. Mais comme par magie, tous les autres proxies autorisés pour ce job sont utilisés, et dans mon cas les performances sont nettement améliorées ! Malheureusement, chaque Job n’est autorisé qu’à utiliser N-1 proxies.

Donc si on veut :

-         Garder la configuration Veeam la plus simple possible

-         Eviter d’aller "bidouiller" chaque backup job pour exclure un proxy (et on risque d'oublier de le faire sur les futurs Jobs)

-         Et surtout que chaque job puisse utiliser la totalité des proxies et non N-1

Je préconiserais :

-         Si le management des ESXi sont tous dans le même VLAN, alors déployer les VMs proxy dans ce VLAN

-         Sinon, créer un VLAN spécifique pour vos VMs proxy qui n’a rien à voir avec les réseaux de management de vos ESXi.

Maintenant que ce problème est réglé, je suis tombé sur une 2e limitation qui se cachait derrière :

Par défaut, Veeam limite la sauvegarde de 4 VMs en simultannées par datastore, afin que les snapshots ne saturent pas le datastore en espace libre. Si vous avez suffisamment de place sur vos datastores, vous pouvez augmenter cette limite à 6 voir 8 snapshots simultannées. Ce sujet est déjà traité par Bilel et Igor, je vous laisse donc le soin de consulter leur article :

http://vinception.fr/veeam-resource-not-ready-active-snapshots-limit-reached-for-datastore/

J’espère que ce retour d’expérience sur le Design réseau des proxies Veeam pourra vous aider 😊

Read More