PowerCLI pour l'automatisation de l'infrastructure virtualisee

PowerCLI est le module PowerShell de référence pour administrer les environnements VMware vSphere par script. Son intérêt dépasse largement l’exécution ponctuelle de quelques commandes : il permet de transformer des opérations répétitives réalisées dans le client vSphere en processus versionnés, contrôlables et reproductibles. Pour un administrateur système, cela couvre aussi bien l’inventaire quotidien que le déploiement en série de machines virtuelles, les audits de configuration, la correction de dérives ou l’intégration de tâches d’infrastructure dans une chaîne CI/CD.

L’objectif n’est pas de remplacer toute utilisation de l’interface graphique. Le client vSphere reste très utile pour diagnostiquer un incident, visualiser une topologie ou traiter une exception. En revanche, dès qu’une action doit être répétée, documentée ou appliquée à plusieurs dizaines d’objets, le clic-bouton devient une source de variabilité. Un script PowerCLI limite ce risque : il décrit précisément le résultat attendu, peut être relu par un pair, placé dans Git, exécuté avec un compte de service et journalisé.

PowerCLI repose sur PowerShell et sur les API vSphere. Les cmdlets manipulant les objets VMware suivent la logique habituelle de PowerShell : récupération d’objets avec Get-*, création avec New-*, modification avec Set-*, suppression avec Remove-*. Cette cohérence facilite la composition de pipelines, l’export CSV, les filtres et la gestion d’erreurs. Ce guide présente une base opérationnelle pour quitter progressivement les gestes manuels et construire une automatisation fiable, sans transformer chaque script en projet logiciel démesuré.

Préparer le poste d’administration et installer PowerCLI

PowerCLI est distribué sous forme de modules PowerShell. Il fonctionne sous Windows, mais également sous Linux et macOS avec PowerShell 7. Dans un contexte d’entreprise, privilégiez une installation contrôlée depuis un dépôt interne PowerShell ou depuis la PowerShell Gallery après validation des dépendances. Le portail développeur PowerCLI de Broadcom centralise les téléchargements, les notes de version et la référence complète des cmdlets.

Sur un poste d’administration Windows récent, commencez par vérifier votre version de PowerShell :

$PSVersionTable

Installez ensuite le module VMware PowerCLI pour l’utilisateur courant. Cette méthode évite de nécessiter une élévation de privilèges locale :

# Installation pour le compte utilisateur actuel
Install-Module -Name VMware.PowerCLI -Scope CurrentUser

# Vérification des modules installés
Get-Module -ListAvailable VMware.PowerCLI

Dans un environnement filtrant les dépôts externes, enregistrez ou utilisez un dépôt interne. Évitez de contourner les contrôles de sécurité simplement avec une stratégie d’exécution permissive. Si l’organisation impose une signature de scripts, signez les scripts déposés dans le dépôt Git ou le partage d’administration.

Gérer les certificats vCenter correctement

Un vCenter avec un certificat signé par une autorité de certification interne reconnue est préférable. Dans la pratique, certains environnements utilisent encore un certificat autosigné ou une chaîne non approuvée par le poste exécutant PowerCLI.

Pour un laboratoire, il est possible d’ignorer les certificats invalides :

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

Cette option simplifie les tests, mais elle réduit la protection contre une interception de connexion. En production, corrigez plutôt la chaîne de confiance en déployant le certificat de l’autorité interne dans le magasin de certificats du système ou dans l’image de l’agent CI/CD. Pour aller plus loin, consultez un script PowerCLI d’audit des disques virtuels.

Quelques paramètres PowerCLI méritent aussi d’être harmonisés dans les scripts ou dans le profil PowerShell :

# Désactive les messages CEIP interactifs
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false -Confirm:$false

# Évite les confirmations sur certaines commandes selon la politique locale
Set-PowerCLIConfiguration -Scope User -DefaultVIServerMode Multiple -Confirm:$false

Le mode Multiple est utile si les scripts doivent interroger plusieurs vCenter. Si vous administrez un seul vCenter à la fois, le mode Single réduit les ambiguïtés liées à une connexion résiduelle.

