vcsim : simuler un vCenter/ESXi pour tester sans VMware

Tester un outil qui parle à vSphere suppose d'ordinaire un vCenter ou un ESXi sous licence, avec du matériel dédié. vcsim lève ce prérequis : c'est le simulateur de l'API vSphere fourni par govmomi (le SDK Go de VMware, sous Apache 2.0). Il expose un faux vCenter complet, avec datacenters, hôtes et VMs simulés, contre lequel on lance ses scripts et ses outils sans rien payer ni provisionner. Ce guide montre comment le déployer, l'exploiter, et surtout jusqu'où il va : à travers un cas concret de test de Migration Manager, on verra ce que vcsim permet de valider et où il s'arrête. Public visé : administrateurs et intégrateurs qui automatisent contre VMware.

Ce que vous allez apprendre

Ce qu'est vcsim et ce qu'il simule vraiment.
Installer vcsim et le client govc.
Lancer un faux vCenter et explorer son inventaire.
L'utiliser comme source de test pour un outil vSphere réel.
Les limites concrètes du simulateur, sans faux-semblant.

Prérequis

Une machine Linux avec un accès internet pour les binaires.
Pour le cas d'usage avancé, Go (pour une recompilation) et un outil consommateur de l'API vSphere.

Ce que vcsim simule, et ce qu'il ne simule pas

Il faut poser le cadre d'entrée, car c'est ce qui détermine à quoi vcsim sert. Le simulateur reproduit l'API de management de vSphere : l'arborescence d'inventaire (datacenters, clusters, hôtes, VMs), les appels SOAP/REST, l'authentification, et les métadonnées des objets. Il ne stocke aucune donnée réelle : les disques des VMs simulées sont des coquilles sans blocs, et certaines propriétés matérielles récentes ne sont pas modélisées.

Autrement dit, vcsim est fait pour tester la logique d'un outil (connexion, inventaire, appels API), pas pour manipuler des données ou reproduire fidèlement une VM de production récente. On y revient concrètement à la fin.

Installer vcsim et govc

vcsim et le client en ligne de commande govc sont distribués comme binaires dans les releases de govmomi. On les installe directement :

V=v0.54.2
wget -q https://github.com/vmware/govmomi/releases/download/$V/vcsim_Linux_x86_64.tar.gz -O - | tar xz vcsim
wget -q https://github.com/vmware/govmomi/releases/download/$V/govc_Linux_x86_64.tar.gz -O - | tar xz govc
install -m 0755 vcsim govc /usr/local/bin/

Lancer un faux vCenter

On démarre le simulateur en le faisant écouter sur toutes les interfaces, pour qu'un outil distant puisse l'atteindre :

vcsim -l 0.0.0.0:8989

Le client govc s'y connecte via deux variables d'environnement. En mode simulateur, n'importe quel couple identifiant/mot de passe est accepté :

export GOVC_URL='https://user:pass@127.0.0.1:8989/sdk'
export GOVC_INSECURE=1
govc about

FullName:     VMware vCenter Server 6.5.0 build-5973321 (govmomi simulator)
Version:      6.5.0
API version:  6.5

Par défaut, vcsim peuple un inventaire complet : un datacenter, plusieurs hôtes, et quelques VMs, qu'on liste immédiatement :

govc find / -type m    # les machines virtuelles
govc find / -type h    # les hôtes ESXi

/DC0/vm/DC0_H0_VM0
/DC0/vm/DC0_H0_VM1
/DC0/vm/DC0_C0_RP0_VM0
/DC0/vm/DC0_C0_RP0_VM1

Dimensionner l'inventaire

Pour reproduire une topologie proche de la cible, vcsim accepte des paramètres de taille. On fixe le nombre de datacenters, d'hôtes par cluster, de VMs par hôte, et la version d'API annoncée :

vcsim -l 0.0.0.0:8989 -dc 2 -host 4 -vm 3 -api-version 8.0.0

L'option -api-version mérite une attention particulière, comme on va le voir : elle change la version de l'API annoncée, mais pas la version du produit, ce qui a des conséquences dès qu'un outil vérifie cette dernière.

Cas concret : tester Migration Manager

