VMware et Powershell : contrôle de l’état des vmtools et des disques orphelins

Suite à quelques cas de vmtools qui tombaient en carafe sur des serveurs Windows en clientèle, j’ai eu l’idée de réaliser un petit script personnel afin de contrôler l’état des vmtools sur un ESXi ou un vCenter, et de remonter une alerte par email si jamais ils ne sont pas dans leur état normal.

On reçoit donc un courriel si les vmtools ne sont pas : en cours d’exécution, à jour ou installés. Par défaut, le script renvoie comme vmtools en erreur les machines qui sont éteintes car le serveur ne peut les joindre. C’est pourquoi il est nécessaire lors du contrôle d’exclure les machines éteintes.

 

Add-PSSnapin VMware.VimAutomation.Core
Add-PSSnapin VMware.PowerCLI
$From = "admin-vmw@localhost"
$To = "supervision@localhost"
$Smtp = "smtp.localdomain"
$ESXServer = "esxi.localdomain"
$ESXUser = "service"
$ESXPwd = "P@ssw0rd"

Connect-VIServer $ESXserver -User $ESXUser -Password $ESXPwd

$VMArray = Get-VM
foreach ($VM in $VMArray)
    {
    $VMPoweredOn = $VM.PowerState
    $toolsStatus = $VM.ExtensionData.Guest.ToolsStatus
    if ($toolsStatus -ne "toolsOK" -and $VMPoweredOn -eq "PoweredOn")
        {
        $MailString = "Bonjour, les vmtools sur la machine '$VM' remontent avec le statut inhabituel suivant : '$toolsStatus'."
        Send-MailMessage -From $From -To $To -Subject "vmtools en statut anormal sur $VM" -SmtpServer $Smtp -Body $MailString
        }
    }

Cela permet alors de pouvoir être plus réactif sur le bon fonctionnement des vmtools et d’éviter d’avoir des soucis de drivers réseau ou d’interface avec d’autres applications. Ce script est disponible dans une version commentée en cliquant sur mon miroir de téléchargement. A noter que pour ce script comme pour le suivant, un seul module Powershell est nécessaire mais en fonction de la version de PowerCLI installée, le nom de celui-ci peut changer.

Le deuxième script que j’ai écrit permet de trouver les VMDK orphelins présents sur les datastores d’un vCenter ou d’un ESX. Il prend la liste des VMDK sur les datastore puis récupère la liste des disques rattachés à une machine virtuelle. Il fait ensuite la différence des deux disques et affiche la liste des différences. Avant de procéder à une suppression, tout de même vérifier si le VMDK n’a pas été désolidarisé pour une raison X ou Y, ou qu’il ne s’agit pas d’un snapshot.

Add-PSSnapin VMware.VimAutomation.Core
Add-PSSnapin VMware.PowerCLI

$vmdkds=@()
$vmdkvm=@()
Write-Host "Parsing all datastores and VMDKs. This might take a while.`r`n"
$dslist = Get-View -ViewType Datastore | select Name
foreach($ds in $dslist) {
	$vmdks = Get-HardDisk -Datastore $ds.Name
        foreach($vmdk in $vmdks) {
            $vmdkfilename = @{Filename = $vmdk.Filename}
            $vmdkentry = New-Object PSObject -Property $vmdkfilename
            $vmdkds+=$vmdkentry
        }
	}
    $vmlist = Get-View -ViewType VirtualMachine | select Name
    foreach($vm in $vmlist) {
        $vmdks = Get-HardDisk -VM $vm.Name
        foreach($vmdk in $vmdks) {
            $vmdkfilename = @{Filename = $vmdk.Filename}
            $vmdkentry = New-Object PSObject -Property $vmdkfilename
            $vmdkvm+=$vmdkentry 
        }
    }
Write-Host "Done. Now processing. Please wait.`r`n"
Compare-Object $vmdkvm $vmdkds -Property Filename | Where-Object { $_.SideIndicator -eq "=>" } | foreach-object { Write-Host $_.InputObject }