Se connecter à vCenter sans exposer les secrets

La connexion à vCenter passe par Connect-VIServer. Le compte utilisé doit respecter le principe du moindre privilège. Ne donnez pas le rôle administrateur global à un compte de script si son unique fonction consiste à produire un inventaire.

Connexion interactive simple :

# Demande le mot de passe de manière interactive
Connect-VIServer -Server vcsa.lab.local -User 'LAB\svc-powercli'

Pour une automatisation planifiée ou un pipeline, le mot de passe ne doit jamais être écrit directement dans le script ni dans un fichier CSV. PowerShell permet de stocker des identifiants chiffrés pour le profil et le compte Windows qui les ont créés.

# Exécuter une seule fois, sous le compte qui lancera les scripts
$Credential = Get-Credential
$Credential | Export-Clixml -Path "$HOME\.powercli-vcenter-credential.xml"

Le script peut ensuite charger ce secret :

# Charge les identifiants chiffrés pour le compte courant
$Credential = Import-Clixml -Path "$HOME\.powercli-vcenter-credential.xml"

# Ouvre la session vCenter
$VIServer = Connect-VIServer -Server 'vcsa.lab.local' -Credential $Credential

# Affiche la cible effectivement connectée
$VIServer | Select-Object Name, Version, Build

Export-Clixml repose sur les mécanismes de chiffrement du système. Le fichier n’est donc généralement pas portable vers un autre compte ou une autre machine. Pour un agent CI/CD, utilisez plutôt le coffre-fort de secrets natif de l’outil, un gestionnaire de secrets centralisé ou des variables protégées injectées au moment de l’exécution.

Terminez systématiquement la session dans un bloc finally, notamment dans les scripts planifiés :

try {
    Connect-VIServer -Server 'vcsa.lab.local' -Credential $Credential -ErrorAction Stop

    # Traitements PowerCLI
}
finally {
    Disconnect-VIServer -Server 'vcsa.lab.local' -Force -Confirm:$false
}

Découvrir l’inventaire avec les cmdlets fondamentales

Les trois cmdlets les plus utilisées pour démarrer sont Get-VM, Get-VMHost et Get-Datastore. Elles retournent des objets PowerShell exploitables directement dans un pipeline. Il ne s’agit pas de simples lignes de texte : chaque objet contient des propriétés, des méthodes et des références vers les objets vSphere associés.

Lister et filtrer les machines virtuelles

La commande la plus simple est :

Get-VM

Dans un environnement conséquent, ne laissez pas cette commande sans filtre dans des scripts interactifs. Filtrez au plus tôt avec les paramètres disponibles :

# Toutes les VM du dossier Production
Get-Folder -Name 'Production' | Get-VM

# VM dont le nom commence par web-
Get-VM -Name 'web-*'

# VM arrêtées
Get-VM | Where-Object { $_.PowerState -eq 'PoweredOff' }

# VM actives avec leurs informations principales
Get-VM |
    Where-Object { $_.PowerState -eq 'PoweredOn' } |
    Select-Object Name, PowerState, NumCpu, MemoryGB, Guest

Pour des informations qui ne sont pas directement exposées par Get-VM, utilisez Get-View. Cette cmdlet accède plus directement aux objets de l’API vSphere et évite parfois une succession coûteuse d’appels distants.

# Récupère des propriétés ciblées depuis l'API vSphere
Get-View -ViewType VirtualMachine -Property Name, Config.Template, Runtime.PowerState |
    Where-Object { -not $_.Config.Template } |
    Select-Object Name,
        @{Name='Etat'; Expression={$_.Runtime.PowerState}}

Interroger les hôtes ESXi et les datastores

Pour les hôtes, commencez par distinguer l’état de connexion de l’état de maintenance :

Get-VMHost |
    Select-Object Name, Version, Build, ConnectionState, PowerState,
        @{Name='ModeMaintenance'; Expression={$_.ExtensionData.Runtime.InMaintenanceMode}}

