If you’re a Dell sort of person you’ll be happy to know that version 5.4.0 of the Dell OpenManage Server Update Utility DVD works under VMware ESX 3.5. Older versions didn’t work, which made firmware management more difficult.
I don’t currently run the OpenManage suite of tools. Instead, I copy the SUU DVD contents to an NFS share, and I have a shell script which handles the mounting & unmounting, and updating my servers. I’m glad that the whole process works on ESX now, too.
 I might, in the future, especially as things like ESX 3i remove the OS.
Comments on this entry are closed.
Before Dell started supporting a bootable firmware updates CD with OM 5.3.0, I recommended HP for our VMware capacity. HP has had bootable firmware maintenance CDs for the ProLiants for years. With this additional support, Dell is finally doing more than just lip service with regards to ESX. Thanks for the note.
That’s great news. I just ordered 4 more Poweredge 1955 ESX boxes on Friday :)
Well…I’d love to know how you made it work. It’s not working for 3.0.2 Update 1 for us. I’ve been stuggling with accomplishing just that scenario (updating through a NFS share containing the DVD contents) to no avail. Everytime I run the suu script I get some “nullstem update in progress” message and then the application quits without updating anything. I’ve only been able to update through the Build and Update Utility boot disc.
It’s only compatible with ESX 3.5, as far as I can tell. :-(
The DUPs (Dell Update Packages) that are located in the ./repository directory on the SUU DVD (the .BIN files) will install under ESX 3.X.
The SUU (Server Update Utility) does not work fully under the service console. The comparison functionality works … so if you so ./suu -c , you will get a comparison report telling you what DUPs are applicable for that server. But if you do a ./suu -u or ./suu -p you will get the ‘null’ message mentioned above and a java exception error on the -p.
The SBUU (Systems Build and Update Utility) in conjunction with the SUU DVD will work, SBUU is bootable and uses the SUU for the packages to install. Of course you have to take the machine down to boot the SBUU.
I’m in the process of writing a script to query the system using ./suu -c and then grep out the package names to drill into the repository and install the DUPs (*.BIN). Keep an eye out for it on our Dell TechCenter site (http://www.delltechcenter.com)
Headed out for a doctors appt, so probably get to it first thing in the morning.
Great blog, btw, hope you don’t us linking back to you.
Awesome, thanks Scott!
Is there a way to bypass having to use multiple CD’s such as SBUU and SUU? Could the SUU be run under WinPE or BartPE?
I have tried to do so but it keeps hanging while searching the local machine for applicable updates.
Doctor said I need to lose weight (of course !). Finished up the script after struggling with regular expressions a little bit.
I posted it on my blog on our site, have to drive a little traffic our way too, right :-)
Or here’s the link directly to the script : http://www.delltechcenter.com/page/Script+to+deploy+Dell+Updates+on+ESX+3.x
Hope that helps.
Mark, I don’t know about Windows, but under Linux I’ve been able to copy the SUU CD contents to an NFS share so I can use it over the network and avoid CDs altogether.
OMSA 5.4 worked with ESX 3.5 perfectly on my production environment here.
Bob, how did you do this ? are you using PXE boot from server to access ? Please give me info since I have remote servers in multiple buildings that need to be rebuilt for testing. Thanks.
>By Bob Plankers on Apr 10, 2008 | Reply
>Mark, I don’t know about Windows, but under >Linux I’ve been able to copy the SUU CD >contents to an NFS share so I can use it over >the network and avoid CDs altogether.
one thing to note, I just ran suu -c (suu ver 5.5.2) against my ESX 3.5 host and it shows in the list of updates nic driver updates:
component: Broadcom NetXtreme II BCM5708 1000Base-T rev 12 (vmnic0)
component type: Firmware
current version: 4.4.1 – repository version: 4.6.8
Package name: NETW_FRMW_LX_R214709.BIN
Applicability: Package can be applied
I figure vmware should be the one controlling the nic driver version so if you do it fully automated (suu -u) then be aware that you’re possibly updating your linux nic driver.
For this reason I take the output of the suu -c and then just drop into the repository and run the updates that I want manually.
“component type: Firmware”
It’s not a driver.