« PowerShell Script for VDI Mass Replicas | Main | SVVP - Thank goodness! »

August 13, 2008


Feed You can follow this conversation by subscribing to the comment feed for this post.

Ryan B

Change control is, of course, essential for any production environment. But I personally haven't encountered a lab test script that includes rolling forward the clock on lab systems to catch something like this.

In this case the bug manifested itself around 2.5 weeks after release of the patch? I don't know the technical details, but could it just as easily been 2 months?

So I guess what is the "right" amount of time to wait before installing an update.


This is similar to the issue we had with the 59330 code build of ESX 3.5 which was time-bombed back in February. VMware's response to that event was disheartening, but I'm much happier with the stance they have taken with this issue.

In the words of Alfred Pennyworth: "Why do we fall, sir? So that we might better learn to pick ourselves up."

And so they have.


This was a ridiculously stupid thing to let out and I'm on the fence as to if someone should get the chop as a result of it.

(Not my call, I'm not an employee of VMWare)

But are they shipping a crappy product? No. They just did something incredibly dumb.

Load both barrels. Point at feet. Fire.

People either see that it was an example of epic fail and take them at their word it won't happen again or they move off to another vendor.

As an Admin I never had time for the complainers who'll do neither.

Neo Writer

I suspect that if all ESX users were polled, a very small percentage of companies actually run the very latest version. We tend to be right at the leading edge with ESX and even WE don't have the very latest in production. We do have it in the lab, and it caused very little trouble for us.

However, when you have come to expect the best, as we have with the quality of VMware software, any glitch is glaring and surprising (even if not catastrophic) - especially if you are fortunate to have someone in your group who drinks only Microsoft Kool-Aid.

I believe, as others have stated, that we need to judge VMware on how they react to the mishap before we get too concerned. It's the first chance to see how the new leadership responds to such quality challenges. And, Goodness knows, he had a lot of opportunity to react to shipped software bugs at one of his former employers...


If you're going to have time-expiring licences, always offer a grace period before they expire.

i.e. Start displaying prominent warnings that the licence is about to expire at least a moth before the expiry date. That way, people notice before functionality is lost.



This one caught about half my sockets in production. We had been testing out update manager and using DRS to demonstrate zero downtime upgrades. It was a great demo to management but an epic fail a week later when things went wrong.

To add insult to injury Update Manager decided it didn't want to talk to its database and stopped working half way through applying the emergency patch. Thankfully I started with these things before update manager came around so I just dropped the patch on the box and fired it off.

Not a good infrastructure week.

Chad Sakac

- 'Zilla, you and Barry remind me with every post/comment that there's not a "no extremophiles allowed" sign on EMC buildings :-) It's OK, I love you anyway

- Neo, I'm with you, but on the other hand, when you have hundreds of thounsands of customers, something that affects 10% is still ten thousand customers. This gets hard as you get big, and VMware is now BIG.

- Phil, I hear you, and I agree, but to be clear - this wasn't a time-expired license, it was time-expiration built into a pre-release code that slipped into the GA build. Maintaining build trees is critical as well as regression testing, but the only license timeouts in GA VMware products are on evals, not the real deal (at least as far as I know).

- John - ouch. All I can do is express my sympathy. I'm glad you were able to apply the express patch quickly.

Daniel Eason

This is a tough issue, in my view it was dealt with by VMware promptly, if anything my only complaint was the lack of update, however I trusted them (as usual) and they delivered a resolution.

Maybe this will change how beta/patches get released in future.

ALso i sincerly hope it dosnt change the way VMware approach providing constant improvements and additions via update patches as this is what makes them and the developer team just so dam good!


As a fan of VMware's products, this was disheartening for me also.
As a VMware customer, I wasn't happy about it, but I also hadn't deployed it into production yet. I tend to take a more conservative approach to deploying patches. Heck, let everyone else find the bugs and problems it creates - I'd trade "stable" for "new" any day.

I wouldn't let others get you down. One of the things that help me maintain the proper context here is remembering that "it's easy to pick on the big guy". This includes all big players in their markets: VMware, EMC, Microsoft, etc. They have millions of customers so their mistakes will become world famous at the speed of the Internet. It's the nature of the beast. Just remember not to lose sleep over the nay-sayers that are just using it as an opportunity to nay-say.

The comments to this entry are closed.

  • BlogWithIntegrity.com


  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.