Pour les datastores, surveillez surtout l’espace libre réel et le pourcentage utilisé. Les propriétés retournées sont généralement exprimées en octets pour CapacityGB et FreeSpaceGB déjà converties dans PowerCLI.

Get-Datastore |
    Select-Object Name, Type, CapacityGB, FreeSpaceGB,
        @{Name='UtilisationPct'; Expression={
            [math]::Round(
                (1 - ($_.FreeSpaceGB / $_.CapacityGB)) * 100,
                2
            )
        }} |
    Sort-Object UtilisationPct -Descending

Le tableau suivant résume les objets de départ et leurs usages courants.

Produire un inventaire automatisé exploitable

Un inventaire utile ne consiste pas uniquement à exporter les noms des VM. Il doit répondre à des besoins opérationnels : identifier les VM arrêtées, les templates, les systèmes invités, les adresses IP déclarées par VMware Tools, les datastores consommés et les responsables via les annotations ou tags.

Le script ci-dessous génère un inventaire CSV. Il utilise des blocs try/catch/finally, filtre les templates et construit une ligne lisible par disque virtuel.

param(
    [Parameter(Mandatory)]
    [string]$VCenter,

    [Parameter(Mandatory)]
    [pscredential]$Credential,

    [string]$OutputPath = ".\inventaire-vm.csv"
)

try {
    # Connexion explicite avec arrêt immédiat en cas d'échec
    Connect-VIServer -Server $VCenter -Credential $Credential -ErrorAction Stop | Out-Null

    # Récupération des VM hors templates
    $Inventory = Get-VM | Where-Object { -not $_.ExtensionData.Config.Template } | ForEach-Object {
        $VM = $_

        # Les informations invitées dépendent de VMware Tools
        $GuestInfo = Get-VMGuest -VM $VM -ErrorAction SilentlyContinue

        # Concatène les datastores liés aux disques de la VM
        $Datastores = ($VM | Get-Datastore | Select-Object -ExpandProperty Name) -join ';'

        [pscustomobject]@{
            Nom              = $VM.Name
            Etat             = $VM.PowerState
            vCPU             = $VM.NumCpu
            MemoireGB        = $VM.MemoryGB
            SystemeInvite    = $VM.Guest.OSFullName
            AdresseIP        = ($GuestInfo.IPAddress | Where-Object {
                                    $_ -notmatch ':' -and $_ -ne '127.0.0.1'
                                }) -join ';'
            Datastores       = $Datastores
            Dossier          = $VM.Folder.Name
            DateCreation     = $VM.ExtensionData.Config.CreateDate
            OutilsVMware     = $VM.ExtensionData.Guest.ToolsStatus
        }
    }

    # Export UTF-8 adapté aux traitements modernes et aux tableurs récents
    $Inventory |
        Sort-Object Nom |
        Export-Csv -Path $OutputPath -NoTypeInformation -Encoding utf8

    Write-Host "Inventaire exporté : $OutputPath"
}
catch {
    Write-Error "Échec de l'inventaire : $($_.Exception.Message)"
    exit 1
}
finally {
    Disconnect-VIServer -Server $VCenter -Force -Confirm:$false -ErrorAction SilentlyContinue
}

Planifiez ce script avec le Planificateur de tâches, un agent d’automatisation ou une pipeline planifiée. Pour éviter d’écraser l’historique, ajoutez un horodatage au nom de fichier. Pour des besoins de reporting, envoyez le CSV vers un stockage central, une base de données ou un outil de visualisation.

Créer des VM en masse depuis un fichier CSV

Le déploiement massif est l’un des premiers cas où PowerCLI apporte un gain immédiat. L’approche saine consiste à séparer les données de déploiement du code. Le script reste stable ; le CSV décrit les VM à créer. Pour aller plus loin, consultez l’administration quotidienne d’ESXi.

Exemple de fichier vms-a-créer.csv :

