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…

Disons que vous souhaitez limiter la possibilité de faire un snapshot sur vos vm uniquement s’il y a suffisamment d’espace sur les datastore, vous utiliseriez notre beau petit one-liner fait main :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="snapshot.minFreeSpace"; Value="$($($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum)"}))}))}

Ce script fixe le snapshot.minFreeSpace à la somme de la taille des vmdk (taille max d’un snapshot) et se limite aux vm dont les vmdk résident sur un seul et unique datastore.

Mais avant de passer ce script, peut être voudriez vous vérifier que vous n’avez pas des vm déjà dans cette situation ? Cet autre petit one-liner vous donnera la liste de chaque vm dont la taille totale est supérieure à l’espace libre du datastore où elle réside :

Get-View -ViewType virtualmachine|?{-not $_.Config.Template}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique|measure-object).count -eq 1}|?{($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.CapacityInKB*1KB}|measure-object -sum).sum -gt ((get-view -viewtype datastore -property name,summary -filter @{"name" = ($_.Config.Hardware.Device|?{$_.GetType().Name -eq"VirtualDisk"}|%{$_.Backing.FileName.split("[]")[1]}|sort -Unique)}).Summary.FreeSpace)}|select name

Currently, VMware does not support quiesced snapshot of virtual machines running the vCenter Server database.

[...]

If quiesced snapshots are created by backup software to back up the virtual machine data, either use:

• A backup solution that provides application-level quiescing.
• Backup Agents in the guest operating system.

Il est donc recommandé d’utiliser un produit comme veeam backup pour faire un backup de votre VCDB avant de tout exploser

De toute façon, les snapshots c’est mal : Performance impact when using VMware snapshots

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

• Snapshots are not backups
• The maximum supported amount in a chain is 32
• VMware recommends that you use only 2-3 snapshots in a chain
• Use no single snapshot for more than 24-72 hours

An excessive number of snapshots in a chain or snapshots large in size may cause decreased virtual machine and host performance.

Increasing the size of a disk with snapshots present can lead to corruption of the snapshots and potential data loss.

Avant l’U2

Après l’U2

vSphere 4.0 supports linked virtual machines, which are two or more virtual machines that share storage.

Nous avons concocté un petit script qui permet de créer un clone ou un linked clone à partir du snapshot de votre choix. Compte tenu des risques, de nombreuses vérifications sont faites par le script pour éviter une mauvaise opération. Vous faites le choix d’un simple linked clone grâce au paramètre -linkedonly=$true (l’opération par défaut est un clone à partir d’un linked clone temporaire) et avez le choix de transformer le clone en template :

Évidement, cette opération peut être effectuée VM “on” :

download

[...] in vStorage API as well as in VCB modes, all snapshots are committed to the VMDK file, it’s VMware expected behavior. But If you still want to backup your current snapshot tree, you should use Network mode

Il fait évidement allusion au Network mode de Veeam Backup qui ne souffre pas de cette limitation :

You cannot increase the size of a virtual machine’s hard disk after you create a snapshot of the virtual machine.

There is no workaround.

Au fil des version d’ESX, on a droit à plusieurs scénarii. Pour les plus anciennes versions d’ESX 3.5, le resize est possible en GUI mais la VM refusera de booter après.

Pour les version les plus récentes d’ESX 3.5, si la VM est OFF il ne se passe strictement rien après le changement de taille mais si la VM est démarrée on a droit à un simple message d’erreur après tentative.

VMware a fini par réagir avec la version 4 en bridant la fonctionnalité via la GUI :

La raison de cette limitation semble évidente mais comme nous l’a habilement fait remarqué un collègue, “cela pourrai être géré par le système”. Après un bref googling, nous trouvons la clef de l’énigme chez sanbarrow, un vétéran de la communauté vmware et créateur de MOA (aka Multi Operating system Administration / Addicts) :

fix Extent description to the size after expand

Voici la procédure en détail (VM OFF) :

• Augmenter la taille du vmdk avec vmkfstools
• Relever la nouvelle taille dans la section “Extent description”
• Remplacer l’ancienne valeur dans le vmdk du (ou des) snapshot
• Reloader la vm (vim-cmd ou vmware-cmd)

Comme toujours, si vous ou l’un de vos équipiers étiez grillés par VMware, Hypervisor.fr nierait avoir eu connaissance de vos agissements. Ce post s’autodétruira dans cinq secondes.

Pour les vPowerusers que nous sommes, cela peut paraitre hallucinant mais sous XenServer 5.5, pour faire un revert de snapshot, il faut (dixit l’admin guide) :

• Run the vm-list command to find the UUID of the VM to be destroyed
• Shutdown the VM
• Destroy the VM
• Create a new VM from the snapshot
• Start the VM

