Nous avons ajouté la taille de la VM pour vous motiver à faire un VeeamZIP et à en finir définitivement avec ces VM qui risque d’être redémarrées après un crash d’ESX…

get-view -viewtype virtualmachine -property name,runtime,layoutex|?{$_.Runtime.PowerState -eq "poweredOff" -and $_.Runtime.ConnectionState -eq "connected" -and !$_.config.template}|?{$_.LayoutEx.File|?{$_.type -match "nvram"}}|%{$_|select Name, @{n="Modification";e={((get-view (get-view -viewtype datastore –filter @{"Name"=($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("[]")[1]}).browser).SearchDatastore(($_.LayoutEx.File|?{$_.type -eq "nvram"}).name.split("/")[0],(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -property @{matchPattern=("*.nvram"); details=(New-Object VMware.Vim.FileQueryFlags -property @{modification=$true})}))|%{$_.file}).Modification}}, @{n="SizeGB";e={[math]::round(($_.LayoutEx.File|measure -Property size -sum).sum/1GB,1)}}}

Et voici le oneliner PowerCLI pour le faire vite et bien :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected" -and $_.config.product.ProductLineId -eq "embeddedEsx" -and ($_.Config.Option|?{$_.Key -eq "Misc.SIOControlLogLevel"}).Value -ne "1"}|%{(Get-View $_.ConfigManager.AdvancedOption).UpdateOptions((New-Object VMware.Vim.OptionValue -Property @{Key="Misc.SIOControlLogLevel";Value=[Int64]1}))}

En effet, après avoir activé l’autoExpand, le nombre de ports utilisables d’un DVPortgroup (en Static binding aka earlyBinding) se verra incrémenté automatiquement de 10 lorsqu’aucun port n’est disponible pour une nouvelle VM. Il y a également une fonction d’autoShrink décrite dans l’API Reference mais c’est une peu vague :

When this property is set to true, the portgroup becomes a potential candidate for auto-shrink. Once the portgroup has auto-expanded then its disconnected ports are likely to be deleted automatically, as a part of auto-shrink step, if there are more than certain number of free ports. If the portgroup never auto-expanded, then it will never lose any free ports.

Sachant que cette fonction est activé par défaut sur les DVSwitch 5.1, nous avons voulu vérifier si c’était également le cas lors d’une migration :

On constate donc que même après avoir upgradé le DVSwitch 5.0.0 en 5.1.0, l’autoExpand est toujours désactivé. Mais pas pour longtemps

Après analyse du script PowerCLI d’Arne et de l’API Reference, nous avons constaté que les DVUplinks “disposaient” de cette fonctionnalité (désactivée dans tous les cas et à ne probablement pas activer) car comme nous le confirme Steve Jin, ce ne sont que des DVPortgroup avec un tag spécifique (SYSTEM/DVS.UPLINKPG). De plus, lors de la reconfiguration du DVPortgroup, la propriété configVersion devrait être incrémentée. Et pour finir, en onliner c’est plus sexy :

Get-View -ViewType DistributedVirtualPortgroup|?{!($_.Tag|?{$_.Key -eq "SYSTEM/DVS.UPLINKPG"}) -and !$_.Config.autoExpand}|%{$_.ReconfigureDVPortgroup_Task((New-Object VMware.Vim.DVPortgroupConfigSpec -Property @{autoExpand="True";ConfigVersion=[int32]$_.Config.ConfigVersion+1}))}

Le script n’active la fonctionnalité que sur les DVPortgroup ne l’ayant pas déjà (hors DVUplinks) et incrémente la propriété ConfigVersion de 1 :

Et pour ceux qui voudraient savoir quand de nouveaux ports ont été ajoutés ou supprimés, il y a une alarme pour ça (Monitor : vSphere Distributed Swiches) :

]]> http://www.hypervisor.fr/?feed=rss2&p=4633 3 http://www.hypervisor.fr/?p=4484 http://www.hypervisor.fr/?p=4484#comments Thu, 13 Dec 2012 07:12:17 +0000 NiTRo http://www.hypervisor.fr/?p=4484 MAJ 23.05.2013 : Et voici un cas d’usage réel en production.