Name,Template,Cluster,Datastore,Folder,Network,NumCpu,MemoryGB
app-01,tmpl-windows-2022,Cluster-Production,vsanDatastore,Applications,VLAN-APP,2,8
app-02,tmpl-windows-2022,Cluster-Production,vsanDatastore,Applications,VLAN-APP,2,8
web-01,tmpl-linux-9,Cluster-Production,Datastore-NFS-01,Web,VLAN-WEB,2,4

Avant un déploiement réel, validez les valeurs référencées : template existant, dossier cible, réseau port group, datastore accessible au cluster et capacité disponible. Un script qui échoue après vingt VM sur cinquante est plus difficile à traiter qu’un script qui détecte l’erreur avant toute création.

Script de déploiement avec mode simulation

Le script suivant utilise SupportsShouldProcess, ce qui autorise -WhatIf. Commencez toujours par cette simulation pour vérifier les objets ciblés.

[CmdletBinding(SupportsShouldProcess)]
param(
    [Parameter(Mandatory)]
    [string]$CsvPath,

    [Parameter(Mandatory)]
    [string]$VCenter,

    [Parameter(Mandatory)]
    [pscredential]$Credential
)

try {
    Connect-VIServer -Server $VCenter -Credential $Credential -ErrorAction Stop | Out-Null

    $Requests = Import-Csv -Path $CsvPath

    foreach ($Request in $Requests) {
        # Vérifie qu'une VM portant le même nom n'existe pas déjà
        if (Get-VM -Name $Request.Name -ErrorAction SilentlyContinue) {
            Write-Warning "VM déjà existante, ignorée : $($Request.Name)"
            continue
        }

        # Résolution préalable des objets vSphere
        $Template  = Get-Template -Name $Request.Template -ErrorAction Stop
        $Cluster   = Get-Cluster -Name $Request.Cluster -ErrorAction Stop
        $Datastore = Get-Datastore -Name $Request.Datastore -ErrorAction Stop
        $Folder    = Get-Folder -Name $Request.Folder -ErrorAction Stop
        $Network   = Get-VirtualPortGroup -Name $Request.Network -ErrorAction Stop

        if ($PSCmdlet.ShouldProcess($Request.Name, "Créer la VM depuis $($Request.Template)")) {
            # Clone de la VM depuis le template
            $NewVM = New-VM -Name $Request.Name `
                            -Template $Template `
                            -ResourcePool $Cluster `
                            -Datastore $Datastore `
                            -Location $Folder `
                            -ErrorAction Stop

            # Ajustement des ressources après le clonage
            Set-VM -VM $NewVM `
                   -NumCpu ([int]$Request.NumCpu) `
                   -MemoryGB ([int]$Request.MemoryGB) `
                   -Confirm:$false `
                   -ErrorAction Stop | Out-Null

            # Affecte le premier adaptateur réseau à un port group donné
            Get-NetworkAdapter -VM $NewVM |
                Select-Object -First 1 |
                Set-NetworkAdapter -NetworkName $Network.Name `
                                   -Connected:$true `
                                   -StartConnected:$true `
                                   -Confirm:$false | Out-Null

            Write-Host "VM créée : $($Request.Name)"
        }
    }
}
catch {
    Write-Error "Échec du déploiement : $($_.Exception.Message)"
    exit 1
}
finally {
    Disconnect-VIServer -Server $VCenter -Force -Confirm:$false -ErrorAction SilentlyContinue
}

Exécution en simulation :

.\New-VMFromCsv.ps1 `
    -CsvPath .\vms-a-créer.csv `
    -VCenter vcsa.lab.local `
    -Credential (Get-Credential) `
    -WhatIf

Dans un environnement de production, complétez ce mécanisme par une spécification de personnalisation invitée (New-OSCustomizationSpec), une politique de tags, un contrôle de capacité et une journalisation détaillée. Le clonage crée l’objet VM ; il ne configure pas automatiquement le système d’exploitation sans personnalisation ou outil de configuration complémentaire.

Auditer la configuration et la conformité vSphere

Un audit PowerCLI efficace distingue trois niveaux : la collecte des faits, l’évaluation par rapport à une règle et la production d’un résultat exploitable. Évitez les scripts qui ne font qu’afficher un avertissement à l’écran. Un audit doit exporter un statut, une valeur observée, une valeur attendue et une action recommandée.