Heureusement pour eux, le script dont il est question évite ce pèlerinage.

VMware vient de mettre en ligne une kb expliquant en détail le process d’un snapshot ainsi que des links vers d’autres kb se rapportant à des best pratices et autres problèmes concernant les snapshots.

]]> http://www.hypervisor.fr/?feed=rss2&p=1482 0 http://www.hypervisor.fr/?p=1080 http://www.hypervisor.fr/?p=1080#comments Fri, 28 Aug 2009 16:15:03 +0000 NiTRo http://www.hypervizor.fr/?p=1080 Lorsqu’on a besoin d’extraire un fichier d’un snapshot, il n’existe que peu de solution. Impossible de cloner la VM car cette fonction “commit” les snapshots et le “revert” ferait perde les modifications en cours.Voici une méthode simple et rapide :

1. Copie du vmdk comprenant le fichier recherché (vmkfstools -i)
2. Connexion au host/datastore avec le “datastore browser” du VI Client
3. Download du vmdk copié
4. Ouverture du fichier “flat” avec winimage
5. Sélection de la partition
6. Extraction du fichier/répertoire

MAJ 29/03/2011 : Mise à jour du script pour supporter vCenter 4.1

En cherchant un moyen élégant de remonter dans rapport la taille occupée par les différents snapshots d’une VM, nous sommes tombés sur un script powershell récemment posté par Arnim van Lieshout : How big is my VM?

Malheureusement, son script n’est pas compatible avec vCenter 4.0, à cause d’un petit bug d’API repéré par plusieurs membres de la communauté VMware lors de l’adaptation d’un script peremetant de lister les vmdk orphelins.

C’est grâce à Yasen Kalchev que nous avons pu modifier ce script et le rendre opérationnel pour vCenter 4.0 :

param( [string] $vm)
 
function Get-VmSize($vm)
{
    #Initialize variables
    $VmDirs =@()
    $VmSize = 0
 
		$fileQueryFlags = New-Object VMware.Vim.FileQueryFlags
		$fileQueryFlags.FileSize = $true
		#$fileQueryFlags.FileType = $true
		#$fileQueryFlags.Modification = $true
		$searchSpec = New-Object VMware.Vim.HostDatastoreBrowserSearchSpec
		$searchSpec.details = $fileQueryFlags
 
    Get-View -ViewType VirtualMachine -Filter @{"Name" = "^$vm$" } | % {
        #Create an array with the vm's directories
        $VmDirs += $_.Config.Files.VmPathName.split("/")[0]
        $VmDirs += $_.Config.Files.SnapshotDirectory.split("/")[0]
        $VmDirs += $_.Config.Files.SuspendDirectory.split("/")[0]
        $VmDirs += $_.Config.Files.LogDirectory.split("/")[0]
        #Add directories of the vm's virtual disk files
        foreach ($disk in $_.Layout.Disk) {
            foreach ($diskfile in $disk.diskfile){
                $VmDirs += $diskfile.split("/")[0]
            }
        }
        #Only take unique array items
        $VmDirs = $VmDirs | Sort | Get-Unique
 
        foreach ($dir in $VmDirs){
            $ds = Get-Datastore ($dir.split("[")[1]).split("]")[0]
            $dsb = Get-View (($ds | get-view).Browser)
			if (($global:DefaultVIServer).Version -cge "4.1"){$searchSpec = [VMware.Vim.VIConvert]::ToVim41($searchSpec)}
			elseif (($global:DefaultVIServer).Version -eq "4.0.0"){$searchSpec = [VMware.Vim.VIConvert]::ToVim4($searchSpec)}
 
			$searchSpec.details.fileOwnerSpecified = $true
 
			if (($global:DefaultVIServer).Version -cge "4.1"){$dsBrowserMoRef = [VMware.Vim.VIConvert]::ToVim41($dsb.MoRef)}
            elseif (($global:DefaultVIServer).Version -eq "4.0.0"){$dsBrowserMoRef = [VMware.Vim.VIConvert]::ToVim4($dsb.MoRef)}
 
			$taskMoRef  = $dsb.Client.VimService.SearchDatastoreSubFolders_Task($dsBrowserMoRef, $dir, $searchSpec)
            $task = [VMware.Vim.VIConvert]::ToVim($dsb.WaitForTask([VMware.Vim.VIConvert]::ToVim($taskMoRef))) 
 
            foreach ($result in $task){
                foreach ($file in $result.File){
                    $VmSize += $file.FileSize
                }
            }
        }
    }
 
    return $VmSize
}
 
$size = Get-VmSize($vm)
$size = [math]::round($size/1GB,2)
WRITE "$size Gb"

/!\ les fichiers de swap (.vswp) ne sont comptabilisés que s’ils sont dans le répertoire de la VM /!\