Tous ceux qui ont eu à affronter un manque d’espace critique sur un zpool se sont au moins une fois posé la question suivante : Pourquoi ZFS n’est il pas capable de supprimer automatiquement les plus anciens snapshot pour libérer de l’espace en cas de besoin ?

La réponse est évidement parce que ce n’est pas (encore) intégré à ZFS mais peut être que le futur principe de “feature flags” (qui remplacera la fameuse “version” de ZFS) facilitera la naissance de cette fonctionnalité tant espérée. En attendant, il y a toujours la bonne vielle crontab toujours très pratique et si on pimente à la sauce oneliner, ça donne quelque chose d’un peu trash mais fonctionnel :

for zpool in `zpool list -H -o name,capacity | sed "s/%//g" | awk '{ if ( $2 > 80 ) { print $1; } }'`; do zfs list -H -o name -t snapshot | grep -E "^$zpool" | head -n $[$(zfs list -H -o name -t snapshot | grep -E "^$zpool"|wc -l) / 5 + 1]  | xargs -n1 zfs destroy -R ; done

Ce oneliner détruira récursivement 25% des plus vieux snapshots (+1 pour éviter les cas ou 25% feraient moins d’1 snapshot) d’un zpool si le remplissage dépasse les 80%.

Voici une démo de ce script sur un zpool soumis à remplissage perpétuel (dd en boucle + snapshot toutes les minutes) :

Observations du graphique : jusqu’à 10h nous avons programmé le script toutes les minutes, puis toutes les 5min jusqu’à 15h30, puis nous l’avons désactivé et le zpool sature presque immédiatement après.

Voici l’extrait de la crontab de notre nexenta de test :

* * * * * for zpool in `zpool list -H -o name,capacity | sed "s/\%//g" | awk '{ if ( \$2 > 80 ) { print \$1; } }'`; do zfs list -H -o name -t snapshot | grep -E "^$zpool" | head -n $[$(zfs list -H -o name -t snapshot | grep -E "^$zpool"|wc -l) / 5 + 1]  | xargs -n1 zfs destroy -R ; done

Et bien nous en a pris car cet indice nous a permis de découvrir (1 an plus tard…) que la cmdlet Get-EsxCli de PowerCLI 5+ ne nécessite pas de connections direct aux ESX (mais uniquement avec un vCenter 5+ comme en témoigne le changelog) :

Added vCenter Server support for Get-EsxCli. (requires vCenter Server 5.0 or later)

Vous pouvez donc facilement vérifier l’état du paramètre UNMAP…

Get-VMHost|select Name, @{n="UNMAP";e={$(($_|Get-EsxCli).system.settings.advanced.list("/VMFS3/EnableBlockDelete")).IntValue}}

… Ou afficher la liste des claimrule (pratique pour masquer un path)…

Get-VMHost|%{" ";write-host -background white -foreground red $_.Name;($_|Get-EsxCli).storage.core.claimrule.list()|ft *}

… Ou encore modifier le paramètre “IOOperationLimit” des LUN configurées en roundrobin :

ForEach ($VMHost in Get-VMHost){" ";write-host -background white -foreground red $VMHost.Name;($VMHost|Get-EsxCli).storage.nmp.device.list()|?{$_.PathSelectionPolicy -match "VMW_PSP_RR"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.get($_.device)}}

ForEach ($VMHost in Get-VMHost){" ";write-host -background white -foreground red $VMHost.Name;($VMHost|Get-EsxCli).storage.nmp.device.list()|?{$_.PathSelectionPolicy -match "VMW_PSP_RR"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.get($_.device)}|?{$_.IOOperationLimit -ne 1 -and $_.LimitType -ne "iops"}|%{($VMHost|Get-EsxCli).storage.nmp.psp.roundrobin.deviceconfig.set($null,$_.device,"1","iops",$null)}}

Moralité : RTFChangelog

