MAJ 25/04/2014 : Mise à jour du script (version 1.1) : A la demande express de notre ami DR, nous avons rajouté le paramètre -VIX pour faire la requête WMI via les vmtools et le paramètre -noSSO pour spécifier des credentials autre que ceux de votre session courante. A ce propos, et à notre plus grande surprise, la cmdlet Invoke-VMScript semble dorénavant supporter le SSO donc si votre compte AD à les bons droits sur le vCenter et dans le GuestOS, plus besoin du paramètre “GuestCredential” pour faire du VIX !

Lorsqu’on vous demande de retirer quelques disques d’une VM Windows qui en possède une cinquantaine, c’est généralement le début d’une longue chasse où on essaye de faire correspondre les id scsi, les contrôleurs ou les tailles de volume quand on est vraiment au bout du rouleau…

Il y a bien des scripts PowerCLI pour surmonter la tâche mais l’élément de référence est toujours l’id scsi ce qui pose parfois des problèmes comme ça l’à été pour nous lors d’une opération similaire :

Une kb VMware décrit comment faire une correspondance via le device manager de windows (et non pas le disk manager) mais où il faut chercher à la main la propriété “location” qui correspond au contrôleur scsi :

To correlate the virtual device node SCSI controller to the Windows drive letter. Each controller increments by 32.
The first SCSI controller is given a location ID of 160. Therefore the second controller is 192, 224 for the third and 256 for the fourth.

Nous vous laissons apprécier l’ampleur de la tache lorsqu’on a plusieurs disques à détacher :

En cherchant un peu sérieusement, nous avons trouver un point commun parfaitement identique entre Hard disk et PHYSICALDRIVE : l’UUID (ou SerialNumber sous Windows). Un petit coup de PowerCLI plus tard, on obtient un beau tableau pour faire la correspondance sans risque (avec le chemin du vmdk en bonus) :

Les prérequis du script sont que vous soyez connecté au bon vcenter et que vous puissiez accéder en WMI à la VM en question (si le FQDN de la vm ne correspond pas à son nom, il faut utiliser le paramètre -winname). Le paramètre -grid controle la sortie dans un GridView pour ceux qui n’aime par le style CLI :

Get-VMWinUUIDMap

Get-View -ViewType virtualmachine -Property Name, Summary, Config, Guest|?{!$_.snapshot -and $_.Guest.GuestFamily -eq "windowsGuest" -and $_.Guest.ToolsRunningStatus -eq "guestToolsRunning"}|?{!($_.Config.Hardware.Device|?{$_ -is [VMware.Vim.VirtualDisk]}|?{$_.Backing.ThinProvisioned}) -eq $false}|select name, @{n="GuestId";e={$_.Guest.GuestId}}, @{n="vmdkCommitted";e={[math]::round($_.Summary.Storage.Committed/1GB,1)}}, @{n="GuestCommitted";e={[math]::round(($_.Guest.Disk|%{$_.Capacity - $_.FreeSpace})/1GB,1)}}, @{n="ThinDiff";e={[math]::round((($_.Summary.Storage.Committed - (($_.Config.Hardware.MemoryMB*1MB - $_.Config.MemoryAllocation.Reservation) + $_.Config.InitialOverhead.InitialSwapReservation)) - ($_.Guest.Disk|%{$_.Capacity - $_.FreeSpace}))/1GB,1)}}|?{$_.ThinDiff -gt 20}|Out-GridView

Ce petit bout de script vous affichera un beau tableau des VM (windows uniquement – pour l’instant) dont la différence entre la taille commitée outGuest (vmdk) et inGuest (ntfs) est supérieure à 20Go.

Par contre, nous n’avons pu naviguer que dans des partitions FAT ou NTFS sans pouvoir les modifier…

Malheureusement il faut être sur la vm pour voir ce message, d’où l’idée d’un ami champion de badminton de faire une alarme pour remonter cet event !

Ni une, ni deux, un petit oneliner qui va créer la précieuse alarme :

if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -match "VM disks consolidation is needed"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "VM disks consolidation is needed";Description = "Custom alarm to monitor com.vmware.vc.VmDiskConsolidationNeeded event";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "com.vmware.vc.VmDiskConsolidationNeeded";objectType = "VirtualMachine";status = "red"});(New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "com.vmware.vc.VmDiskConsolidatedEvent";objectType = "VirtualMachine";status = "green"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} VM disks consolidation is needed - {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}

Comme d’hab, il faut remplacer “admin@vmare.local” par le mail qui vous convient et rajouter (ou remplacer) un envoi de trap snmp si besoin. Cette alarme s’auto-acquittera lorsque la consolidation sera réussie :

MAJ 30/10/2012 : Mise à jours des scripts pour n’exclure que les vm “invalid” ou “orphaned”.

