Documentation

VMware vSphere

Provibr se connecte à un vCenter Server et gère les machines virtuelles de son inventaire : commander, cloner, démarrer, arrêter, suspendre, supprimer et relever la consommation, via le même agent, les mêmes offres et la même piste d’audit que toute autre intégration.

À quoi cela se connecte

L’intégration dialogue avec vCenter Server par son API Web Services. Tout ce que fait le panneau (placement, clonage, configuration de l’invité) passe par vCenter, si bien qu’un cluster avec DRS continue de décider lui-même sur quel hôte une machine atterrit.

Un hôte ESXi autonome n’est pas pris en charge. Il répond sur la même API et la connexion réussit même, mais il n’a ni clusters, ni DRS, ni pool de ressources vers lequel cloner. L’agent vérifie à quoi il parle et refuse un hôte autonome plutôt que d’échouer à votre première commande.

Ce qui diffère de Proxmox

Le modèle est le même : un agent, une intégration, des offres et des modèles. Quatre choses se comportent autrement, et ce sont celles que vous remarquerez.

Une machine est désignée par son UUID d’instance et non par un numéro attribué par Provibr. Tout ce que vous choisissez dans les réglages (centre de données, pool de ressources, réseau) est une référence d’objet vSphere et non un nom, car les noms n’y sont uniques qu’au sein de leur dossier. Et le « nœud » affiché dans le panneau est le centre de données, pas l’hôte ESXi : celui-ci change à chaque vMotion, et une machine qui semblerait déménager toutes les heures serait impossible à suivre.

Ce que vous saisissez

Quatre champs. Créez un utilisateur dédié plutôt que de réutiliser un administrateur : vCenter n’a pas de jeton d’API révocable, donc le rôle attribué au compte est la seule limite.

L’adresse https de vCenter, telle que vous l’ouvrez dans le navigateur.
Le nom d’utilisateur avec son domaine, par exemple provibr@vsphere.local.
Le mot de passe. Il part une seule fois vers votre agent et n’est jamais conservé par Provibr.
L’empreinte SHA-256 du certificat présenté par vCenter.

Attribuez au compte un rôle sur le centre de données qu’il doit gérer. La connexion réussit avec n’importe quel compte connu de vCenter : un compte sans rôle se connecte donc sans erreur puis ne voit absolument rien : aucun message, juste un inventaire vide. C’est pourquoi le test de connexion indique combien de centres de données il voit : zéro signifie que les identifiants sont bons et que le rôle manque.

L’empreinte TLS

Relevez-la depuis n’importe quelle machine capable de joindre vCenter :

shell

openssl s_client -connect <host>:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256

Les commandes et les sorties de terminal sont en anglais partout, dans le panneau comme dans ces pages. Un seul texte, une seule vérité : ce que vous lisez ici est littéralement ce que votre hôte affichera.

Ce champ est obligatoire. vCenter présente toujours un certificat de sa propre autorité interne : il n’existe donc ni chaîne publiquement reconnue sur laquelle se rabattre, ni accès en clair. Avec une empreinte, l’agent fait confiance à ce certificat précis au lieu de désactiver la vérification.

Prenez l’empreinte du certificat de la machine, pas celle de l’autorité interne. Le vSphere Client affiche les deux et elles se ressemblent. Épingler celle de l’autorité donne une intégration qui fonctionne tout de suite et s’arrête des mois plus tard, à la rotation suivante du certificat.

Réglages

Où sont placées les nouvelles machines. Vous choisissez parmi ce que vCenter signale ; rien n’est à saisir.

Le centre de données où sont créées les nouvelles machines.
Le pool de ressources. Sur un cluster DRS, c’est le pool racine et vSphere choisit l’hôte.
Le groupe de ports auquel se rattache la carte réseau.
Éventuellement un hôte fixe : laissez ce champ vide partout où DRS est actif.

Il n’y a pas de réglage de banque de données. Un clone hérite du stockage de son modèle, lequel se trouve déjà à un endroit autorisé ; un choix propre vous laisserait désigner une banque que l’hôte cible ne voit peut-être même pas.

Modèles

Dans vSphere, un modèle est une machine virtuelle ordinaire marquée comme telle, dans le même inventaire. Reliez-le à un système d’exploitation de votre catalogue et les commandes de ce système en seront clonées.

La liste affiche le centre de données à côté du nom, car deux modèles peuvent porter le même nom dans des dossiers différents. Donnez au modèle VMware Tools et cloud-init ; Provibr transmet la configuration de l’invité par le canal guestinfo, qui fonctionne sur n’importe quelle image cloud sans exigence supplémentaire.

Ce que vous pouvez faire d’une machine

La créer depuis un modèle, la démarrer, l’arrêter, la réinitialiser, l’éteindre et la redémarrer proprement via VMware Tools, la suspendre et la reprendre, lire son état et la supprimer.

Pas encore : ajouter ou retirer des disques et des cartes réseau, et réinstaller. Réinstaller dans vSphere revient à cloner de nouveau, et aucune commande ne reconstruit la même machine sur place. Un pare-feu par machine n’existe pas dans vSphere : c’est NSX, un produit distinct.

Réseau

Une nouvelle machine reçoit une carte sur le groupe de ports défini dans les réglages, et son adresse depuis votre IPAM si l’offre est rattachée à un pool.

Les groupes de ports distribués sont pris en charge et constituent le cas courant. Ils se rattachent autrement que les réseaux classiques (par l’UUID de leur commutateur et leur propre clé), et l’agent le déduit de l’objet lui-même : vous n’avez rien à régler.

Reprendre l’existant

Les machines qui existent dans vCenter en dehors de Provibr peuvent être importées depuis la page de l’intégration : cochez celles que vous voulez et elles apparaissent comme serveurs, avec leur centre de données, leur état et leurs caractéristiques.

PrécédentProxmox VE SuivantoVirt