Nous vous proposions il y a quelques temps un script qui stop les jobs en cours sur un serveur veeam backup, aujourd’hui nous allons plus loin dans la démarche avec 2 fichiers xml correspondant à 2 export de tache planifiée pour Windows 2008 R2 contenant les commandes. Le fichier StopActiveVBRJobs.xml va vous permettre de créer une tache planifiée qui arrêtera les jobs veeam en cours à 7h du matin, les jours de semaine, et le fichier RetryFailedVBRJobs.xml automatisera le retry des jobs arrêtés ”manuellement” à 21h, les mêmes jours.

Nous vous proposons également une tache planifiée qui automatise l’export des jobs veeam backup sur un partage CIFS (\\server\share\ à ajuster) et un autre qui permet d’exporter régulièrement (en xml) la liste des points de restauration possibles pour chaque vm de chaque job.

Voici maintenant un oneliner pour un usage très particulier, celui de trouver (replacez le get-item par remove-item pour supprimer) les fichiers veeam backup orphelins dans les répertoires cibles des jobs (cela peut arriver en cas de reboot violent du serveur veeam ou indisponibilité du repository pendant un backup).

v5 :

Compare-Object (Get-VBRJob|%{$_.Info.TargetDir|%{Get-ChildItem $_|%{$_.FullName}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

v6 :

Compare-Object (Get-VBRJob|%{$_.Info|%{Get-ChildItem "$($_.TargetDir)\$($_.Path)"|%{$_.FullName|?{$_ -match ".vrb|.vbk|.vib"}}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

On continue avec un autre oneliner qui permet d’afficher la liste des vm dont la date du dernier backup veeam (si vous avez activé la fonction qui rempli l’un des custom fields, “veeam” dans notre exemple) est supérieure à 21 jours, que vous pouvez utiliser dans un script pour vous envoyez un mail périodiquement par exemple.

Get-View -Viewtype virtualmachine|select name,@{n="backup";e={[Regex]::Match(($_.value|?{$_.key -eq ((get-view (Get-View ServiceINstance).content.CustomFieldsManager).field|?{$_.name -match "veeam"}).key}).value, "([0-9]{1,2}/){2,2}201[0-9]{1,1}[ ]*([0-9]{1,2}:?){3,3}").Value}},@{n="pool";e={(get-view $_.ResourcePool).name}}|?{$_.backup}|?{([datetime]::ParseExact(($_.backup), "dd/MM/yyyy HH:mm:ss", (New-Object System.Globalization.CultureInfo("fr-FR")))) -le (get-date).AddDays(-21)}

Et pour finir, un oneliner qui nous a prit un peu de temps (à cause du comportement bizarre du -ExpandProperty de la cmdlet Select-Object) qui vous permet de lister les vm présentent dans plusieurs jobs de backup.

Get-VBRBackup|select jobname,@{n="vm";e={$_.GetObjectOibsAll()|%{@($_.name,"")}}}|select jobname -ExpandProperty vm|select @{n="vmname";e={$_}}, @{n="jobname";e={$_.jobname}}|?{$_.vmname}|Group-Object -Property vmname|?{$_.Count -gt 1}|select name, @{n="jobs";e={$_.group|%{$_.JobName}}}

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…

When making changes to the networks that your clustered ESX/ESXi hosts are on, VMware recommends that you suspend the Host Monitoring feature.

Nous vous recommandons pour cela notre petit OneLiner PowerCLI maison :

Get-View -ViewType ClusterComputeResource|%{$_.ReconfigureComputeResource_Task((New-Object VMware.Vim.ClusterConfigSpecEx -Property @{DasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -Property @{HostMonitoring="disabled"})}), $true)}

Vous trouverez facilement la commande inverse

MAJ 23/04/2012 : modification du script pour filtrer les vm ayant déjà le bon paramétrage.

Comme l’indique cette kb, à partir d’ESX 4.1 le copier/coller via la console vmrc est désactivé pour des raisons de sécurité :

Starting with vSphere 4.1, the Copy and Paste options are, by default, disabled for security reasons.

Note: This functionality was enabled by default in earlier releases of vSphere.

Pour le réactiver en GUI il faut impérativement arrêter la VM ce qui est évidement inacceptable. En PowerCLI c’est très facile mais en OneLiner, grâce au concours de notre cher vmDude, c’est nettement plus fun :

Get-View -ViewType VirtualMachine|?{$_.runtime.ConnectionState -eq "connected"}|?{-not $_.Config.Template}|?{!($_.Config.ExtraConfig|?{$_.key -match "isolation.tools.paste.disable" -or $_.key -match "isolation.tools.copy.disable"}) -or ($_.Config.ExtraConfig|?{($_.key -match "isolation.tools.copy.disable" -and $_.value -ne "false") -or ($_.key-match "isolation.tools.paste.disable" -and $_.value -ne "false")})}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="isolation.tools.copy.disable";Value="$false"});(New-Object VMware.Vim.optionvalue -Property @{Key="isolation.tools.paste.disable";Value="$false"}))}))}

