With a lot of VMs using Thin Provisioning ive been working with service desk users to find a quick way of them figuring out which Datastore they should deploy VMs to while ensuring they dont over-allocate. I know over-allocation is a big perk of thin provisioning but regardless were working towards ensuring that we dont
This is a fairly straightforward couple of one liners that use my usual variables (i will list them below). $global:DCChoice – DC Choice $global:CLUChoice – Cluster Choice You can add or remove these variables as required #Run a VUM compliance checkGet-Datacenter $global:DCChoice | Get-Cluster $global:CLUChoice | Scan-Inventory #Check VUM Compliance resultsGet-Datacenter $global:DCChoice | Get-Cluster $global:CLUChoice
The function “VP-HostCDPInfo” will list all hosts in cluster $Global:CLUChoice from DC $Global:DCChoice, you can then select a host and list its CDP information for each NIC Get host CDP Informationfunction VP-HostCDPInfo { $hosts = Get-datacenter $Global:DCChoice | Get-Cluster $Global:CLUChoice | get-vmhost Write-Host “================ Select host ================” $i = 1 $hosts | ForEach-Object -Process {
For some time now I’ve wanted to put together a PowerCLI menu system, just to make running common commands a little faster. Let’s start with vCenter, unfortunately, this is the only part that hardcoded so you’re going to need to amend this to include your vCenters FQDN ###############################File Location ############################### $scriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path
All the commands below reference variables created from my menu system post, obviously if you are not using that menu you will need to change them to work with your environment.These are just some of the commands i used recently on an audit: To Export to CSV simply append the following to the end of
As with everything in IT, having things standardized generally makes your life easier. Unfortunately in many environments, snapshots tend to get overlooked and their naming convention can end up a little adhoc which can lead to confusion around who and why they were taken. Ive put together the following script which takes a snapshot with
This function pulls a list of hosts from your vCenter that are currently in maintenance mode and moves them into your previous selected cluster. Again this uses my usual variables, specifically: VP-MoveHostCluster – Function Name $Global:DCChoice – DC Choice$Global:CLUChoice – Cluster Choice function VP-MoveHostCluster { $hosts = Get-datacenter $Global:DCChoice | get-vmhost | Where {$_.ConnectionState -eq
get-vm | get-snapshot | select vm, name, description, created, sizegb | export-csv -path “c:\temp\file.csv” -notypeinformation
This week i had been tasked with collecting lists of VMs that are tagged within certain vSphere tag categories and then compiling lists of their metrics so that service group owners can identify resource demand during testing. This information would also be useful if rightsizing your environment or planning new infrastructure. I used the following
Occasionally you can run into the situation where you need to leave a host down for an extended period of time and the business is happy to sign off on a loss of storage redundancy while any work is completed. In a vSAN environment without further action this could lead to a significant number of
