We’re currently having some issues caused by the convergence of vSphere 4.0, IndependentNonPersistent drives, StandBy and DRS (I’ll post more on that later). As a workaround, we needed to modify 228 machines so that they did not go into hibernation. You can do this though the vSphere Client by right clicking the virtual machine, click Edit Settings, go to the Options Tab, then select Power Management, and changing the radio button. We were wanting to change from “Suspend the virtual machine” to “Put the guest OS into standby mode and leave the virtual machine powered on”.
To do this the machines need to be powered down. We had an imminent maintenance window, but it wouldn’t allow us the time to make this change manually (even if we wanted to), this necessitated some automation. Unfortunately I had no idea how to go about editing this setting using the PowerCLI, even after a little search through the VMware PowerCLI community.
This seemed like the perfect opportunity to try out Project Onyx.
Carter Shanklin’s video does a good job of explaining how to Onyx up and running, and it worked exactly as described (even on my Windows 7 machine).
- Download the Onyx files and extract to a folder
- Run the Onyx executable
- Click the Connect button, and connect to your VirtualCenter server.
- Once that’s launched, start vSphere client, but instead of connecting to your VirtualCenter server, connect to http://localhost:1545 (Carter actually says 1445 in the video, but you can see on screen that he’s using 1545). Use your normal credentials.
- Ignore the warning about unencrypted traffic (as Carter explains, the unencrypted traffic is local-only, the network traffic is still encrypted)
- Click the Start button on Onyx
- In vSphere client make whatever changes it is that you’re wanting to record.
- Click the Pause button on Onyx, and you’ll see in the window a script has been created.
- Copy this into your favourite PowerShell editor, and modify until it’s suitable for your purposes.
The original capture from the Onyx Window
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec $spec.changeVersion = "2009-11-27T09:16:04.570821Z" $spec.powerOpInfo = New-Object VMware.Vim.VirtualMachineDefaultPowerOpInfo $spec.powerOpInfo.defaultPowerOffType = "soft" $spec.powerOpInfo.defaultSuspendType = "hard" $spec.powerOpInfo.defaultResetType = "soft" $spec.powerOpInfo.standbyAction = "checkpoint" $_this = Get-View -Id 'VirtualMachine-vm-1074' $_this.ReconfigVM_Task($spec)
A second capture changing the setting back to isolate the exact line that makes the changes
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec $spec.changeVersion = "2009-11-27T09:16:33.872017Z" $spec.powerOpInfo = New-Object VMware.Vim.VirtualMachineDefaultPowerOpInfo $spec.powerOpInfo.defaultPowerOffType = "soft" $spec.powerOpInfo.defaultSuspendType = "hard" $spec.powerOpInfo.defaultResetType = "soft" $spec.powerOpInfo.standbyAction = "powerOnSuspend" $_this = Get-View -Id 'VirtualMachine-vm-1074' $_this.ReconfigVM_Task($spec)
And a finished script, which will run it against all machines in a specified blue folder comment/uncomment one of the $specVM.powerOpInfo.standbyAction lines to choose which option you want.
$objVMs = Get-Folder "Folder Name" | Get-VM
ForEach ($objVM in $objVMs){
$specVM = New-Object VMware.Vim.VirtualMachineConfigSpec
$specVM.powerOpInfo = New-Object VMware.Vim.VirtualMachineDefaultPowerOpInfo
$specVM.powerOpInfo.standbyAction = "checkpoint" # Put the guest OS into StandBy Mode and leave the Virtual Machine powered On
#$specVM.powerOpInfo.standbyAction = "powerOnSuspend" # Suspend the Virtual Machine
$viewVM = Get-View -Id $objVM.Id
$viewVM.ReconfigVM_Task($specVM)
}
I was actually surprised at how easy this was; and I think it’s going to make me a bit more adventurous with what I attempt to do via the PowerCLI.
VMware have released update 1 for vSphere 4.0.
The following enhancements have been made to ESX (from the release notes):-
VMware View 4.0 support – This release adds support for VMware View 4.0, a solution built specifically for delivering desktops as a managed service from the protocol to the platform.
Windows 7 and Windows 2008 R2 support –This release adds support for 32-bit and 64-bit versions of Windows 7 as well as 64-bit Windows 2008 R2 as guest OS platforms. In addition, the vSphere Client is now supported and can be installed on a Windows 7 platform. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.
Enhanced Clustering Support for Microsoft Windows – Microsoft Cluster Server (MSCS) for Windows 2000 and 2003 and Windows Server 2008 Failover Clustering is now supported on an VMware High Availability (HA) and Dynamic Resource Scheduler (DRS) cluster in a limited configuration. HA and DRS functionality can be effectively disabled for individual MSCS virtual machines as opposed to disabling HA and DRS on the entire ESX/ESXi host. Refer to the Setup for Failover Clustering and Microsoft Cluster Service guide for additional configuration guidelines.
Enhanced VMware Paravirtualized SCSI Support – Support for boot disk devices attached to a Paravirtualized SCSI ( PVSCSI) adapter has been added for Windows 2003 and 2008 guest operating systems. Floppy disk images are also available containing the driver for use during the Windows installation by selecting F6 to install additional drivers during setup. Floppy images can be found in the /vmimages/floppies/ folder.
Improved vNetwork Distributed Switch Performance – Several performance and usability issues have been resolved resulting in the following:
- Improved performance when making configuration changes to a vNetwork Distributed Switch (vDS) instance when the ESX/ESXi host is under a heavy load
- Improved performance when adding or removing an ESX/ESXi host to or from a vDS instance
Increase in vCPU per Core Limit – The limit on vCPUs per core has been increased from 20 to 25. This change raises the supported limit only. It does not include any additional performance optimizations. Raising the limit allows users more flexibility to configure systems based on specific workloads and to get the most advantage from increasingly faster processors. The achievable number of vCPUs per core depends on the workload and specifics of the hardware. For more information see the Performance Best Practices for VMware vSphere 4.0 guide.
Enablement of Intel Xeon Processor 3400 Series – Support for the Xeon processor 3400 series has been added. For a complete list of supported third party hardware and devices, see the VMware Compatibility Guide.
vCenter 4.0 has also been updated, and now has full compatibility with Windows 7 x86 and x64 versions. Saving the various hacks that were necessary to get it working.
Also, the PowerCLI has been updated, and can be found here. There are 68 new CMDLETS, which Alan Renouf does a great job of explaining. I’m especially looking forward to trying out Get\Set-CustomAttribute (no more manipulation of the View object), Move-VMTemplate (no more converting templates to machines), and Get\Set-VMQuestion (for those times when the datastores run out of space for the REDO files necessitated by Non-Persistent disks).
I’m looking forward to investigating the new PowerCLI functionality, and I’m also looking forward to not needing to manually customise the dozen or so Windows 7 guests I’m deploying next week!
Carter Shanklin has announced that VMware have released an Alpha build of the long-anticipated Project Onyx. This is a script recorder for vSphere Client, which is designed to allow scripting of things which are awkward or difficult to achieve using the VMware PowerCLI APIs alone.
Downloading this at the moment, although I don’t suspect I’ll have time to look at it for a while.
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
As part of the migration I’m working on, we needed to add a whole bunch of Virtual Port Groups with associated VLANs to the servers. The following script could do this in a few minutes (although Host Profiles would accomplish much the same thing, we’re not running Enterprise)
# Sets up virtual port groups on all hosts connected to a specific vCenter Server # Name of vCenter Server $strVCenterServer = "your.vCenter.Server" # VLANs and associated VPGs $ArrVLANs = @{ "123" = "Admin"; "456" = "GPO"; "789" = "NAG"; } # Connect to the vCenter Server Connect-VIserver $strVCenterServer # Loop through the VLAN/VPG pairs ForEach($objVLAN in ($ArrVLANs.Keys | Sort-Object)){ # Loop through the hosts ForEach ($objHost in (Get-VMHost | Sort-Object)){ # Create the VPG with the VLAN as specified in the array above, on the switch called "VMSwitch" on the current host # Remove the "-WhatIf" tag from the end of the following line to "arm" the script New-VirtualPortGroup -Name $strNewVPG -VirtualSwitch (Get-Virtualswitch -VMHost $objHost | Where-Object { $_.Name -match "VMswitch" }) -VLanId $strNewVlanTag -WhatIf # Write what we've just done to screen Write-Host "Adding Virtual Port Group" $ArrVLANs[$objVLAN] "with VLAN Tag" $objVLAN "to" $objHost } } # Disconnect the session from the host Disconnect-VIServer -Confirm:$False
Although this isn’t a complicated script, it was the first time I’ve used hash tables (thanks to PowerShell.Com’s excellent page), so I thought I’d share.
I love it when I have an idea in my head of a script I need to write, and then I run across one that does exactly what I need!
Hugo Peeter’s has written a script to add VMX location as a Custom Attribute:
Add Vmx Path to VI Client using Powershell | PeetersOnline.nl.
Photo from Flickr, courtesy C Wood
VMware have published an excellent white paper on memory management [pdf].
The document is technically detailed, but makes interesting reading. The authors do a good job of describing the methods ESX uses to manage and allocate virtual memory; and how when guests deallocate memory it’s not necessarily freed up for reuse by other guests. This should prevent you from allocating more memory to guests than is physically available on the host (overcommitting); however the hypervisor uses three memory reclamation strategies which allow overcommitment:-
- Transparent Page Sharing (TPS). Where ESX detects that multiple guests are using identical memory pages (such as those used by common OS components), it presents one shared copy to the guests. By default, this is active all the time. If the guests need to write to the memory, a copy needs to be made, which incurs a slight performance penalty.
- Ballooning. Is where VMware tools allows the hypervisor to see inside the guest operating system and reclaim unused memory. This typically occurs when ESX drops to less than 4% free memory (the Soft threshold). It has more of an overhead than TPS, but is still preferable to the alternative.
- Hypervisor swapping. This is used as a last-resort when TPS or Ballooning cannot provide enough memory (or cannot provide it quickly enough). Swapping tends to affect the guest more than the other two methods.
In the unlikely event that Hypervisor Swapping is unable to provide enough memory to meet the requirement, the hypervisor blocks the execution of all virtual machines which exceed their memory limit.
The whitepaper details the results of various benchmarks to evaluate the performance overhead of each of the reclamation strategies. While I’d certainly heard that the performance impact of TPS was negligible, I had always been slightly sceptical, but the data provided by VMware would appear to back it up.
The whitepaper also includes some best practices for memory management, some of which have had me thinking about our memory allocation strategy:-
- Do not disable page sharing or the balloon driver. These two techniques are enabled by default in ESX4 and I can’t imagine that anyone would disable them unless they had specific reason to. It’s also another reason to make sure you have VMware tools installed on all your guests.
- Carefully specify the memory limit and memory reservation. Our environment is pretty fluid, with a large number of small guests with 10-15% of them being . For this to be useful for us, these values would need to be constantly checked and reconfigured.
- Host memory size should be larger than guest memory usage. I generally try to limit our hosts to a 20% potential overcommit on RAM allocated to guests, and as there are usually only about 80% of our machines switched on at any one time, the hosts are normally pretty comfortable. However, this conservative approach means our RAM allocations need to be carefully managed, and kept as low as possible; which may be hitting us elsewhere (see below)
- Use shares to adjust relative priorities when memory is overcommitted. Our environment is pretty unique in that the vast majority of the machines have equal priority, so there’s little need for us to add another management overhead.
- Set appropriate Virtual Machine memory size. The virtual machine memory size should be a little larger than the average used by the guest. I think this is an area we need to look at in our environment. Our default RAM allocations for guests is probably a little on the low side, due to historical reasons, and due to our current environment being configured with a rather paltry 16GB of physical RAM (a problem that will be resolved in the next couple of months). We may be keeping our memory usage in check, but the resultant disk-swapping might be stressing our storage infrastructure.
The white paper is definitely worth reading; it’s certainly going to help me plan a memory management strategy for the implementing our infrastructure on the new hardware .