Cette commande agira d’un coup sur toutes les vm pour les fonctions “copier” et “coller”, il ne vous restera plus qu’à utiliser notre autre OneLiner Shake My VM pour effectuer un vmotion afin d’appliquer les modifications, ou d’attendre que DRS fasse le travail pour vous…

get-vm|?{$_.PowerState -eq "PoweredOn"}|%{move-vm -vm $_ -destination (get-random @((($vmhost = $_.Vmhost).Parent|get-view).host|%{get-view $_}|?{$_.Runtime.ConnectionState -eq "connected" -and !$_.Runtime.InMaintenanceMode -and $_.Runtime.StandbyMode -eq "none" -and $_.name -cne $vmhost.name})).name -whatif}

Pour être un peu plus précis, ce script va faire un vmotion sur un des autres ESX disponibles du cluster parent. OneLiner oblige, ce script ne tient pas compte des vm qui seraient déplacées par DRS avant son passage. Il est par contre nécessaire d’avoir un minimum de “mou” sur le cluster en question pour éviter une vilaine contention.

Dans l’état, le script vous affichera la liste des vmotion, il suffit d’ôter le “-whatif” et relancer pour agiter la pulpe

Insufficient video RAM. The maximum resolution of the virtual machine will be limited to 1176×885. To use the configured maximum resolution of 2560×1600, increase the amount of video RAM allocated to this virtual machine by setting svga.vramSize=”16384000″ in the virtual machine’s configuration file

Get-VM|?{($_.ExtensionData.Config.Hardware.Device|?{$_.GetType().Name -eq "VirtualMachineVideoCard"}).useAutoDetect -eq $false}|%{($_|Get-View).ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{DeviceChange=(New-Object VMware.Vim.VirtualDeviceConfigSpec -Property @{Operation="edit";Device=(New-Object VMware.Vim.VirtualMachineVideoCard -Property @{UseAutoDetect="$true";Key=(($_.ExtensionData.Config.Hardware.Device|?{$_.GetType().Name -eq "VirtualMachineVideoCard"}).key)})})}))}

Et vous pouvez l’exécuter 10x de suite, elle n’agira que sur les VM qui ne sont pas en auto

MAJ 01/06/2011 : Rajout du filtre “MultipleHostAccess” pour éviter l’activation de SIOC sur du DAS

Si vous devez activer Storage I/O Control (aka IORM) sur les datastores d’un cluster, vous ne sauriez opérer autrement qu’avec un bon script ou mieux, avec un petit oneliner bien mijoté (et comme souvent, inspiré d’un post de Luc) :

Get-VMHost -location "MonBeauCluster"|Get-Datastore|Get-View|?{$_.Summary.Accessible -eq $true -and $_.Capability.StorageIORMSupported -and $_.Summary.MultipleHostAccess -and $_.IormConfiguration.Enabled -ne $true}|%{(Get-View (Get-View ServiceInstance).Content.StorageResourceManager).ConfigureDatastoreIORM_Task($_.MoRef,(New-Object VMware.Vim.StorageIORMConfigSpec -Property @{enabled="1";congestionThreshold="25"}))}

La valeur par défaut de la variable congestionThreshold est “30″ mais peut être tuné en fonction de la nature du stockage (fixée à “25″ dans notre oneliner), comme détaillé dans le pdf linké en début de post.