Vous pouvez également trouver ce script dans une version commentée sur ce lien provenant de mon miroir de téléchargement.

VMware et Powershell : détection de snapshots anciens et surveillance de l’espace libre

PowerCli est un excellent outil pour faciliter l’administration et la maintenance d’une infrastructure VMware. Il m’arrive d’écrire des scripts pour un client ou pour moi-même en fonction de tâches que j’ai à réaliser. Dans ce billet, je vais partager aujourd’hui deux petits scripts tout simples.

Le premier permet de scanner les VM présentes sur l’ESX ou le vCenter et d’envoyer un courriel si un snapshot est plus ancien qu’un certain nombre de jours. Par défaut, si un snapshot existe sur une machine virtuelle, un mail est tout de même envoyé.

Add-PSSnapin VMware.VimAutomation.Core
$From = "admin-vmw@localhost"
$To = "supervision@localhost"
$Smtp = "smtp.localdomain"
$Delay = 7

Connect-VIServer $ESXserver -User $ESXUser -Password $ESXPwd

$VMNamesArray = Get-VM | select Name
foreach ($VMName in $VMNamesArray)
    {
    $VMSnaps = Get-Snapshot $VMName.name
    foreach ($Snap in $VMSnaps)
        {
        $now = Get-Date
        if ($Snap.Created.AddDays($Delay) -gt $now -eq $false)
            {
            $SnapVM = $Snap.VM
            $MailString = "Bonjour, le snapshot '$Snap' de la machine '$SnapVM' existe depuis plus de $Delay jours."
            Send-MailMessage -From $From -To $To -Subject "Alerte snapshot" -SmtpServer $Smtp -Body $MailString
            }
        else
            {
            $MailString = "Aucun snapshot datant de plus de $Delay jours existant."
            Send-MailMessage -From $From -To $To -Subject "Rapport snapshot" -SmtpServer $Smtp -Body $MailString
            }
        }
    }

Le second script analyse les datastore de l’ESX ou du vCenter et envoie un mail si jamais il y a dépassement du seuil prédéfini. Il me semble que les préconisations VMware font état d’un besoin minimal de 20% de libre sur un datastore pour assurer le fonctionnement optimal de celui-ci. Le script va envoyer un courriel si jamais un datastore tombe à moins de 25% d’espace libre.

Add-PSSnapin VMware.VimAutomation.Core
$From = "admin-vmw@localhost"
$To = "supervision@localhost"
$Smtp = "smtp.localdomain"
$SeuilAlerte = 25

Connect-VIServer $ESXserver -User $ESXUser -Password $ESXPwd

$DatastoreArray = Get-Datastore
foreach ($Datastore in $DatastoreArray)
    {
    $MBAvail = $Datastore.FreeSpaceMB
    $MBTotal = $Datastore.CapacityMB
    $FreeProp = ($MBAvail/$MBTotal) * 100
    if ($FreeProp -lt $SeuilAlerte)
        {
        $FreeProp = [math]::Round($FreeProp,1)
        $MailString = "Bonjour, le datastore '$Datastore' n'a plus que $FreeProp % de libre."
        Send-MailMessage -From $From -To $To -Subject "Alerte occupation Datastore" -SmtpServer $Smtp -Body $MailString
        }
    }

Vous pouvez récupérer les scripts depuis mon miroir de téléchargement dans des versions commentées :
Script d’alerte snapshot
Script d’alerte datastore

Sauvegarde wbadmin impossible sur contrôleur de domaine virtuel 2012 R2

Comme premier article, je vais aborder le problème auquel j’ai été confronté récemment après avoir mis en place ma petite infrastructure que je présenterai éventuellement dans un prochain billet.

