PowerCLI: Document the ESX Hostname of the vCenter VM


I was reading Duncan Epping his post: http://www.yellow-bricks.com/2009/10/09/best-practices-running-vcenter-virtual-vsphere/ about Running vCenter virtual. The most of the steps described, you only have to do once but step 5 needs to be documented once in a while

5. Write a procedure to boot the vCenter / AD / DNS / SQL manually in case of a complete power outage occurs.

Nobody likes to document this thing so we will let PowerCLI do this job for us.

First you need to now the VMs. In most cases this will be your Domain Controller, Database Server and of course the vCenter VM.

$vms =  Get-VM "DC01", "DB01", "VC01" | Sort Name
$vms | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, `
@{N="VMHost";E={Get-VMHost -VM $_}} 

The one-liner above will return the VM name, Cluster Name and ESX Host name:


Now you are able to document where your VMs are. But you still need to put this information somewhere. So I created a simple script which will export the information displayed above to a CSV file. The script will also remove files older than 7 days.

You can change the variable if you want.

$now = Get-Date
$days = "7"
$targetFolder = "C:\vCenter"

if (Test-Path $targetFolder)
    Write-Host $targetFolder "Already exists"
    New-Item $targetFolder -type directory
    Write-Host $targetFolder "Created"

$lastWrite = $now.AddDays(-$days)
$files = get-childitem $targetFolder -include *.csv -recurse `
    | Where {$_.LastWriteTime -le "$lastWrite"} 

