Upgrade VMware 5.5 to 5.5 Update 1 – Error conflicting VIB’s

October 10, 2014 Leave a comment

Problem: Attempted to upgrade VMware 5.5 to 5.5 Update 1 – Error conflicting VIB’s
The upgrade contains the following set of conflicting VIBs;
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.

Explanation:
Actually the problem is NOT the net-bnx2 package, but the net-cnic package it depends on. Or to be more precise, it looks like a problem during the ESXi update procedure to interpret version numbers correctly.

You can see that if you check the esxupdate.log or manually try to update net-bnx2 it with the –update option:

# esxcli software vib update –vibname net-bnx2 –dry-run –depot /tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip

[DependencyError]

VIB Broadcom_bootbank_net-bnx2_2.2.5d.v55.2-1OEM.550.0.0.1331820 requires misc-cnic-register = 1.7a.02.v55.1-1OEM.550.0.0.1331820, but the requirement cannot be satisfied within the ImageProfile.

Please refer to the log file for more details.

So our net-bnx2 driver needs at least misc-cnic-register = 1.7a.02.v55.1-1OEM.550.0.0.1331820, but that package is in the bundle. Hm.
Next step, what net-cnic version do I currently have on my host?
# esxcli software vib list | grep -i net-cnic

net-cnic                       1.72.52.v55.1-1vmw.550.0.0.1331820     VMware           VMwareCertified   2013-11-21

Ok, we got 1.72.52.v55.1-1vmw.550.0.0.1331820 here. So the battle boils down to version string 1.7a vs. 1.72. Might be a bit ambiguous.
Now let’s ask our ESXi host about what he assumes is the newer driver (make sure you scroll to the right to the Status column):

# esxcli software sources vib list -d /tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip

Name                Version                             Vendor    Creation Date  Acceptance Level  Status
——————  ———————————-  ——–  ————-  —————-  ———
net-cnic            1.7a.05.v55.3-1OEM.550.0.0.1331820  Broadcom  2014-03-04     VMwareCertified   Downgrade
scsi-bnx2i          2.7a.03.v55.2-1OEM.550.0.0.1331820  Broadcom  2014-01-31     VMwareCertified   Downgrade
net-bnx2x           1.7a.10.v55.1-1OEM.550.0.0.1331820  Broadcom  2014-03-04     VMwareCertified   Downgrade
scsi-bnx2fc         1.7a.08.v55.1-1OEM.550.0.0.1331820  Broadcom  2014-04-17     VMwareCertified   Downgrade
misc-cnic-register  1.7a.02.v55.1-1OEM.550.0.0.1331820  Broadcom  2013-12-21     VMwareCertified   Downgrade
net-bnx2            2.2.5d.v55.2-1OEM.550.0.0.1331820   Broadcom  2014-03-27     VMwareCertified   Update

Oops! All drivers contained in the bundle except net-bnx2 are actually being interpreted as version downgrades! Which is not quite correct though. The host doesn’t see any need to update these packages with the –update switch
# esxcli software vib update –vibname net-cnic –dry-run -d /tmp/BCM-NetXtremeII-4.0-offline_bundle-1796156.zip

Installation Result

Message: Dryrun only, host not changed. The following installers will be applied: []

Reboot Required: false

VIBs Installed:

VIBs Removed:

VIBs Skipped: Broadcom_bootbank_net-cnic_1.7a.05.v55.3-1OEM.550.0.0.1331820

So what’s basically happening causing these errors everybody has is:

The host looks through the metadata version information and compares it with it’s existing packages.
It assumes it can only update net-bnx2 while everything else is a downgrade, so only net-bnx2 is considered for the update process.
It checks the dependencies of the newer net-bnx2 driver, which say it needs at least net-cnic version 1.7a.
The host  reverses the comparison approach it just did when it decided the other packages including net-cnic are downgrades, and thinks the existing net-cnic version 1.72 is too old to satisfy this requirement.
It throws an error that it can’t update net-bnx2 (because of this dependency).

Apparently the ESXi updater gets confused by the ambiguous 1.7a vs 1.72 version strings conundrum. I don’t know what’s the general industry standard on versioning when it involves letters, so  either VMware/Broadcom/HP messed up when naming these new versions or the ESXi updater is buggy when interpreting them.

Resolution:
1) Log into the host (we did this from the console via ESXi Shell)
2) Remove all broadcom components.  The order of removal was important due to dependencies.  We tried removing just bnx2 and bnx2x but got the error again, so we took them all out
esxcli software vib remove –vibname=net-bnx2
esxcli software vib remove –vibname=net-bnx2x
esxcli software vib remove –vibname=net-tg3
esxcli software vib remove –vibname=scsi-bnx2fc
esxcli software vib remove –vibname=scsi-bnx2i
esxcli software vib remove –vibname=net-cnic
esxcli software vib remove –vibname=misc-cnic-register

