Hypervisor.fr

MAJ 18/05/2011 : Mise à jour du script pour supporter vCenter 4.1

Si vous voulez vous faire peur, voici un petit script powershell qui calcul la somme totale d’espace occupée par les snapshot de toutes les VM concernées.

Get-SnapWaste.ps1

Sur notre infra de production, le résultat fait très mal :

Tags: powershell, scripting

En environnement NFS, lors d’une grosse coupure réseau ou d’une opération de maintenance, il arrive que le status d’une VM devienne “invalid” ou “inaccessible” car l’ESX(i) a perdu la liaison avec le fichier vmx de la VM :

Après vérification de la connectivité avec le datastore, il faut reloader la VM pour qu’elle soit de nouveau accessible. A l’origine, seul un restart du service hostd ou un reload du vmid en vimsh permettait de corriger le problème et obligeait de se connecter à chaque ESX(i) pour effectuer l’opération (ssh ou vMA) :

Grâce au powershell et au PowerCLI (aka VI toolkit), il est possible d’identifier les VM dont le status est “invalid” ou “inaccessible” et forcer le reload du vmx

(Get-View -ViewType VirtualMachine) |?{$_.Runtime.ConnectionState -eq "invalid" -or $_.Runtime.ConnectionState -eq "inaccessible"} |%{$_.reload()}

Tags: powershell

L’une des alarmes par défaut qui manque cruellement à vCenter, c’est celle de l’Overallocation. Il est heureusement possible (et vivement conseillé) de la créer :

Il est également possible d’obtenir la valeur en powershell:

$storages = Get-Datastore |Get-View
$voverallocation = @()
foreach ($storage in $storages)
{
	if ($storage.Summary.Uncommitted -gt "0")
	{
	$Details = "" | Select-Object Datastore, Overallocation
	$Details.Datastore = $storage.name
	$overallocation = [math]::round(((($storage.Summary.Capacity - $storage.Summary.FreeSpace) + $storage.Summary.Uncommitted)*100)/$storage.Summary.Capacity,0)
 
		if ($overallocation -gt 99)
		{
		$Details.overallocation = "$overallocation" + "%"
		$voverallocation += $Details
		}
	}
}
$voverallocation

Tags: powershell, scripting

MAJ 15/05/2015 : 6 ans plus tard cette technique est toujours autant d’actualité et c’est donc tout naturellement que nous vous proposons un joli onliner qui viendra poser les bundles dans c:\temp

Get-View -ViewType HostSystem |?{$_.config.product.ProductLineId -eq "embeddedEsx"} |?{$_.Runtime.ConnectionState -eq "connected"}|%{Get-VMHostFirmware -VMHost $_.Name -BackupConfiguration -DestinationPath C:\temp\}

Les plus observateurs aurons remarquez que le backup passe maintenant par la cmdlet Get-VMHostFirmware mais pour restaurer un bundle, c’est toujours Set-VMHostFirmware qu’il faut utiliser. En local sur l’ESXi (aka “ESXi shell”) c’est avec la commande vim-cmd que ça se passe.

Un des gros avantages d’ESXi est qu’il a été à l’origine conçu pour être booté via PXE. Pour cette raison entre autres, la config complète (hors VM bien sûr) d’ESXi est backupée toutes les heures (par la crontab /var/spool/cron/crontabs/root) sous la forme d’un package (state.tgz) qui servira au prochain boot (statefull ou stateless) ou à la cmdlet Set-VMHostFirmware. Le script suivant sauvegarde le configBundle de chaque ESXi, facilement utilisable dans une tache planifiée sur votre vCenter :

$backpath = "c:\bundle_backup\"
$eVMHs = Get-View -ViewType HostSystem |?{$_.config.product.ProductLineId -eq "embeddedEsx"} |?{$_.Runtime.ConnectionState -eq "connected"}
	Foreach	($eVMH in $eVMHs)
	{Set-VMHostFirmware -VMHost $VMH.name -BackupConfiguration -DestinationPath $backpath}

Sur le screenshot, vous pouvez constater que pour 39 ESXi, la taille totale du backup dépasse à peine 1Mo. En détail, le configBundle d’un host standalone pèse environ 10ko et celui d’un host membre d’un cluster HA pèse environ 100ko (à cause de l’agent AAM). Malgré sa petite taille, ce bundle contient chaque paramètre de la configuration de l’ESXi, y compris le certificat SSL. Ce qui signifie qu’il est possible d’échanger une machine sans impact grâce à ce bundle.

/!\ le bundle est lié à la version de l’ESXi dont il provient et ne peut doit être restauré que sur un ESXi de version identique /!\

Tags: ESXi, powershell, scripting, state.tgz

MAJ 28/09/2009 : William Lam vient de mettre à dispo l’équivalent de notre script en perl pour les aficionados de vMA. Nous en profitions pour etoffer le resultat avec les ConfigState et les RuntimeState.

Alors qu’avec les API du visdk 2.5 il n’était pas possible de communiquer avec les agents AAM (cluster HA), celle du visdk 4.0 (aka vSphere API 4.0) permettent d’obtenir quelques infos intéressantes. L’une d’elles l’est particulièrement puisqu’elle permet de lister les primary nodes d’un cluster HA :

((Get-View -ViewType ClusterComputeResource -filter @{"name" = "clustername"}).RetrieveDasAdvancedRuntimeInfo()).DasHostInfo.PrimaryHosts

((Get-View -ViewType ClusterComputeResource -filter @{"name" = "clustername"}).RetrieveDasAdvancedRuntimeInfo()).DasHostInfo.HostDasState | select Name,ConfigState,RuntimeState

Tags: HA, powershell, scripting