if (($files | Measure-Object).count -gt 0){
foreach ($file in $files)
{write-host "Deleting File $File" -foregroundcolor "Red"; `
    Remove-Item $file | out-null}

$filename = "C:\vCenter\" + (Get-Date -format  'yyyy-MM-dd hh-mm-ss') + '.csv'
$vms =  Get-VM "DC01", "DB01", "VC01" | Sort Name 
$vms | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, `
@{N="VMHost";E={Get-VMHost -VM $_}} | `
Export-Csv -NoTypeInformation $filename

The script will generate a CSV file:


The CSV file will look like this:





You can schedule this script on a VM that runs on another cluster or maybe better, schedule the script on a physical box. If you want to know how to schedule a Powershell/CLI script, go check out this post from Alan Renouf: http://www.virtu-al.net/2009/07/10/running-a-powercli-scheduled-task/

Now you are able to track the most important VMs in your environment.

PowerCLI: Enable Changed Block Tracking

If you don’t know what Changed Block Tracking is, just read this excellent post from Eric Siebert.

You can check the status of Changed Block Tracking with the following PowerCLI one-liner:

Get-VM | Get-View | `
Sort Name | Select Name, `

The output of the one-liner will look like this:


If you’re running a VM with only one VMDK, you can use the following function to enable Changed Block Tracking:

Function EnableChangeTracking{
    $vmView = Get-VM $vm | Get-View

    if($vmView.Config.Version -eq "vmx-04"){
        Write-Host -ForegroundColor Red `
        "The Virtual Hardware version of this VM does not support Changed Block Tracking"

    $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
    $vmConfigSpec.changeTrackingEnabled = $true

    sleep 3

    Get-VM $vm | New-Snapshot -Name "Temp" 

    sleep 5

    Get-VM $vm | Get-Snapshot | Where {$_.Name -eq "Temp"} | Remove-Snapshot -Confirm:$false

You can run the function via the following command:


I am going to updated the function later, so it will be able to enable Changed Block Tracking on a VM with multiple VMDKs.

Update: When the VM is powered off, you are able to set the Changed Block Tracking feature for all the VMDKs.

Update 2: There was a little chat about this subject on Twitter between @lamw @gabvirtualworld and me (@afokkema) where @gabvirtualworld posted the following tweet:


I can confirm this theory and update my script with this little trick. Now you’re able to enable Changed Block Tracking when your VM is powered on.

PowerCLI: Change Persistence mode (on the fly)


When you have some vmdk’s with the Independent Persistent mode enabled. You might get problems with Storage vMotion (some DMotion errors). I was able to fix this with disabling  the Independent mode and create and remove a snapshot of the VM. But within the vSphere client you’re not able to change the Independent setting of a running VM. With PowerCLI you can!

The first one-liner will return all the vmdk’s with the Independet Persistent mode enabled:

Get-VM | % { Get-HardDisk -VM $_ | Where {$_.Persistence -eq "IndependentPersistent"} }

This is what you see in the console.


Within the vSphere client, you can’t change this setting while the VM is powered on.


But why use the vSphere client when we have PowerCLI ;-). If you run the following one-liner, it will return all the vmdk’s with Independent Persistent mode enabled. The next step is to disable this setting.

Get-VM | % { Get-HardDisk -VM $_ | Where {$_.Persistence -eq "IndependentPersistent"} | `
% {Set-HardDisk -HardDisk $_ -Persistence "Persistent" -Confirm:$false} }

This is the output you’ll see:


When you check the settings within the vSphere client, you’ll notice that the Independent mode is disabled.


PowerCLI: Two Virtual Switch and Portgroup one-liners


In this post you’ll find two Powershell one-liners to do some maintenance on Virtual Switches and PortGroups.

The first one-liner is inspired by Hany Michel his post: vMotion vs. VMotion .. Vote for your favorite! In this post he starts the debate about which name it should be. I voted for the “new” name vMotion. If you want to change the name of the VMotion portgroups to the “new” standard. You can do this by hand but why, we got PowerCLI 😉 The following one-liner will do the job:

Get-VMhost | % { Get-VirtualPortGroup -VMhost $_ -Name VMotion `
| Set-VirtualPortGroup -Name vMotion -Confirm:$false }

The vSwitches with the VMotion Protgroup name will be changed to vMotion:image


The next one-liner will change the number of ports on vSwitch0. The default setting on vSwitch0 is 24 ports.


With PowerCLI you can easily change this again with an one-liner. This one-liner will change the value to 120 ports:

Get-VMHost | % {Get-VirtualSwitch -VMHost $_ -Name vSwitch0 | `
where {$_.NumPorts -lt "128"}} | `
% { Set-VirtualSwitch -VirtualSwitch $_ -NumPorts "128" }

You’ll see the following output:


You need to reboot the ESX host to apply the new setting.

PowerCLI: One-Liner to get VMs, Clusters, ESX Hosts and Datastores


With the one-liner below, you’re able to create an overview of your VM’s, Clusters, ESX Hosts and Datastores.

Get-VM | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, `
@{N="ESX Host";E={Get-VMHost -VM $_}}, `
@{N="Datastore";E={Get-Datastore -VM $_}} 

The following output will be generated:


If you add an extra line with the export-csv cmdlet, you can export the output to a CSV file.

Get-VM | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, `
@{N="ESX Host";E={Get-VMHost -VM $_}}, `
@{N="Datastore";E={Get-Datastore -VM $_}} | `
Export-Csv -NoTypeInformation C:\Scripts\VM_CLuster_Host_Datastore.csv 

If you want, you can import the CSV file into Excel. Excel has some basic filtering options, so you’re able to filter on ESX Host, Cluster etc.


PowerCLI: Check CPU/Memory Hot Add


In my previous post I created a couple of functions to enable or disable the Hot Add features.  To check these settings, you can run this one-liner:

Get-VM | Get-View | Select Name, `
@{N="CpuHotAddEnabled";E={$_.Config.CpuHotAddEnabled}}, `
@{N="CpuHotRemoveEnabled";E={$_.Config.CpuHotRemoveEnabled}}, `

The following output will be generated:


Powershell: Using SCHTASKS in Powershell


In this post you will see how powerful powershell is in combination with external applications like SCHTASKS.exe.

First you have to create a CSV file like this:


The following one-liner imports the CSV file and creates a task on every server which is saved in the CSV file:

# Create a scheduled task on all the servers in *.csv
import-csv ".\*.csv" | % { schtasks /create 
/S $_.Name /SC DAILY /TN "Task_Name" 
/TR "program_or_script" /ST time /RU account}

The next one-liner imports the CSV file and will modify a scheduled task on every server which is saved in the CSV file:

# Change a scheduled task on all the servers in *.csv
import-csv ".\*.csv" | % { schtasks /change 
/TN "Task_Name" /S $_.Name 
/TR "program_or_script" /ST 23:05 /RU System }

The last one-liner imports the CSV file and will delete a scheduled task on every server which is saved in the CSV file:

# Delete a scheduled task on all the servers in *.csv
import-csv ".\*.csv" | % { schtasks /delete 
/tn "Task_Name" /f /s $_.Name }

More info about how to use SCHTASKS.exe can be found here: KB814596