VMware Cloud Community
rm_bk
Enthusiast
Enthusiast

ELX_bootbank_elx-esx-libelxima.so conflict between patch baseline and HP custom ISO.

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!

24 Replies
msripada
Virtuoso
Virtuoso

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

VMware Knowledge Base

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

Thanks,

MS

rm_bk
Enthusiast
Enthusiast

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).

Reply
0 Kudos
rm_bk
Enthusiast
Enthusiast

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:

eChuck
Contributor
Contributor

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:

https://h20195.www2.hpe.com/v2/getpdf.aspx/a00061651enw.pdf?ver=3.0

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-670.10.4.1," 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:

(1) hpe-driver-bundle-670.10.3.0

(2) hpe-driver-bundle-670.10.3.5

But this makes no sense, given that hpe-driver-bundle-670.10.4.1 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.

Reply
0 Kudos
rm_bk
Enthusiast
Enthusiast

We're still rolling with the VUM defaults.  We haven't put the HPE vibsdepot URL back in (as much as we'd like to).  :smileycry:

Reply
0 Kudos
Schaedle
Enthusiast
Enthusiast

We have exactly the same problem here with our new HPE Gen10 server. Did someone already find a newer version of this VIB?

Reply
0 Kudos
Skeetneet
Contributor
Contributor

I ran into the same issue with some Synergy SY480 Compute nodes. Followed this guide:

https://www.servertrouble.com/the-host-returns-esxupdate-error-codes-1-check-the-update-manager-log-...

Command –

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.
Command –
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.

Reply
0 Kudos
MarkusPi
Contributor
Contributor

I'm hitting these problems too. I used the vibsdepot with 5.5 and 6.5 without issues. Why problems with 6.7? I'm confused.

Reply
0 Kudos
psychoschlumpf
Contributor
Contributor

I am hitting the same problem here - is there any solution how to get rid of it and

a) Still to follow HPE Baseline

b) Still follow ESXi Patches

Reply
0 Kudos
davesamic
Contributor
Contributor

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-670.10.3.0 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? 

Reply
0 Kudos
Schaedle
Enthusiast
Enthusiast

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!

Regards Wolfgang

pirx666
Contributor
Contributor

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.

pastedImage_0.png

Reply
0 Kudos
MarkusPi
Contributor
Contributor

Thanks Wolfgang,

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.

Thanks

Mark

Reply
0 Kudos
Roger3000
Contributor
Contributor

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.

Reply
0 Kudos
pazzoide76
Contributor
Contributor

I've got the same problem.

I remove the vib but the vum reinstalls it and tells me it's not compliant.

Is there any solution?

ThomasOliveri
Contributor
Contributor

I am also seeing this issue.  But I have several identical Gen9 blades and so far only one has the problem.

Reply
0 Kudos
DimVKir
Contributor
Contributor

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]'

Solution:

1. Enable SSH for ESXi host, connect to ESXi host via SSH and run command:

    "esxcli software vib list | grep ELX"

  Command Result:

    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"

  Command Result:

     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

http://vibsdepot.hpe.com/hpe/sep2018/esxi-670-drv-vibs/be2iscsi/ELX_bootbank_elx-esx-libelxima.so_12...

and

<vcenter>/vum/repository/hostupdate/HPE/sep2018/esxi-670-drv-vibs/be2iscsi/ELX_bootbank_elx-esx-libelxima.so_12.0.1108.0-03_670.vib

scott28tt
VMware Employee
VMware Employee

Moderator: Moved to Update Manager


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
Reply
0 Kudos
rm_bk
Enthusiast
Enthusiast

DimVKir​​: Is this a lasting, permanent fix?  Or does it work around the problem until VMware updates their version of the VIB thus restarting the conflict?

Reply
0 Kudos