Et pour ceux que ça intéresse, la kb Troubleshooting Storage I/O Control précise quelques points importants (ainsi que le la façon d’obtenir les logs de SIOC) :

• Before enabling SIOC, ensure that datastores are managed by a single vCenter Server.
• [...] if the number of hosts connected to the datastore has changed since enabling SIOC [...]

Et pour ceux qui veulent savoir comment ça marche, direction les sessions Technology and Architecture du vmworld 2010 : Prioritizing Storage Resource Allocation in ESX Based Virtual Environments Using Storage I/O Control

Get-View -ViewType ResourcePool|?{$_.name -match "qualif"}|?{$_.Vm.count -gt 0}|%{(Get-View $_.vm)|?{$_.Config.SwapPlacement -ne "vmDirectory"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{SwapPlacement="vmDirectory"}))}}

Dans notre cas, pour économiser l’espace disque sur notre SAN, les fichiers .vswp sont redirigés sur les disques locaux des ESX mais la consolidation allant bon train nous nous sommes retrouvés dans une situation où l’espace disque local n’est plus suffisant. Les VM membres des resource pool de qualif/test/dev étant stockées sur des partages NFS, nous avons pris la décision de bypasser la politique pour ces dernières et de laisser le fichier dans le répertoire de la vm.

Par contre, n’oubliez pas que sur du stockage “thin provisioné” l’espace du fichier de swap n’étant pas reservé, l’admition control est faussé. Mais j’espère pour vous que n’en êtes pas au point de remplir les fichiers swap de vos VM (même si un jour cela pourrai devenir une option grâce aux SSD)

C’est encore PowerCLI qui vient à notre secours pour un script d’export/import de ces informations vers un fichier xml pour une manipulation plus facile.

Sans arguments, le script exportera l’ensemble des Custom Fields et Annotation de toutes les vm (ou d’une en particulier grâce au paramètre -VmAlone)  dans un fichier “VmFieldList.xml” dans le répertoire courant (ou à l’emplacement de votre choix grâce au parametre -$XmlPath) ; si le fichier existe déjà, il sera renommé suivant la nomenclature VmFieldList-yyyyMMddHHmmss.xml. Le fichier généré ressemble à cela :

Pour restaurer les infos d’une VM, voici la syntaxe :

IOCustomField.ps1 -VmAlone RSW2K8VPX51 -Action import -Confirm 1

Pour restaurer toute ou une partie des vm, il suffit de passer au script le nom de la vm dans une boucle :

Get-Cluster "CLU01"|Get-VM|%{.\IOCustomField.ps1 -VmAlone $_.name -Action import -Confirm 1 -XmlPath .\VmFieldList.xml}

download

En bonus, un petit OneLiner pour exporter vos Host Profiles en fichiers .prf du même nom :

Get-VMHostProfile|%{Export-VMHostProfile -FilePath "$($_.name).vpf" -Profile $_ -Force}

(get-datastore datastore).extensiondata.host|%{(get-view (get-view $_.key).ConfigManager.DatastoreSystem).RemoveDatastore((get-datastore datastore).extensiondata.moref)}

Voici un petit oneliner qui démontera le datastore désigné de tous les ESX sur lesquels il était monté :

(Get-Datastore datastore|get-view).host|%{(get-view (get-view $_.key).ConfigManager.DatastoreSystem).RemoveDatastore((Get-Datastore datastore|get-view).moref)}

A grande échelle c’est pratique !

get-vmhost -location "mon_beau_cluster"|get-view|select name,@{N="WWN";E={get-view $_.ConfigManager.StorageSystem|%{$_.StorageDeviceInfo.HostBusAdapter|?{$_ -is [VMware.Vim.HostFibreChannelHba]}}|select @{N="WWN";E={"{0:x}" -f $_.PortWorldWideName}}}}|select name -ExpandProperty WWN|select name, @{N="WWN";E={$_.WWN.substring(0,2)+":"+$_.WWN.substring(2,2)+":"+$_.WWN.substring(4,2)+":"+$_.WWN.substring(6,2)+":"+$_.WWN.substring(8,2)+":"+$_.WWN.substring(10,2)+":"+$_.WWN.substring(12,2)+":"+$_.WWN.substring(14,2)}}|sort name

