Conflicting VIBs upgrading from VMWare vSphere 5.1 to vSphere 5.5 U1

I had a DL360 Gen8 server running VMWare vSphere 5.1 which was installed using the HP custom image. When trying to upgrade this server to vSphere 5.5u1 using the new HP ISO, the upgrade failed with the following error message:

The upgrade contains the following set of conflicting VIBs:
Broadcom_bootbank_net-bnx2_2.2.5d.v55.2-1OEM.550.0.0.1331820
Broadcom_bootbank_net-bnx2_2.2.5d.v55.2-1OEM.550.0.0.1331820
 
Remove the conflicting VIBs or use Image Builder to create a custom upgrade ISO image that contains the newer versions of the conflicting VIBs, and try to upgrade again.

It seems that the version of the broadcom drivers in vSphere 5.5u1 are older than those included in v5.5 and v5.1u2.

As a workaround, upgrade the host to v5.5, then downgrade the broadcom driver to 2.2.5d, and upgrade the host to v5.5u1 again. It might not be the easiest solution if you have many hosts to upgrade but in my case there were only two so this was the fastest.

  1. Download http://vibsdepot.hp.com/hpq/jun2014/esxi-550-devicedrivers/BCM-NetXtremeII-4.0-1796156.zip and extract the BCM-NetXtremeII-4.0-offline_bundle-1796156.zip
  2. Copy this file to /tmp on the ESXi host
  3. Run esxcli software vib install --depot=/tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip

After a reboot, upgrading to 5.5u1 should now work as expected.

Blog Category:

hpacucli on esxi 5.5 - no controllers detected

After upgrading a Proliant DL360 Gen8 ESXi host from vSphere 5.1 to vSphere 5.5, I noticed that the hpacucli command no longer worked. Instead of providing the usual output, it failed to detect the controllers:

~ # /opt/hp/hpacucli/bin/hpacucli ctrl all show status
 
Error: No controllers detected.

The solution is quite simple, instead of using hpacucli, use hpssacli instead:

~ # /opt/hp/hpssacli/bin/hpssacli ctrl all show status
 
Smart Array P420i in Slot 0 (Embedded)
   Controller Status: OK
   Cache Status: Temporarily Disabled
   Battery/Capacitor Status: Recharging

Blog Category:

Mobistar iPhone tethering possible again (personal hotspot)


Mobistar has always blocked tethering on their network. Years ago their was a workaround but that was only for very old iOS versions.

Today, it is once again possible to enable tethering. This time without "hacks". Rumor has it this will be officially announced on monday but the functionality is already working. All you need is an up-to-date iOS version and the latest carrier update.

To obtain the latest carrier update, go to Settings > General > Usage. Here a popup will appear asking if you want to install the carrier update.
Select update, and as soon as you have done that, the Settings > General > Network > Personal Hotspot item should appear.


Configuration is quite simple. At the top of the page, enable the personal hotspot.
You will be asked if you want to use USB or Bluetooth/Wireless. USB requires iTunes to be installed on the computer, if you use this option, don't forget to disable the hotspot after use, otherwise the computer will use it every time the iphone is connected.
Wireless/Bluetooth are especially useful if you want to use a second device to access the internet (such as an iPad), or if you don't want to install any additional software on your computer.

The main disadvantage for now is the poor 3G coverage of the mobistar network. In most of the places all you get is Edge, which is enough to synchronize email but to slow for anything else.

Juniper SRX global security policy - revisited

Quite a while ago I wrote about creating a global policy using apply-groups. It works, but its main disadvantage was that it only logs traffic if there is at least one permit rule between the source and destination zones.

As of Junos 11.2, a global firewall rulebase can now be configured. Just like the netscreen global rulebase, this only gets evaluated if there is no match in the regular rulebase. So, it can be used to create a default logdrop rule like this:

[edit security policies global]
    policy default-logdrop {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
            log {
                session-init;
            }
        }
    }

When traffic does not match any of the permit policies, it is now logged in the following format:

RT_FLOW - RT_FLOW_SESSION_DENY [junos@2636.1.1.1.2.39 source-address="10.199.6.91" source-port="5947" destination-address="194.178.10.7" destination-port="80" service-name="junos-http" protocol-id="6" icmp-type="0" policy-name="default-logdrop(global)" source-zone-name="trust" destination-zone-name="untrust" application="UNKNOWN" nested-application="UNKNOWN" username="N/A" role="N/A" packet-incoming-interface="fe-0/0/8.6"]

The global policy works fine for a default logdrop rule, but when you want to specify specific source or destination addresses in a rule, things get more interesting. The addresses need to be defined in the new global address book at [security address-book] instead of the zone-specific ones. Unfortunately, the two cannot be combined. If you try to commit this change, you'll see error messages like this:

[edit security zones security-zone untrust]
  'address-book'
    Zone specific address books are not allowed when there are global address books defined

So you will have to convert all your address books to the new style, which is quite a bit of work.

Blog Category:

Pages

Subscribe to Bart Jansens RSS Subscribe to Bart Jansens - All comments