Hi All,
I have just found a bug in the latest NMI sourcing bundle (version 2.1.2) for HP DL585 G6 servers.
I currently have version 2.0.11 installed, and after importing version 2.12 into my VUM repository and scanning the host for updates it was oddly already installed. The obvious alarm bell was that the install data was much earlier thant the release date.
Version 2.1.2 - released 13/08/2012;
I knew that I hadn't deployed this yet, so did a little digging.
From the DCUI I can see that I have the old version 2.0.11 installed (with an old date as expected);
~ # esxcli software vib list | grep hpnmi
Name Version Vendor Acceptance Level Install Date
-------------------- ---------------------------------- --------------- ---------------- ------------
hpnmi 2.0.11-434156 hp PartnerSupported 2012-04-28
So why was VUM reporting that version 2.1.2 was already installed?
I manually removed this;
~ # esxcli software vib remove -n hpnmi
Removal Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed:
VIBs Removed: hp_bootbank_hpnmi_2.0.11-434156
VIBs Skipped:
I rescanned the host, and used VUM to deploy version 2.1.2 (release date 13/08/2012).
Now, from the DCUI I can see that I still have the old version 2.0.11 installed, but the install date has changed to today;
~ # esxcli software vib list | grep hpnmi
Name Version Vendor Acceptance Level Install Date
-------------------- ---------------------------------- --------------- ---------------- ------------
hpnmi 2.0.11-434156 hp PartnerSupported 2012-11-08
So the question is, do I have the old version or the new version installed?
I looked into the XML data of the bundles, and it turns out that HP did a poor job of updating the version numbers so the current version 2.1.2 has a mix of old and new version numbers embedded in the XML (see below);
Version 2.0.11 - correct;
Version 2.1.2 - incorrect;
Has anyone else noticed this, and can I safely assume that I have the new version installed, but simply reports the old version number because of the sloppy version control?
Cheers,
Jon
I also noticed this when HP released that supposedly "new" NMI bundle in September (shameless self-plug: http://alpacapowered.wordpress.com/2012/09/06/september-esxi-hp-updates/).
As you found out, both VIBs are actually the same version and only the metadata has changed. This is because the metadata was updated to apply the same VIB to the recently released ESXi 5.1 too.
The md5sums of both VIBs are identical - so it really is exactly the same code.
So the bottom line is, the "outer" version of a whole offline bundle package is completely irrelevant. What matters are the versions of the actual VIBs inside.
I also noticed this when HP released that supposedly "new" NMI bundle in September (shameless self-plug: http://alpacapowered.wordpress.com/2012/09/06/september-esxi-hp-updates/).
As you found out, both VIBs are actually the same version and only the metadata has changed. This is because the metadata was updated to apply the same VIB to the recently released ESXi 5.1 too.
The md5sums of both VIBs are identical - so it really is exactly the same code.
So the bottom line is, the "outer" version of a whole offline bundle package is completely irrelevant. What matters are the versions of the actual VIBs inside.
There's no shame in self plugs when the articles are well written
Thanks for the info!
Cheers,
Jon