Find VM’s with Snapshots using VMware PowerCLI

After all the hassle I’ve had with snapshots recently it was time to finalise this script. It’ll find all of the snapshots in your environment, based on age, and then e-mails a nice list to you.


param ($Age = 0)
$outfile = "c:\snaps.csv"
$output="VM Name,Snapshot Name,Snapshot Size,Creation Date"+"`n"+"`n"
$vcenter = "servername"

Connect-VIServer $vcenter

$snapshotlist = get-snapshot -VM (get-vm)
Write-Host -ForegroundColor Red "Matching Snapshots Found: "

foreach ($snap in $snapshotlist) {
     if ($snap.Created -lt (Get-Date).AddDays(-$Age)) {
          Write-Host "VM: " $snap.VM "Name: " $snap.Name "Size: " $snap.SizeMB "Created: " $snap.created
          $output = $output + $snap.VM + "," + $snap.Name + "," + $snap.SizeMB + "," + $snap.created + "`n"
          }
     }

disconnect-viserver * -force:$true -confirm:$false

Out-file $output $outfile

#Sets the mail values
$FromAddress = &quot;<;a href=&quot;mailto:Snapshots@domain.com&quot;>;snapshots@domain.com<;/a>;&quot;
$ToAddress = &quot;<;a href=&quot;mailto:recipient@domain.com&quot;>;recipient@domain.com<;/a>;&quot;
$MessageSubject = &quot;Snapshot Report&quot;
$SendingServer = &quot;mail_relay.domain.com&quot;
$MessageBody = $output

#Create the mail message
$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress, $MessageSubject, $MessageBody

#Send the message
$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer
$SMTPClient.Send($SMTPMessage)

Modify these settings as required for your environment/needs:

$FromAddress = “snapshots@domain.com”
$ToAddress = “recipient@domain.com”
$MessageSubject = “Snapshot Report”
$SendingServer = “mail_relay.domain.com”
$outfile = “c:\snaps.csv”
$vcenter = “servername”

By default, the script will collect info about all snapshots. If you want to modify that list, and only have snapshots created more than 7 days ago, just call the script with the “-age” parameter, and you’ll only get a list of VM’s that have been around for longer than that time.

VMware Snapshots Fail with: “File is larger than the maximum size supported for the datastore”

Full Error:

File <unspecified filename> is larger than the maximum size supported by datastore ‘<unspecified datastore>

I’ve been coming up against this issue for the last few days whilst installing some backup software for one of our customers. It’s highly frustrating and I couldn’t figure out why this was even happening. The data stores that this particular VM was running on had plenty of free disk space, and none of the disks exceeded the file size maximum for the block size on those disks.

What I didn’t know was, quite simply, that a VM cannot snapshot if it’s configuration file is stored on a data store with a smaller block size than one of it’s virtual hard disks. Now, I presume, that this is only the case if the virtual disk size is larger than the supported size of a file on the configuration files data store.

So, if you come accross this problem, just storage vMotion the configuration file to a data store with a larger block size, or at least to a datastore with the same size block size as your largest virtual disks’ data store. Run another snapshot, and “Hey Presto!” it should snapshot correctly.

Onswipe added to Spug.co.uk

Just a quick update for all you iPad users out there, I’ve now added OnSwipe to spug.co.uk which makes browsing the site via iPad a heck of a lot easier – and it looks good too!

For anyone who has an iPad and wants to take a look, just head to the main http://www.spug.co.uk page, and you’ll see the OnSwipe version of the site.

vSphere5 goes GA!!

At last! After being announced last month, vSphere5 has finally gone GA! Available to download from late last night (UK time) the latest release of VMware’s Datacentre hypervisor comes with over 140 new features, and improves on the existing features from vSphere4.

If you already own vSphere 4 and have a current support agreement, then your licenses will be available to upgrade by the end of the week. Given that a lot of people will probably wait a couple of months before upgrading any production systems, I don’t see this being a problem for most people, and there’s the usual evaluation period in the mean time anyway.

I’ve downloaded my copy, have you got yours? If not, head over here:

http://downloads.vmware.com/d/info/datacenter_cloud_infrastructure/vmware_vsphere/5_0

New Function: Get VM’s by Powerstate using VMware PowerCLI

Another ususal issue I keep finding is the need to see how many VM’s I have that are either Powered On, Powered Off or Suspended. Today I decided it was time to do two things:

1. Write a script for this so I don’t have to work this out “the hard way”.
2. Make it a function with parameters so that it has help information included for other people and can be modular. This was mainly due to Jonathan Medd and his talk at the last LonVMUG.

So, I decided I needed options to limit the scope of the script. Cluster level seemed like a good start to me, and I also added an option to connect to a particular host/vCenter instance (assumes you are running Powershell as a user with sufficient access permissions).

So, I came up with a script. Then made it into a function. And then fixed it after I broke it! I also realised that outputting large lists of VM’s went over the PowerShell console history length if you had enough VM’s listed, so I added an output to file option to relieve this issue.

If you want to be able to get a list of all VM’s dependant on their current power state, take a copy of this script, save it as a “.psm1” file and import is as a module (import-module). This way you can just run Get-VMByPowerState and you’ll get a full list.

Here’s the function:

