Emptying a VMFS datastore with PowerCLI

Posted by on Thursday, 26th January, 2012 No comments

Well, once again I hacked at the Powershell/PowerCLI the other day. Since we don’t yet have a Enterprise Plus license at work (which would support Datastore Maintaince and Storage DRS), I needed a way to empty one datastore and move all the content into another one, while enabling Thin-Provisioning.

So I googled for a bit, and actually found a few hints … So without further yada-yada, here’s the script I came up with:

param( [string] $vCenter, [string] $datastore_old, $datastore_new )

# Add the VI-Snapin if it isn't loaded already
if ( (Get-PSSnapin -Name "VMware.VimAutomation.Core" -ErrorAction SilentlyContinue) -eq $null )
{
	Add-PSSnapin -Name "VMware.VimAutomation.Core"
}

if ( !($vCenter) -or !($datastore_old) -or !($datastore_new) ) {
	Write-Host `n "datastore-massmigrate-vms: <vcenter> <datastore_old> <datastore_new>" `n
	Write-Host "   datastore-massmigrate-vms moves all VMs residing on <datastore_old>"
	Write-Host "   to the datastore named <datastore_new>." `n
	exit 1
}

# Turn off Errors
$ErrorActionPreference = "silentlycontinue"

Connect-VIServer -Server $vCenter

Write-Host "Migrating VMs from datastore" $datastore_old "to" $datastore_new

$vms = Get-VM -datastore $datastore_old

foreach ($vm in $vms) {
         Write-Host "Moving" $vm "from" $datastore_old "to" $datastore_new
         Move-VM $vm -Datastore $datastore_new
}

Disconnect-VIServer -server $vCenter -Confirm:$false

Initially I have something different, which was a bit shorter (based on Brian‘s work), but it had a huge downside: If you have vRDMs (like I do), it converts every damn vRDM into a VMDK, so make sure you only run this script on a datastore on VMs that either have only pRDMs or VMs with only VMDKs.

Doing TSM’s job on Windows Server 2008

Posted by on Thursday, 26th January, 2012 No comments

Ran into another weird problem the other day … Had a few Windows boxens running out of space. Why ? Well, because TSM includes a System-State backup when creating the daily incremental. Now, apparently (as stated by the IBM support) it isn’t TSM’s job to keep track of the VSS snapshots but rather Windows’. Now by default, if you don’t click on the VSS properties of a Windows drive, there is no limit on the volume. Thus, VSS is slowly eating up all your space.

That isn’t the worst of it, but when you want to delete it all … With Windows 2003 you would just this:

run vssadmin delete shadows /for=C:

However, as with everything Microsoft, Windows 2008 R2 does it a little bit different. As a matter of fact, it won’t allow you to delete application triggered snapshots (as you can see in the example below), so you’re basically shit-out-of-luck.

Error: Snapshots were found, but they were outside of your allowed context. Try removing them with the backup
application which created them.

Well, not really … diskshadow to the rescue. Simply running diskshadow with a simple script like this:

diskshadow> delete shadows C:
......

Just for clarification this isn’t my own work, it was someone elses.

Empty Port SSL after ADAM installation

Posted by on Wednesday, 18th January, 2012 No comments

I’ve been meaning to post this, but never actually got around to doing that. When installing vCenter 5.0, an instance of ADAM is installed, which stores all the configration data for Linked Mode.

It basically boils down to running this script and rebooting the box:

reg DELETE "HKLM\ SYSTEM\CurrentControlSet\services\ADAM_VMwareVCMSDS\Parameters" /v "Port SSL" /f
reg ADD " HKLM\ SYSTEM\CurrentControlSet\services\ADAM_VMwareVCMSDS\Parameters" /v "Port SSL" /t REG_DWORD /d 0000027c  /f

This is no new invention of myself, just writing it down for myself from here or here.

Rebooting a virtual machine via Task scheduler

Posted by on Monday, 16th January, 2012 No comments

Since the Scheduled Tasks in vCenter ain’t exportable, I went ahead and wrote a rather simple script, which lets me do this in Windows own Task Scheduler. What this script does, is initiate a graceful shutdown and if the VM isn’t shutdown within 60 seconds (12 * 5 seconds) it simply powers the VM off and immediately after that powers it back on.

param( [string] $vCenter, [string] $VMname )

# Add the VI-Snapin if it isn't loaded already
if ( (Get-PSSnapin -Name "VMware.VimAutomation.Core" -ErrorAction SilentlyContinue) -eq $null )
{
	Add-PSSnapin -Name "VMware.VimAutomation.Core"
}

If ( !($vCenter) -or !($VMname) )
{
	Write-Host
	Write-Host "vm-reboot: <vcenter-server> <VMname>"
	Write-Host
	Write-Host "   <vcenter-server>  - DNS name of your vCenter server."
	Write-Host "   <VMname>          - Display name of the VM in this vCenter server."
	Write-Host
	exit 1
}

Connect-VIServer -Server $vCenter

$VM = Get-VM $VMname

# First, try shutting down the virtual machine gracefully
Write-Host "Stopping VM $( $VM )"
Write-Host "   - Graceful shutdown"
Shutdown-VMGuest -VM $VM -Confirm:$false
$VM = Get-VM $VMname

$i = 0
While ($VM.PowerState -ne "PoweredOff") {
	# If that doesn't work, break out the hammer and just kill it
	if ( $i -gt 12 ) {
		Write-Host "  - Forced shutdown"
		Stop-VM -VM $VMname -Confirm:$false
	}

	Start-Sleep -Seconds 5
	$VM = Get-VM $VMname
	$i++
}

If ($VM.PowerState -eq "PoweredOff") {
	Write-Host "Starting VM $( $VM )"
	Start-VM -VM $VM -Confirm:$false >$NULL
}

Disconnect-VIServer -server $vCenter -Confirm:$false

Before this implementation in PowerCLI, I needed three tasks for each VM that was to be scheduled. And when migrating vCenters (and I usually do an empty install) vCenter’s scheduled tasks are not exportable, thus you need to re-create the tasks on the new vCenter by yourself again, which for more than four virtual machines is really a pain in the ass …

Update: well, found an error that caused shit not to work … Basically Stop-VM also needs the object for $VMname, otherwise the whole point of waiting for the VM to be stopped is kinda moot (seeing as Stop-VM never stops obsessing about not having a Get-VM object or a VM name to work with).

Reoccurring memory limits in vCenter

Posted by on Friday, 13th January, 2012 Comments Off

We recently had, after we migrated from vSphere 4 to vSphere 5, a memory limit in size of the configured memory on each and every VM. Since memory limits on VM level pretty much destroy performance, I went ahead an wrote this simple script to remove all memory limits on all VMs that don’t have “Unlimited” configured:

param( [string] $vCenter )

# Add the VI-Snapin if it isn't loaded already
if ( (Get-PSSnapin -Name "VMware.VimAutomation.Core" -ErrorAction SilentlyContinue) -eq $null )
{
	Add-PSSnapin -Name "VMware.VimAutomation.Core"
}

If ( !($vCenter) )
{
	Write-Host
	Write-Host "cluster-remove-mem-limits: <vcenter-server>"
	Write-Host
	Write-Host "   <vcenter-server>  - DNS name of your vCenter server."
	Write-Host
	exit 1
}

Connect-VIServer -Server $vCenter

Get-VM | Get-VMResourceConfiguration | Where-Object { $_.memlimitmb -ne '-1' } |`
	Set-VMResourceConfiguration -memlimitmb $null

Disconnect-VIServer -server $vCenter -Confirm:$false

This script is basically what the guy over at get-admin.com did, just only for memory limits.