3) Reboot host to iso
4) Run the upgrade, preserve datastore -> reboot host
5) Remediate via the vsphere client if necessary. We did
6) Exit maintenance mode, start vm’s and the upgrade is complete

Restarting the Management agents on ESXi

October 10, 2014 Leave a comment

Problem: Restarting the Management agents on ESXi

Solution: To restart the management agents on ESXi:

From the Direct Console User Interface (DCUI):
Connect to the console of your ESXi host.
Press F2 to customize the system.
Log in as root.
Use the Up/Down arrows to navigate to Restart Management Agents.

Note: In ESXi 4.1 and ESXi 5.0, 5.1 and 5.5, this option is available under Troubleshooting Options.

Press Enter.
Press F11 to restart the services.
When the service has been restarted, press Enter.
Press Esc to log out of the system.

From the Local Console or SSH:
Log in to SSH or Local console as root.
Run these commands:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

Note: In ESXi 4.x, run this command to restart the vpxa agent:
service vmware-vpxa restart

Alternatively:
To reset the management network on a specific VMkernel interface, by default vmk0, run the command:
esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0

Note: Using a semicolon (;) between the two commands ensures the VMkernel interface is disabled and then re-enabled in succession. If the management interface is not running on vmk0, change the above command according to the VMkernel interface used.

To restart all management agents on the host, run the command:
services.sh restart

Categories: vmWare Tags: , , ,

Changing VM NIC on VMware Virtual Machines from E1000 to VMXNET3

October 10, 2014 1 comment

Problem: Changing VM NIC on VMware Virtual Machines from E1000 to VMXNET3

Solution:

While the VM is running, add the 2nd NIC.

After Windows adds the NIC go into network and sharing, disable the NIC, and use the same static ip address info as the original NIC (you’ll get a warning, tell it to continue).

Go to the vSphere client and connect the NIC, then go back to the VM and disable the original NIC and enable the “new” NIC. Double check the IP configuration of new NIC, I found that the Gateway is sometimes missing.

Once this completes you should be connected without any problem (unless you have something bound to the mac address, but this can be changed in the NIC properties if you power down the VM).

If all is good, remove the old NIC from the VM (you may need to remove the IP configuration on old disabled NIC’s for VM removal) and once Windows removes the device open a command prompt as administrator and enter: SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 followed by devmgmt.msc when the command prompt returns,

Once Device Manager opens, go to view and check show hidden devices, then scroll down and remove the old NIC (which became a hidden piece of hardware when it was uninstalled).

Categories: Networking, vmWare Tags: , ,

WSUS Error – Windows Update Failed 80244017

August 13, 2014 Leave a comment

Problem

Using WSUS and clients getting an error on install – Windows Update Failed 80244017

Resolution

Even though Domain Users had Read/Write access I was able to fix this error by adding WSUSServer\users with read/execute privileges to the WsusContent folder and it’s subfolders.

 

Regedit.exe – File System Error (-1073741819)

July 11, 2014 Leave a comment

Problem: I was watching (via console) another administrator trying to run regedit.exe however the following error was occurring;

C:\Windows\regedit.exe

File system error (-1073741819)

Resolution: Turn off UAC.

Putting Exchange Server into Maintenance Mode

July 8, 2014 Leave a comment

Run PowerShell as Admin to put server in maintenance mode for patching or other work.

1. Set-MailboxServer “name of server” -DatabaseCopyActivationDisabledAndMoveNow $True
2. Set-ServerComponentState –Identity mtaexch01 –Component HubTransport –State Draining –Requester Maintenance
3. Suspend-ClusterNode –Name “name of server”
4. Set-MailboxServer –Identity “name of server” –DatabaseCopyAutoActivationPolicy Blocked

Take server out of Maint Mode

1. Set-MailboxServer –Identity “name of server” –DatabaseCopyAutoActivationPolicy Unrestricted
2. Resume-ClusterNode –Name “name of server”
3. Set-ServerComponentState –Identity “name of server” –Component HubTransport –State Active –Requester Maintenance
4. Set-MailboxServer –Identity “name of server” –DatabaseCopyActivationDisabledAndMoveNow $False

Error: (unknown): TIMEOUT – READ_DMA retrying (1 retry left) LBA=493207

July 4, 2014 2 comments

Problem

I am running a pfSense 2.1.3-RELEASE-nanobsd virtual machine on VirtualBox as a firewall as part of my study network (great way to do domain labs etc. with access to internet without interferring with corporate environment).
The pfSense firewall would constantly get the following error and stop routing (would require a reset).
Error: (unknown): TIMEOUT – READ_DMA retrying (1 retry left) LBA=493207

Resolution

In VirtualBox settings of the pfSense vm, disable USB and/or remove Floppy.

Follow

Get every new post delivered to your Inbox.