In esxupdate.log when checking compliance in VUM:
ValueError: VIBs ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03 and ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03 have unequal values of the 'payloads' attribute: '[elx-esx-libelxi: 1602.936 KB]' != '[elx-esx-libelxi: 1493.833 KB]
This is from a host that was installed with the 6.7U2 HPE Custom ISO then patched with the "critical" VUM baseline. It seems the baseline installs a conflicting vib which breaks VUM compliance checks from that point forward.
If I remove the vib with esxcli software vib remove -n elx-esx-libelxima.so, it allows VUM compliance scanning to resume but then the host reports as non-compliant against the critical patch baseline.
Is there a definitive fix for this? Can I somehow blacklist this vib within VUM? We don't even need it -- we don't have this hardware!
This is same discussed in the kb as below but removing the vib should not harm anything. I am unsure why it shows not compliant, possibly you can remove the one with 1493 kb and install the one with 1602kb
If you remove existing one available in the list, then there is only one which is removed so when scanned against the baseline, the vib is missing could lead to non-compliant behavior
Interesting. I see in the kb: "Workaround: Create a custom baseline without the conflicting vib."
I've done this and it does seem to work. With that vib removed, the host shows as non-compliant with the default built-in baseline. I'll have to make sure that default baseline remains unattached since another admin would be likely to come along in a few days/weeks and apply it (thus reinstalling the conflicting vib).
So I think I may brought this on myself by having the HPE vibsdepot as a patch source in addition to the default VMware repository. I just reset VUM back to defaults and it seems to have cleared all of this up. :smileyalert:
Just to add to this discussion, we have an identical problem to the one you've reported. In our case, we are adding two new HPE Gen10 Blade Servers to a system with 630FLB and 534M HBAs, Virtual Connect switches, and a 3PAR system, all operating over an iSCSI SAN, so we are definitely using hardware that depends on this VIB and related drivers.
Like you, we started with the HPE 6.7U2 Custom ISO. Based on HPE's Technical White Paper at:
we were aware of the conflicting VIB at the outset of this exercise (see Appendix O in this document). However, as you have noted, deleting this VIB does not resolve the problem, and after many attempts, we just keep going around in circles, always coming back to the state where we have duplicate, incompatible "elx-esx-libelxima" VIBs. One VIB shows up as "elx-esx-libelxima.so" while the other usually shows up as "elx-esx-libelxima.so-8169922." The Creation Dates for these two VIB variants vary, depending on the order In which we try to remediate these hosts. I've also tried manually installing the latest version of this VIB after deleting the duplicates, but that actually made the remediation problem worse.
We also see problems with the "hpe-driver-bundle-670," of which there are five versions, including 10.2.0, 10.3.0, 10.3.5, 10.4.0, and 10.4.1. Our ESXi host is actually using the "hpe-driver-bundle-622.214.171.124," which is the latest from April 10, 2019. After we remediate one of our new ESXi Gen10 hosts, we see that we are non-compliant with the VMware Predefined "Non-Critical Host Patches" baseline. What is interesting is that there are only two patches that are not compliant:
But this makes no sense, given that hpe-driver-bundle-6126.96.36.199 is what we actually have installed.
Honestly, this is a maddening problem. Even following HPE's instructions to delete this "elx-esx-libelxima" VIB results in a situation where remediating restores the two conflicting VIBs, which then prevent further remediation. It isn't clear which vendor is the source of this problem, but it seems absurd to be having this problem no matter what the source is.
I ran into the same issue with some Synergy SY480 Compute nodes. Followed this guide:
esxcli software vib list | grep ELX
Command Result –
elx-esx-libelxima.so 12.0.1108.0-03 ELX VMwareCertified 2018-08-23
Now to remove the VIB, use the command mentioned below.
esxcli software vib remove -n elx-esx-libelxima.so
For me this works. After the reboot I was able to scan the hosts and update them with UM.
I will add to this, as this has been my entire weekend and then some thus far. I have tried nearly everything myself. The issue is both HPE device driver / bundles: hpe-driver-bundle-6188.8.131.52 and 10.3.5. Both of these, whether, installed independently, together, 3.5 first, 3.0 second... nothing.
As someone else said, I even installed 10.4.1 by itself. It works, but the VUM complains that the 10.3.0 and 10.3.5 patches are needed. These are showing up in the default non-critical patches.
I have also tried just updating the host with ESXi670-Update02 and it still complains that the above are missing. The other thing is if I install U2 and then the 10.3.x updates, when I uninstall them, VUM complains about U2 not being installed and I have to do that again.
This problem has been lingering since April and after hours of digging, there is nothing anywhere I can find to fix this, other than work around it?
I opened a SR at VMware, they told me it's a third-party problem and I have to open an SR at HPE. So I opened one at HPE. The painful answer and solution was first to uninstall the conflicting VIB and then to add a modified download resource http://vibsdepot.hpe.com/hpe/apr.11.2019/index-drv.xml
With this it works again. But keep two things in mind. First the download resource should only be modified till the next ISO image is provided by HPE and second you will only be able to update v6.7!
I just upgraded from 6.5 to 6.7, if I remove the elx vibs then I can upgrade, but as long as I keep the vibsdepot in VUM it keeps complaining that 2 patches are missing and the host is not compliant.
Could you just clarify what that Vibsdepot URL really is doing, and whether I'd need to add new URLs for months going forward?
Would I likely to be able to go back to the old vibsdepot URL when a new HP custom ISO comes out?
Presently I've just removed the vibsdepot repositories and going with the custom ISO with vmware updates.
So I tried this, I uninstalled the ELX packages there were installed on my host then added the repo you listed, but I am still getting the same error in my esxupdate.log. Is there a way to manually exclude the ELX update from the HPE repo?
Who at HPE did you contact? I have tried calling support a couple of times on this, but no one seems to know anything.
This problem described in the article https://kb.vmware.com/s/article/59257:
While performing an Update Manager check compliance, the host returns the error:
esxupdate error codes: -1. Check the Update Manager log files and esxupdate log files for more details.
In the /var/log/esxupdate.log, you see entries similar to:
ERROR: ValueError: VIBs ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03 and ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03 have unequal values of the 'payloads' attribute: '[elx-esx-libelxi: 1602.936 KB]' != '[elx-esx-libelxi: 1493.833 KB]'
1. Enable SSH for ESXi host, connect to ESXi host via SSH and run command:
"esxcli software vib list | grep ELX"
elx-esx-libelxima-8169922.so 12.0.1188.0-03 ELX VMwareCertified 2019-11-19
elx-esx-libelxima.so 12.0.1108.0-03 ELX VMwareCertified 2019-11-19
2. Run command:
"esxcli software vib remove -n elx-esx-libelxima.so"
3. Restart ESXi host.
4. Enable SSH for ESXi host, connect to ESXi host via SSH and run command:
"esxcli software vib list | grep ELX"
elx-esx-libelxima-8169922.so 12.0.1188.0-03 ELX VMwareCertified 2019-11-12
5. Download file ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03_670.vib from http://vibsdepot.hpe.com/hpe/sep2018/esxi-670-drv-vibs/be2iscsi/
6. Copy file ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03_670.vib to ESXi host in /tmp/
7. Run command:
"esxcli software vib install -v /tmp/ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03_670.vib"
8. Restart ESXi host.
9. Check compliance and remediate.
Cause of this problem is different files
Moderator: Moved to Update Manager