Je possède un contrôleur de domaine fonctionnant sous Windows Server 2012 R2, le seul de la forêt. Je possède un autre serveur 2012 R2, qui va recevoir sur un disque virtuel dédié les fichiers de sauvegarde des autres serveurs Windows ainsi que les fichiers des quelques scripts de sauvegardes de mes machines Linux.

Je veux donc concentrer sur ce serveur les sauvegardes Windows Server afin de pouvoir les sauvegarder en ligne plus facilement par la suite.

Sur mon contrôleur de domaine, j’installe donc la fonctionnalité Windows Server, et tente d’exécuter une première sauvegarde. Pour des raisons de performances disques (disques mécaniques en SATA3) et vu le peu de criticité, je ne souhaite pas effectuer de sauvegarde planifiée mais des sauvegardes uniques que je réaliserai de temps en temps. Je choisis donc de sauvegarder le serveur complet.

Je précise l’emplacement réseau du lecteur de sauvegarde, et je lance l’opération. Quelques minutes plus tard, la sauvegarde rentre en erreur au moment de sauvegarder le disque C:.

Dans les logs, rien de bien transcendant : c:\windows\logs\WindowsImageBackup

J’essaye donc de sauvegarder un autre serveur exactement de la même manière et avec le même compte de sauvegarde (un compte de service qui est le seul à avoir les droits complets sur le dossier du partage réseau, et qui est membre du groupe Opérateurs de Sauvegarde). Cela fonctionne, cela signifie que ce n’est pas le partage réseau qui pose problème.

Autre piste suggérée : la taille des secteurs n’est pas la même. En regardant sur les deux machines grâce à msinfo32.exe, je vois qu’ils font bien la même taille de 512 K.

Je tente un sfc /scannow sur le contrôleur de domaine afin de vérifier l’état des fichiers système, même si le serveur a été installé il y a moins de 48 heures. Pas d’erreur décelée. Je monte un second disque virtuel afin d’effectuer une sauvegarde en local, toujours impossible, le problème semble donc venir de l’accès au C:.

Finalement, je décide alors de boycotter l’interface graphique de wbadmin ainsi que l’utilisation en ligne de commande qui ne donne pas plus de résultats, même avec un lancement en tant qu’administrateur du domaine. Je recherche rapidement sur le web comment utiliser PowerShell pour se substituer au cmd et tombe sur un script fourni sur une plateforme Microsoft.
Etant donné que je n’ai pas besoin de toute la partie envoi de mail ni suivi du nombre de sauvegarde, je l’ai quelque peu simplifié.

Add-PsSnapin Windows.ServerBackup
$Server = « \\serveur »
$Folder = ($Server+ »\dossier »)
$WBPolicy = New-WBPolicy
Add-WBBareMetalRecovery -Policy $WBPolicy | Out-Null
$BackupLocation = New-WBBackupTarget -network ($Folder)
Add-WBBackupTarget -Policy $WBPolicy -Target $BackupLocation -force | Out-Null
$WBPolicy | Out-Null
Start-WBBackup -Policy $WBPolicy

On spécifie donc un serveur de sauvegarde, un répertoire accessible, on spécifie les paramètres souhaités dans la policy, et on exécute.
Via PowerShell, la sauvegarde s’est bien déroulée, il ne me restera plus qu’à appeler ce script lorsque je souhaiterai réaliser une sauvegarde. A noter que le script d’origine permet de sauvegarder également les autres volumes du systèmes qui sont non critiques (non swap, non système), mais n’ayant qu’un volume sur ce DC, l’option ne me concerne pas. Vous pouvez trouver le script d’origine en suivant ce lien. Apparemment la fonctionnalité WBBackup de PowerShell est conseillée par rapport au wbadmin. Question d’habitudes, j’utilisais toujours wbadmin avant.

Il ne me reste plus qu’à uploader sur mon ftp la sauvegarde pour être tranquille, et la faire redescendre sur ma station de travail au cas où.

Vous pouvez récupérer le script présent dans ce billet en le téléchargeant sur mon miroir de fichiers.