Les règles dépendent de votre référentiel interne. Exemples classiques : présence de snapshots anciens, VM avec VMware Tools obsolètes, hôtes en mode maintenance, datastores trop remplis, activation de SSH sur les hôtes, absence de tag de criticité ou contrôle de la configuration NTP.

Exemple d’audit des snapshots et de la capacité datastore

param(
    [Parameter(Mandatory)]
    [string]$VCenter,

    [Parameter(Mandatory)]
    [pscredential]$Credential,

    [int]$AgeSnapshotMaximumJours = 7,

    [int]$SeuilDatastorePct = 85
)

$Results = [System.Collections.Generic.List[object]]::new()

try {
    Connect-VIServer -Server $VCenter -Credential $Credential -ErrorAction Stop | Out-Null

    # Recherche de snapshots trop anciens
    Get-VM | Get-Snapshot | ForEach-Object {
        $Age = ((Get-Date) - $_.Created).Days

        if ($Age -gt $AgeSnapshotMaximumJours) {
            $Results.Add([pscustomobject]@{
                Type       = 'Snapshot'
                Objet      = $_.VM.Name
                Statut     = 'Non conforme'
                Observation = "Snapshot '$($_.Name)' âgé de $Age jours"
                Attendu    = "Age inférieur ou égal à $AgeSnapshotMaximumJours jours"
                Action     = 'Valider la nécessité du snapshot puis le supprimer'
            })
        }
    }

    # Contrôle du remplissage des datastores
    Get-Datastore | ForEach-Object {
        $Usage = [math]::Round(
            (1 - ($_.FreeSpaceGB / $_.CapacityGB)) * 100,
            2
        )

        if ($Usage -ge $SeuilDatastorePct) {
            $Results.Add([pscustomobject]@{
                Type       = 'Datastore'
                Objet      = $_.Name
                Statut     = 'Non conforme'
                Observation = "Utilisation à $Usage %"
                Attendu    = "Utilisation inférieure à $SeuilDatastorePct %"
                Action     = 'Libérer de l''espace ou rééquilibrer les VM'
            })
        }
    }

    $Results | Export-Csv -Path ".\audit-vsphere.csv" -NoTypeInformation -Encoding utf8

    if ($Results.Count -gt 0) {
        Write-Warning "$($Results.Count) écart(s) détecté(s)."
        exit 2
    }

    Write-Host "Audit terminé : aucune non-conformité détectée."
}
finally {
    Disconnect-VIServer -Server $VCenter -Force -Confirm:$false -ErrorAction SilentlyContinue
}

Le code de sortie 2 est volontaire : un outil CI/CD ou de supervision peut l’interpréter comme un état de non-conformité distinct d’une erreur technique. N’automatisez pas aveuglément les remédiations destructrices, telles que la suppression de snapshots. Produisez d’abord un rapport, validez la règle, puis introduisez une correction contrôlée avec approbation.

Intégrer PowerCLI dans une chaîne CI/CD

L’infrastructure peut être traitée comme du code à condition de respecter quelques principes simples : dépôt Git, revue de code, variables séparées selon l’environnement, secrets protégés, journalisation et contrôle après exécution. Une pipeline ne doit pas devenir un compte administrateur vCenter déguisé.

Une organisation minimale de dépôt peut ressembler à ceci :

powercli-infra/
├── scripts/
│   ├── Get-VSphereInventory.ps1
│   ├── New-VMFromCsv.ps1
│   └── Test-VSphereCompliance.ps1
├── data/
│   ├── dev/
│   └── production/
├── tests/
└── README.md

Étapes recommandées dans une pipeline

Dans un agent Windows ou Linux, installez le module PowerCLI au moment de construire l’image d’agent, plutôt qu’à chaque exécution. La version doit être figée et testée. Stockez les identifiants vCenter dans le coffre-fort du système CI/CD, puis créez l’objet PSCredential uniquement en mémoire.