Le meilleur moyen de cerner ce que vaut vcsim est de lui brancher un vrai consommateur. Prenons Migration Manager (l'outil de la stack FuturFusion qui migre des VMs VMware vers Incus). On lui déclare vcsim comme source :

migration-manager source add vcsim https://<ip-vcsim>:8989 \
  --trusted-cert-fingerprint <sha256>
# identifiants demandés : user / pass (acceptés par le simulateur)

| Name  | Type   | Connectivity Status | Username |
| vcsim | vmware | OK                  | user     |

Excellente nouvelle : la connectivité est validée. Migration Manager dialogue avec vcsim, découvre les quatre VMs et tente de les importer. C'est là que les limites apparaissent, l'une après l'autre.

Première limite : la version du produit

L'import échoue d'abord sur la version :

Failed to record vm properties ... error="Property definition version "8.0"
does not support version "6.5.0" for "vmware""

Migration Manager n'accepte qu'une source VMware 8.0, or vcsim annonce un produit 6.5.0. Et le piège est que -api-version 8.0.0 ne suffit pas : ce drapeau ne change que About.ApiVersion, tandis que l'outil lit About.Version, codée en dur à 6.5.0 dans le simulateur (simulator/vpx/service_content.go). Aucun drapeau ne l'expose.

La seule voie est de recompiler vcsim avec la bonne version. C'est un patch d'une ligne, et vcsim étant un module Go séparé, il faut un replace pour utiliser le code local modifié :

git clone --depth 1 https://github.com/vmware/govmomi.git && cd govmomi
sed -i 's/6\.5\.0/8.0.0/g' simulator/vpx/service_content.go simulator/esx/service_content.go
cd vcsim
echo 'replace github.com/vmware/govmomi => ../' >> go.mod
go mod tidy && go build -o /usr/local/bin/vcsim .

Après relance, govc about confirme un produit 8.0.0, et Migration Manager franchit la vérification de version.

Seconde limite : les propriétés matérielles

L'import bute alors sur les attributs matériels d'une VM 8.0 que les VMs simulées ne possèdent pas :

error="Failed to find value for key set "summary.config.tpmPresent": Object does not contain key "tpmPresent""
error="... "backing.sharing": Object does not contain key "sharing""
error="... "config.bootOptions.efiSecureBootEnabled": ..."

Migration Manager lit le profil complet d'une VM 8.0 (présence de TPM, Secure Boot, mode de partage de disque). Or vcsim crée des VMs basiques : ces propriétés ne sont ni modélisées dans le simulateur, ni ajoutables via govc. Les peupler demanderait de patcher le simulateur en profondeur, avec la certitude de découvrir la propriété manquante suivante.

Troisième limite : le contenu des disques

Même si l'inventaire remontait entièrement, la migration réelle resterait hors de portée. Le transfert de données passe par la lecture des disques VMDK (via VDDK/nbdkit), et les disques des VMs simulées sont vides. Il n'y a rien à copier.

Ce que vcsim permet vraiment

Objectif	Avec vcsim
Tester la connexion et l'authentification vSphere	Oui
Valider les appels d'inventaire d'un outil	Oui
Vérifier la compatibilité de version	Oui, après recompilation
Importer un inventaire de VMs 8.0 complet	Non (attributs matériels non modélisés)
Migrer/copier des données de disque	Non (disques vides)

Le simulateur est donc précieux pour le développement et la CI d'outils vSphere, tant qu'on teste la logique de contrôle. Pour un test de bout en bout d'un outil de migration, il faut un ESXi/vCenter réel avec de vraies VMs.

À retenir

vcsim simule l'API vSphere et un inventaire, sous Apache 2.0, sans licence ni matériel.
Le client govc explore l'inventaire ; en mode simulateur, tout identifiant est accepté.
-api-version change l'API, pas la version produit (codée en dur) : recompilation nécessaire pour la forcer.
Les VMs simulées sont basiques : pas d'attributs matériels 8.0 (TPM, Secure Boot, sharing).
Les disques sont vides : aucune migration de données possible.
vcsim teste la logique de contrôle d'un outil, pas le matériel virtuel ni les données.

Prochaines étapes

Operations Center Gérer une flotte Incus OS, cible d'une migration depuis VMware.

Proxmox VE Une alternative de virtualisation type 1.

Incus OS sans interface La brique hyperviseur de la stack souveraine.