MAJ 06/07/2012 : Mise à jour des scripts pour exclure “*/hostCache/*” pour ne pas remonter les fichiers vswp de la fonction Host Cache d’ESXi 5.

MAJ 05/07/2012 : Mise à jour des scripts pour intégrer les fichiers vswp.xxxxxx, merci à Larus Hjartarson pour l’idée.

MAJ 21/03/2012 : Mise à jour des scripts pour exclure “var/tmp/cache” dans le cas d’une redirection de la partition scratch sur un datastore.

MAJ 06/03/2012 : Mise à jour des scripts pour le support des multi-datacenter/multi-vcenter, des snapshot NetApp et des fichiers zdump qui trainent.

MAJ 28/02/2012 : Mise à jour des scripts suite à une erreur dans le “SideIndicator”

MAJ 24/02/2012 : Et pour ceux qui ont *VRAIMENT* confiance, voici le script pour supprimer les fichiers vswp orphelins (et si vraiment vous en avez, vous pouvez changer le filtrage au niveau du |?{$_.lostfile -match “vswp”}) :

foreach ($lost in (compare -passthru -property path $(foreach ($ds in ((get-view -ViewType datastore|sort name -unique|?{$_.summary.accessible}|%{(get-view $_.browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*zdump*","*.xml","*.vmsn","*.vmsd","*.vswp*", "*.vmx","*.vmdk","*.vmss","*.nvram","*.vmxf"); details=(New-Object VMware.Vim.FileQueryFlags -property @{filesize=$true;modification=$true})}))})|?{$_.file})){foreach ($files in $ds.file){$files|?{$_.Path -notmatch "-ctk.vmdk|esxconsole.vmdk|esxconsole-flat.vmdk"}|select @{n="path";e={$ds.FolderPath + $files.path|%{$_ -replace " ",""}}},FileSize,Modification|?{$_.path -notmatch ".zfs|.snapshot|var/tmp/cache|/hostCache/|.lck"}}}) $(get-view -ViewType virtualmachine|?{$_.Runtime.ConnectionState -notmatch "invalid|orphaned"}|%{$_.layoutex.file}|?{$_.type -ne "log"}|%{$_.name}|%{$_ -replace " ",""}|sort -unique|select @{n="path";e={$_}})|?{$_.SideIndicator -eq "<="}|select @{n="LostFile";e={$_.Path -replace "]","] "}}, @{n="FileSize";e={"{0:N0}" -f ($_.FileSize/1MB)}}, Modification|?{$_.lostfile -match "vswp"})){(get-view (Get-View ServiceInstance|select -first 1).content.filemanager|select -first 1).DeleteDatastoreFile($lost.LostFile,(Get-View -ViewType datacenter|?{$_.Datastore -match (get-datastore $lost.LostFile.split("[]")[1]|get-view).moref}|select -first 1).moref)}

MAJ 24/02/2012 : Mise à jour du script pour afficher la taille en MegaBytes et la date de modification des fichiers.

Très fortement inspiré du célèbre Raiders of the Lost VMX (mais aussi du post Orphaned files and folders – Spring cleaning) de LucD, nous avons enfin fini de finioler un oneliner PowerCLI qui va vous lister les fichiers .xml, .vmsn, .vmsd, .vswp, .vmx, .vmdk, .vmss, .nvram et .vmxf qui traînent sur vos datastores et qui ne sont pas rattachés à une quelconque vm du vcenter depuis lequel vous avez exécuté le script.

compare -passthru -property path $(foreach ($ds in ((get-view -ViewType datastore|sort name -unique|?{$_.summary.accessible}|%{(get-view $_.browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*zdump*","*.xml","*.vmsn","*.vmsd","*.vswp*", "*.vmx","*.vmdk","*.vmss","*.nvram","*.vmxf"); details=(New-Object VMware.Vim.FileQueryFlags -property @{filesize=$true;modification=$true})}))})|?{$_.file})){foreach ($files in $ds.file){$files|?{$_.Path -notmatch "-ctk.vmdk|esxconsole.vmdk|esxconsole-flat.vmdk"}|select @{n="path";e={$ds.FolderPath + $files.path|%{$_ -replace " ",""}}},FileSize,Modification|?{$_.path -notmatch ".zfs|.snapshot|var/tmp/cache|/hostCache/|.lck"}}}) $(get-view -ViewType virtualmachine|?{$_.Runtime.ConnectionState -notmatch "invalid|orphaned"}|%{$_.layoutex.file}|?{$_.type -ne "log"}|%{$_.name}|%{$_ -replace " ",""}|sort -unique|select @{n="path";e={$_}})|?{$_.SideIndicator -eq "<="}|select @{n="LostFile";e={$_.Path -replace "]","] "}}, @{n="FileSize";e={"{0:N0}" -f ($_.FileSize/1MB)}}, Modification|ft -autosize

Les snapshots ZFS (.zfs/snapshot), les fichiers -ctk.vmdk (fichiers CBT) et les vmdk des COS d’ESX classic (esxconsole-) sont filtrés, n’hésitez pas à nous remonter d’autres faux positifs que vous pourriez rencontrer. Prochaine étape : ménage automatique…

N’importe lequel de ces messages vous mènera aux forums VMware, sur des blogs ou même à cette kb qui précise justement ce que nous allons prendre à contre pied :

Because a virtual machine can be moved between hosts, the host where the virtual machine is currently registered may not be the host maintaining the file lock. The lock must be released by the ESX host that owns the lock

Le point commun de ces troubleshooting est l’objectif de faire sauter le lock du ou des fichiers, ce qui parait tout à fait censé et que nous avons d’ailleurs déjà suivi par le passé en essayant aussi de redémarrer le service hostd en masse grâce à plink (ou esxi.txt est la liste des fqdn) avant de redémarrer l’ESX en dernier recours :

@echo off
FOR /F %%i in (esxi.txt) do call :plink %%i
:plink
"C:\Program Files (x86)\PuTTY\plink.exe" -pw "password" root@%1 "/sbin/services.sh restart"
GOTO End
:Last
:End

Cette dernière étape est particulièrement longue et fastidieuse alors que, sauf cas exceptionnel, la solution “idéale” est de trouver le dernier ESX ayant fait tourné la vm (via le vmware.log ou grâce à export régulier des infos du vCenter), de passer DRS en manuel pour être prompté au démarrage de la VM et de selectionner le bon ESX :

C’est tout simple mais ça marche très bien