Have just given the current version a basic test again vCenter 5.5 and all seems good! I used the vCenter appliance, specifically version 5.5.0, build 1398495, and fired up the existing version of sfvAlarms against it. VMware have upped the number of default alarms again, and there are now some 68 alarms. I ran a basic test of exporting the default alarms, deleting them, and importing again. All looks good. There is a new version of the SDK, so at some point I should really compile against the new SDK and then re-check against all versions and try out a few custom alarms set at different levels.
Appreciate all feedback against 5.5 or if you encounter any issues.
I have uploaded a new version (v1.1.2) – see Download page. This fixes a small issue where characters in the Alarm name were invalid when used as file names for export. Thanks to Rob for taking the time to post on this issue and send me output from his export so I could nail it. The Dell Management Plugin he is using adds a load more alarms, some using characters in the alarm name which were invalid when used as filenames.
Just uploaded a new version of sfvAlarms. Had a feature request over on vladan’s blog to allow the user to specify the alarm export path so as not to fall foul of local policies that limit where data can be written to. This is now implemented in v1.1.1 available on Download page along with updated user guide. The export setting is on the Preferences dialogue – you can leave at default or specify custom folder.
Few things I have learnt on my Autodeploy journey regarding DHCP…
When using DHCP, use reservations, then add Option 12 to your reservation and enter the host name. When your host gets added to vCenter it will come in with proper host name and qualified with domain (depending on other setups).
Also on properties of your reservation (using W2008R2), select DNS tab, and allow updates by ensuring Enable DNS dynamic updates is ticked, then selecting option Always dynamically update DNS A and PTR records. I Also tick box Dynamically update DNS A and PTR records for DHCP clients that do not request updates. This will mean you will get your auto-deploy hosted added to DNS with Host(A) record (and if you have remembered to create a reverse lookup zone for your subnet)a PTR record as well. This saves the work of adding this manually.
And finally… setting Spanning-Tree PortFast on your switch port with which your host is booting and getting DHCP lease is required. Have seen 2nd-stage DHCP request within gPXE failing / timeout unless Spanning-Tree PortFast is set.
Stripeyfish is feeling chuffed! Managed to get AutoDeploy working under VMware Workstation 7 and just pushed out my first stateless ESXi 5 VM! Still a way to go with host files, answer files, VIB cutomisations etc but its a start!
Have built the lab from scratch – no use of appliances. So have W2008R2 based VMs as follows:
- Domain Controller (inc. DNS)
- SQL 2008R2
- Auto Deploy server hosting DHCP / AutoDeploy / Solarwinds TFTP
The PowerShell side of things strikes me as odd… like its unfinished though. For some reason even though the latest PowerCLI installed I had to manually add in the snapins for VMware.ImageBuilder and VMware.DeployAutomation (which took me a while to figure out). Was launching PowerCLI from desktop shortcut.
Once have tested all in the lab will be trying on real tin as part of a vCloud setup (which am also teaching myself and have partly setup in Workstation as well although my PC getting a bit stetched!) so can push out Resource Cluster hosts via Auto Deploy. Well thats the plan!
As per the developer setup guide for VMware vSphere Web Services SDK 5.0, you have to build your own DLLs from the wsdl files provided.
There are a few changes from SDK 4.0, most notably the lack of the genvimstubs.cmd and OptimiseWsStubs.exe files. However it is still fairly straightforward… apart from the initial wsdl command! read on…
Depending on where you extract the SDK zip file to you may end up with spaces in your path. After lots of head scratching it turns out wsdl.exe does not like this! If you have spaces in your path, then when running command “wsdl.exe /n:VimyyApi vim.wsdl vimService.wsdl” you will get an error as follows – despite trying all combinations of environment variables, running from Visual Studio command prompt in the actual vim25 directory:
Error: Could not find a part of the path ‘c:\program%20files\microsoft%20visual%20studio%209.0\sdk\vsphere5\vsphere-ws\wsdl\vim25\query-messagetypes.xsd’.
So rather than copy to e.g. Visual Studio/SDK path, just extract to e.g. C:\vSphere5\… and then once produced the two DLLs if you want to compile the samples, then move/copy to correct folder afterwards. The main DLL gets produced twice – the first time ‘as is’ to then produce the second XMLSerialisers DLL, then again when the reference to this DLL has been added to the vimservice.cs file and the XMLAttributes commented out – this is all in the Developer Setup Guide.
Hopefully this will save a few hours as I spent trying to work out what was going on! (This was with VS2008).
Anyone who has custom alarms in vCenter will be frustrated when they need to set up the same alarms in multiple datacenters as there is nothing out of the box that provides this either in vSphere 4 or 5 (please let me know if there is!).
To this end I have written a utility that allows simple export and import of alarms in and out using the C# web services API. It works really well and also effectively allows state management of alarms so that if anyone fiddles with alarms can easily reset to known set.
Update 21st May 2012 – nearly ready to upload… been doing some more coding on the front end over the weekend. Works with vSphere4.. just looking at vSphere5 compatibility.