function Get-VMByPowerState
{
<#
    .SYNOPSIS
        Gets a list of VM's dependant on power state.
    .DESCRIPTION
        Gets a list of VM's dependant on power state.
    .PARAMETER Cluster
        Name of the cluster to retrieve VM's from. Supports Wildcards.
    .PARAMETER PowerState
        REQUIRED. The power state of the VM's that you are looking for.
		Valid state options are:
			PoweredOn
			PoweredOff
			Suspended
	.PARAMETER Server
		The name or IP of the vCenter or ESX(i) host to connect to. This assumes that you have sufficient access rights as the logged on user.
	.PARAMETER Outfile
		Name & path to an output file.
    .EXAMPLE
        Get-PowerState -Cluster ClusterName -State PoweredOn -Server 127.0.0.1 -outfile filename.txt
    #>
[CmdletBinding(defaultparametersetname='ByName')]
    param(
        [Parameter(Mandatory=$False
        ,   Position = 0
        ,   ParameterSetName='ByName')]
        [Alias("ClusterName")]
        [string]
        $Cluster = '*'
    ,
        [Parameter(Mandatory=$true
        ,   ParameterSetName='ByDatacenter')]
		[Alias("PowerStateEntry")]
        [string]
        $PowerState
	,	
		[Parameter(Mandatory=$false
        ,   ParameterSetName='ByDatacenter')]
		[Alias("vCenterHost")]
        [string]
        $Server = $null
	,	
		[Parameter(Mandatory=$false
        ,   ParameterSetName='ByDatacenter')]
		[Alias("Output File Name")]
        $outfile = $null
    )
Process
   {

if ($server -ne $null) {
	connect-viserver $server
	clear-host
	}

$vms = get-vm | where {$_.PowerState -eq $PowerState} | select Name,PowerState

$vmcount = $vms.count

if ($vmcount -gt "0"){
	if ($outfile -eq $null) {
		""
		write-host "List of all $PowerState VM's:"
		$vms
		""
		write-host "There are $vmcount $PowerState VM's"
	}
	if ($outfile -ne $null){
		""
		write-host "Outputting to file as requested."
		out-file -FilePath $outfile -InputObject $vms}
		}
if ($server -ne $null) {
	disconnect-viserver $server -force:$true -confirm:$false
	}
}
}

Finding the VMware datastore with the most diskspace using PowerCLI

Today I found that I needed to know which of my datastores had the most disk space so that I could add a new virtual hard disk on it temporarily for some temporary data upload. Knowing that I needed to exclude certain datastores I had to figure out how to get PowerCLI/PowerShell to check the name of the datastore against an “exclusion list”. So, with some help from @jonhtyler and @leveitan on Twitter, and using the PowerShell operators, I came up with the following script:

#Connects to vCenter/ESX(i)
connect-viserver $servername 

#Get's a list of datastores and excludes based on matches of "Name1" etc. Only gets free space and datastore Name
$datastores = get-datastore | where {$_.Name -notmatch "Name1|Name2|Name3"} | select Name,FreeSpaceMB

#Sets some static info
$LargestFreeSpace = "0"
$LargestDatastore = $null

#Performs the calculation of which datastore has most free space
foreach ($datastore in $datastores) {
	if ($Datastore.FreeSpaceMB -gt $LargestFreeSpace) {	
			$LargestFreeSpace = $Datastore.FreeSpaceMB
			$LargestDatastore = $Datastore.name
			}
		}

#Writes out the result to the PowerShell Console		
write-host "$LargestDatastore is the largest store with $LargestFreeSpace MB Free"

#Disconnects from all connected vCenter/ESX(i) hosts.
disconnect-viserver * -force:$true -confirm:$false

Now, all you need to do is replace $servername with the name of your vCenter server or ESX(i) host, and change “Name1”, “Name2” and “Name3” with the expressions that you want to remove. If you know that all of the disks you want to exclude contain a single word such as “LOCAL”, then just replace all 3 (and remove the all the “|”), if you want to exlude “LOCAL” and “TEMP” then you’ll need “LOCAL|TEMP” – with me?

Hope this helps more people than just me 🙂

Well Done VMware – vSphere 5 licensing model adjusted!

Today VMware announced that there were going to be changes made to the new licensing model that was announced for the latest edition of their Hypervisor platform, vSphere 5.

All editions of vSphere 5 are to have larger vRAM entitlements than originally stated, with Enterprise Plus now getting 96GB vRAM per CPU license as well as other editions having their vRAM entitlements increased. Large VM’s will be capped at an entitlement maximum of 96GB (even if your VM has 1TB of RAM). This won’t be available at GA, but will be afterwards, with another tool being created so that users can keep track of vRAM entitlement useage easily in the meantime.

More details can be found here:

http://blogs.vmware.com/rethinkit/

I have to say, that I think what VMware has done here is amazing. They’ve realised they needed to change the licensing model, made a choice, and listened to customer feedback. And after all that, they changed the model so that existing users, and new customers, can take more advantage of their hypervisor based on current trends for VM memory sizing. It’s not often that you see this kind of dedication to customers and keeping them happy, especially from large companies. Hats off to you VMware.

UPDATE:

Also just found out that the ESXi vRAM limit is being increased from 8GB to 32GB – much better!