Dell have recently released version 1.6 of their vCenter plugin, and I have come across a few bugs / annoyances so far. I tried to post feedback on the official Dell blog, but although the post says successfully posted nothing ever appears online ... so thought that I would share this here for hopefully everyone elses benefit.
Official blog for the Dell VC plugin, version 1.6;
I successfully upgraded to the current version 1.6.0.34 (shown correctly in the administration portal), but the GUI within vCenter still shows up as version 1.5.1 build 477 - technically not a problem, just not cool.
The next thing that stands out is that if you are not running the latest version of OpenManage, then all your hosts are shown as "non-compliant". You can check this from the host console as per below;
Non-compliant;
~ # esxcli software vib list | grep Dell
OpenManage 7.0-0000 Dell VMwareAccepted 2012-10-03
Compliant;
~ # esxcli software vib list | grep Dell
OpenManage 7.1-0000 Dell VMwareAccepted 2012-10-18
What this in effect pushes you to do is to install version 7.1, which I understood provided support for 12G systems, regardless of the fact that the hosts are only 11G systems. Whilst I can see the befifits of being up to date, I wouldn't class this as a "non-compliant" status.
I then used the fix compliance wizard to update OpenManage to version 7.1, and once again like previous verions of this plugin the deployment of OpenManage overwrites all your existing SNMP configuration, and replaces it with a single entry pointing back to the VC plugin (using IP address, noth DNS) ... effectively stopping all traps going to your existing OME infrastructure, or other destinations that you have configured. So you need to reconfigure SNMP on every host that use this method on. I know this is documented behaviour, but in my opinion it would be far better to simply append the existing configuration with the additional entry rather than overwriting the entire configuration.
As part of the remediation process the plugin puts the host into maintenance mode and reboots etc, as expected, BUT it also disables HA by stopping the vSphere High Availibility Agent and setting the startup policy to start and stop manually ... effectively disabling HA, as this daemon is not restarted with the host as before.
Hopefully there arent other majors, but these are the few that I have noted so far ... let's also hope that Dell reads this and feeds it back into their product develoment team and addresses these issues.
Cheers,
Jon