We’re currently neck-deep in migration at the moment, but despite the workload, it’s always worth considering what we can do now, that might save us some time and effort later on.

One of the reasons we were moving to vSphere was the ability to thin-provision (TP) our disks, which we’re hoping will allow us to increase the amount of machines that we can provision without needing to allocate more storage (currently 18 TB).  I found an article by Duncan Epping over at Yellow Bricks suggesting the use of Sysinternals SDelete utility before the conversion to TP.

Essentially, as deleted files are not zeroed in Windows, and because VMware looks at the raw disk when “deallocating” space during conversion to think provisioned disks; deleted data are not reclaimed.  Running SDelete in the Windows guest before converting the disk to thin provisioned format zeroes the deleted data and should allow the maximum amount of space to be reclaimed.

While I don’t doubt that this is all correct, I wasn’t sure how much extra space it would allow us to reclaim. The majority of our guests are relatively small windows clients, almost all of which have non-persistent hard drives; of course – once they’ve been made non-persistent, the drive is effectively frozen, and subsequent use won’t increase the amount of non-zeroed slack space.

What’s the best way to see whether this is worthwhile? Run an experiment of course!

Method

I took one of our standard Windows XP guests which had been migrated to the new vSphere infrastructure. It had a 10GB hard drive, currently persistent, but which has been – for the majority of it’s 9 month existence – non-persistent. I examined how much disk space it was using, this was the pre-TP “Control”. I then cloned it without customization. One of the clones was converted to TP during a Storage vMotion operation. The other had slack space zeroed using SDelete (this process took around 3 minutes). It was then converted to Thin Provisioned disk format using Storage vMotion in the same way as the first machine.

Results

Here’s what happened

Normal (Thick) Disk

• Provisioned Storage: 10.50 GB
• Not-shared Storage: 10.00 GB
• Used Storage: 10.00GB

Converted to Thin Provisioned

• Provisioned Storage: 10.50 GB
• Not-shared Storage: 5.05 GB
• Used Storage: 5.05 GB

Converted to Thin Provisioned, after running SDelete

• Provisioned Storage: 10.50 GB
• Not-shared Storage: 4.21 GB
• Used Storage: 4.21 GB

Conclusion

Zeroing slack space on this typical machine saved me 0.84 GB (8.4%). For the minimal effort involved, I think this is worthwhile (I have about 500 more machines almost exactly the same as this).

The percentage of free space reclaimed would likely be higher on persistent machines, or larger machines which see frequent creation and deletion of files.

I’ve been trying out XtraVirt‘s vAlarm:-

vAlarm is a Windows® based application which monitors alarms generated by VMware® vCenter.

The product is designed to be installed on an administrators PC, and provides automated monitoring of vCenter alarms without needing to be logged into a full VI Client console.

The software automatically communicates with a vCenter server on a user configurable schedule, and notifies any active alarms via a popup information bubble in the notification area of a users desktop.

The option to show details of all active alarms displays an information dialogue which lists individual alarms with detailed descriptions.

The software supports VMware vCenter 2.5 & 4.0.

It’s turned out to be quite handy, as it’s making me far more conscious of alarms. It might even encourage me to modify the default set of alarms – I’m generally not interested in guests going into the red because of CPU or memory due to the nature of the way they’re used, but I do need to know when hosts and datastores are running close to capacity.

The system tray application pops up a bubble, even when there are no alarms, which isn’t strictly necessary, and it might be nice to be able to collate notifications from more than one vCenter Server (I’m currently watching over two); but these are minor quibbles about a free product.

You can download vAlarm from XtraVirt (free registration required).

We can use PowerShell to search through the event logs of a machine object ($objVM in the example below) for events which match a specific pattern – in this case powering off a machine. Once we have the event object, we can access the properties of the first object in the array (the most recent event)

$objEvent = @(Get-VIEvent -Entity $objVM | Where-Object {$_.fullFormattedMessage -like "Task: Power off Virtual Machine"})
$objEvent[0].userName
$objEvent[0].createdTime

I recall seeing an alternate way of getting events, which might be faster; if I have time, I’ll look it up.

This is based on Carter Shanklin’s PowerShell snippets to query VC and ESX build version numbers.

This script loops through the list of vCenter servers, and gets their version and build info, as well as the version and build info for it’s connected hosts.

# Script to connect to a list of vCenter Servers, and get their version numbers, as well as the version numbers of their hosts
# Ben Neise
# 02/10/09
 
# Array of vCenter Servers
$arrVCenterServers = @("server1","server2","server3")
 
# Create empty arrays for the results
$arrTableVCs = @()
$arrTableHosts = @()
 
# Loop through the array of vCenter servers specified above
ForEach ($strVCenterServer in $arrVCenterServers){
	# Connect to the VC
	$objVCenterServer = Connect-VIServer $strVCenterServer
	# Version info about the VC you are connected to
	$viewVCenterServer = Get-View serviceinstance
	# Add custom attributes to each VC objects for version and build
	$objVCenterServer | Add-Member -Name Version -type noteproperty -value ($viewVCenterServer.content.about.Version) -Force
	$objVCenterServer | Add-Member -Name Build -type noteproperty -value ($viewVCenterServer.content.about.Build) -Force
	# Add the VC object to the results array
	$arrTableVCs += $objVCenterServer
	# When connected to loop through the hosts managed by the VC
	ForEach ($objHost in (Get-VMhost | Sort-Object)){
		# Get the view for the current host
		$viewHost = $objHost | Get-View
		# Add custom attributes to the host object for VC server, Host and Version
		$objHost | Add-Member -Name VCServer -type noteproperty -value $objVCenterServer.Name -Force
		$objHost | Add-Member -Name Host -type noteproperty -value $viewHost.Name -Force
		$objHost | Add-Member -Name Version -type noteproperty -value $viewHost.Config.Product.Version -Force
		# Add the host object to the results array
		$arrTableHosts += $objHost
	}
	# Disconnect from the VC server
	Disconnect-VIServer -Confirm:$False
}
# Output the VC results (can be modified to output to a CSV with Export-CSV)
$arrTableVCs | Select-Object Name, Version, Build | Sort-Object Name
 
# Output the Host results (can be modified to output to a CSV with Export-CSV)
$arrTableHosts | Select-Object VCServer, Host, Version, Build | Format-Table
 
# End of script