PS : Et nous on pense que les “:” c’est important

$ds = get-datastore "NexentaStor";compare ($ds|?{$_.Accessible -eq "true"}|Get-HardDisk) (Get-View -ViewType VirtualMachine|?{$_.datastore -match $ds.id}|?{$_.Summary.Runtime.ConnectionState -eq "Connected"}|%{$_.Layout}|%{$_.Disk}|%{$_.DiskFile}|select @{N="filename";E={$_}}) -property filename|ft -AutoSize

Encore un petit oneliner PowerShell/PowerCLI à partager : trouver les vmdk orphelins sur vos datastore, y compris les snapshots.

compare (Get-Datastore|?{$_.Accessible -eq "true"}|Get-HardDisk) (Get-View -ViewType VirtualMachine|?{$_.Summary.Runtime.ConnectionState -eq "Connected"}|%{$_.Layout}|%{$_.Disk}|%{$_.DiskFile}|select @{N="filename";E={$_}}) -property filename|ft -AutoSize

Résultat :

Le “SideIndicator” vous permet de savoir de quel “coté” le vmdk est manquant. Si c’est vers la droite (en jaune), c’est un vmdk qui n’existe plus sur le datastore mais encore dans le vcenter et si c’est vers la gauche (en rouge) c’est un vmdk qui n’appartient à aucune vm du vcenter.

Pour les vmx, nous vous recommandons le célèbre Raiders of the Lost VMX de LucD.

$delta="5";get-view -viewtype "hostsystem"|?{$_.Runtime.ConnectionState -eq "Connected" -or $_.Runtime.ConnectionState -eq "Maintenance"}|%{$esx=$_.name;$_.ConfigManager.NetworkSystem|%{get-view $_}|%{$_.NetworkInfo}|%{$_.pnic}|%{$vmnic = $_.device;$_|select @{N="ESX";E={$esx}},@{N="vmnic";E={$_.device}},@{N="Speed";E={$_.linkspeed.SpeedMb}},@{N="Inbound";E={[math]::round((get-vmhost $esx|get-stat -Stat net.received.average -Realtime|?{$_.Timestamp -gt (get-date).addminutes(-$delta)}|?{$_.instance -eq $vmnic}|Measure-Object -Property Value -Average).average,0)}},@{N="Outbound";E={[math]::round((get-vmhost $esx|get-stat -Stat net.transmitted.average -Realtime|?{$_.Timestamp -gt (get-date).addminutes(-$delta)}|?{$_.instance -eq $vmnic}|Measure-Object -Property Value -Average).average,0)}}}}|ft -AutoSize

Et voila le résultat :

Spécial cassedédie à papycloud

Get-Template "template" |Set-Template -tovm
(Get-View -ViewType VirtualMachine -Filter @{"Name" = "template" }).MarkAsTemplate()

Ces 2 commandes permettent de changer un template en vm, puis de changer cette vm en template à nouveau. Cela permet d’éviter la GUI et ses questions inutiles…

get-vm -name VM1,VM2,VM3 |New-Snapshot -name "snapshot" -description "tralala"

Cette commande toute simple, permet de faire un snapshot massif sur plusieurs VM simultanément.

get-vm -location "cluster" |select name, @{N="store";E={(get-datastore -vm $_)}} |where {$_.store -match "datastore1|datastore2"}

Cette commande permet de lister les vm d’un cluster ayant un vmdk,vmx ou iso sur le datastore1 ou datastore2.

get-template "template"|Get-HardDisk

Cette commande simplissime permet tout simplement des lister les vmdk d’un template sans le changer en vm.

Get-VMHost -location "cluster" |Get-View | %{$_.ReconfigureHostForDAS_Task()}

Cette commande exécute la tache “Reconfigure for VMware HA” sur les membres du cluster.

((Get-VMHost |Get-View |select name, @{N="socket";E={$_.Hardware.CpuInfo.NumCpuPackages }} ) | Measure-Object socket -Sum).sum

Cette commande vous permet de remonter le nombre de socket contenu dans votre VC, pratique pour les licences…