Today we have another guest post from Tech Support Engineer Mike Bean.

'Morning everyone, I must take a moment to say thank you to people, both internally and externally, who’ve expressed support for the first column I wrote. To quote a web comic I enjoy, “we must learn, lest we stagnate”, if readers have enjoyed it as well; then I take that as a compliment!

At the risk of digressing from the “most wanted theme”, I wish to approach a new subject today. By the time you read this, ESX vSphere update 2 will be publicly available.

I gladly extend congratulations to all our development and QA teams the world over. I can say with complete sincerity they’re my heroes, for it is on their backs that our product is built, one feature spec and bug report at a time. Congratulations lords and ladies, hug your significant others, have a beer, and enjoy the moment. You’re our warriors!

I began my morning with a soda and a copy of the release notes, and I can safely say, it’s not light reading. Speaking as an army-ant in Global Support Services, I don’t see any issues we’ve been breathless with anticipation for, but there’s also far too many things being addressed to engage in any sweeping generalization.

In the course of my time here, I’ve often been asked the eternal question “should I get the patch?” I’m never quite sure how to answer this question, but it’s honestly one worth asking. So it’s worth taking a moment to examine.

Asking a software company if you should apply the patch is a little like asking a lawyer if you should sue; let’s face it, we have a slight bias. On one hand, if we didn’t think our customers would benefit, we wouldn’t have released the patch in the first place. On the other hand, many of my customers are system admins, and I’ve walked a mile in their shoes. In that sense, I’m well aware that they don’t have the liberty of applying patches/FW flashes whenever any number of numerous vendors they do business with, releases the latest update. My college economics classes would’ve called it “opportunity cost”. Downtimes must be scheduled, approvals must be obtained, benefits assessed. It is precisely because I have experienced both the software development point of view, and the system administration point of view, that I’m well aware that many of our customers may not have had problems. Risk is relative, myself and my co-workers routinely speak to customers who’ve literally ran for years without issues. Why then, upgrade?

Typically, when a customer asks me that question on the phone, I often end up trying to explain that I can’t really answer that question. It’s the natural course of software development that a changing code base means a changing landscape. Old problems are solved, and new ones arise, and I won’t imply to the contrary. However, that should not be interpreted as carte blanche to never patch. Risk may be relative, but as available security and stability fixes accumulate, so does risk, and so does benefit.

It’s a matter of risk assessment, as a GSS TSE (technical support engineer) it’s my responsibility to try and help present the facts and the options, but ultimately, the final decision always belongs to the customer. Only they know their networks, and basically, only they can realistically decide when the benefits of patching will exceed the costs. Inevitably, the only safe policy is one of shared information (informed consent); In that spirit, I encourage most everyone I speak to familiarize themselves with the available resources, both in documents and communities. Examine the facts for yourself, and let the update speak for itself.

In closing, I would briefly highlight at least one real case from memory. I spoke with a customer some weeks ago who’d been having substantial issues with hangs on his cluster of Dell 2900s. I sincerely hope he’s watching update 2’s contents, very carefully!

VMware ESX might fail to boot on Dell 2900 servers
If your Dell 2900 server has a version of BIOS earlier than 2.1.1, ESX VMkernel might stop responding while booting. This is due to a bug in the Dell BIOS, which is fixed in BIOS version 2.1.1.

Workaround: Upgrade BIOS to the version 2.1.1 or later.

You spoke, and we were listening! Till next time!