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.
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.
Thanks to Pascal for trying out sfvAlarms on newly released vSphere 5.1 (sfvAlarms is my import and export utility for vCenter alarms). The export is OK but not the import. Am looking into this now and hope to have another version that will be 5.1 compatible as well as backwards compatible with 4 and 5. Currently sfvAlarms only works with 4.0 and 5.0 as per User Guide description.
Have downloaded the 5.1 vCenter Appliance and 5.1 C# Web Services SDK and getting an error it looks like on the AlarmSpec when calling CreateAlarm. I can’t however see anything wrong withe spec! aaarrgghhh! I need to go back to something really simple and see if can create the simplest possible alarm in 5.1 to make sure not something awry at VMware’s end!. Nothing I can see in the revision updates seems to relate to alarms, although have noticed that there are now 61 default alarm definitions as opposed to the 54 in vSphere 5.0.
The VMware KB for restoring default vCenter alarms doesnt seem to work any more either for 5.1 (KB: 2009166) – at least I cant get the default alarms back on the 5.1 applicance.
- KB all good.. dont know what happened but works fine on v5.1
- New version of sfvAlarms now on Download page (v.1.1.0) now with vCenter 5.1 support 🙂
V1.0.0 of sfvAlarms has hit the decks and is now available on the download page. This simple utility allows the export and import of vCenter Server alarms from a simple Windows GUI. It uses the VMware Web Services SDK and is written in C#.
I felt something a lot simpler than having to use Powershell scripting or other scripts would enable managing alarms across vCenter’s to be much more controlled. Being able to import and export alarms at will allows for duplication of alarms as well as being able to revert to a known state in case of meddlers!
All comments greatly received as well as enhancement requests! I have tested as much as I can on vCenter 4 and against the vCenter 5 appliance. The User Guide on the download page has much more info about the utility.
If you are giving it a whirl I would obviously suggest not installing it on a production environment, but trying it out on a test vCenter installation first or maybe the VMware vCenter 5 appliance that can be downloaded from VMware.
Hope it proves useful, if not at least it has been a technical exercise for me to brush up on some programming skills 🙂
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.