Exemple de principe pour reconstruire un identifiant depuis des variables protégées :

$SecurePassword = ConvertTo-SecureString $env:VCENTER_PASSWORD -AsPlainText -Force
$Credential = [pscredential]::new($env:VCENTER_USERNAME, $SecurePassword)

.\scripts\Test-VSphereCompliance.ps1 `
    -VCenter $env:VCENTER_SERVER `
    -Credential $Credential

Le mot de passe ne doit jamais être affiché par Write-Host, ajouté à un transcript, ni transmis dans une ligne de commande visible par un autre processus. Préférez également des comptes distincts pour la lecture, le provisioning et les opérations d’administration hôte.

Savoir quand préférer Ansible ou Terraform

PowerCLI excelle pour l’administration impérative, l’exploitation quotidienne et l’accès direct à la richesse de l’API vSphere depuis PowerShell. Il est particulièrement pertinent si l’équipe maîtrise déjà PowerShell, si les opérations sont variées ou si l’automatisation doit interagir avec Active Directory, Windows, des API REST ou des fichiers métiers. Pour aller plus loin, consultez l’automatisation avec Ansible et Terraform.

Ansible et Terraform répondent à des besoins complémentaires. Ils ne remplacent pas nécessairement PowerCLI ; beaucoup d’équipes les combinent.

Ansible et les modules community.vmware

Ansible est adapté aux playbooks déclaratifs et à l’orchestration multi-systèmes. La collection community.vmware permet de créer ou configurer des VM, des réseaux, des datastores et certains paramètres vSphere. Ansible est intéressant lorsque la création de VM doit être suivie de la configuration du système invité, du déploiement applicatif et de la configuration réseau. Pour aller plus loin, consultez l’architecture d’un cluster vSphere.

Gardez toutefois en tête que les modules, les versions de collections et les dépendances Python doivent être maîtrisés. Pour certains cas avancés d’administration vSphere, PowerCLI expose plus directement les API VMware et offre davantage d’exemples opérationnels dans les environnements historiques.

Terraform et le provider vSphere

Terraform est particulièrement adapté au provisioning déclaratif avec gestion d’état. Un fichier HCL décrit la cible désirée, tandis que Terraform calcule un plan avant application. Cela apporte une discipline utile pour les infrastructures reproductibles, notamment pour des environnements de développement, de recette ou des plateformes applicatives standardisées.

Le revers est la gestion du fichier d’état. Il doit être stocké de manière sécurisée, verrouillée et partagée. Terraform ne remplace pas un outil d’exploitation : une action manuelle dans vCenter peut générer une dérive entre l’état réel et l’état déclaré. Il faut donc définir clairement quelles ressources sont sous gestion Terraform.

Une approche pragmatique consiste à utiliser Terraform pour décrire les VM standardisées, Ansible pour configurer les systèmes invités et PowerCLI pour les audits, les opérations exceptionnelles, les migrations, les rapports et les actions d’exploitation propres à vSphere.

Construire une automatisation durable

La première automatisation n’a pas besoin de couvrir tout le datacenter. Commencez par une tâche répétitive, mesurable et peu risquée : un inventaire hebdomadaire, la détection de snapshots anciens ou la création de VM de laboratoire depuis un CSV. Ajoutez ensuite des contrôles d’entrée, un mode simulation, des logs et une gestion d’erreurs.

Traitez les scripts comme du code d’infrastructure. Utilisez Git, documentez les prérequis, relisez les changements et testez dans un environnement non productif. Préférez des fonctions courtes et des paramètres explicites à un script monolithique dépendant de variables globales. Utilisez -ErrorAction Stop sur les opérations critiques afin que les blocs catch interceptent réellement les erreurs non terminantes de PowerShell.

Enfin, l’industrialisation ne se résume pas à lancer plus vite des commandes. Elle consiste à rendre les opérations prédictibles, auditables et réversibles. PowerCLI est un excellent point d’entrée pour y parvenir dans un environnement VMware : il permet d’automatiser progressivement sans imposer dès le premier jour une refonte complète des pratiques d’exploitation.