VMware admits 'time bomb' rolled past quality control
Glum CEO says 'we're sorry'
Cloud storage: Lower cost and increase uptime
VMware’s CEO has blamed a chunk of leftover pre-release code for a bug that yesterday prevented virtual servers around the world from powering up when the clock hit 12 August.
Despite the company carrying out quality assurance of its product, VMware failed to spot that it had released the leftover bit of time-bombed code within the ESX 3.5 and ESXi 3.5 Update 2 final versions of its hypervisors that were released about two weeks ago.
VMware boss Paul Maritz apologised for the major balls-up. He said the code caused the product license to expire. And, worse still, he admitted that the problem had been overlooked in recent patches to the product.
The code time bomb prevented virtual machines from powering on or leaving suspend mode and unable to migrate using the firm's VMotion software.
Maritz said VMware has released an “express patch” for customers unlucky enough to have already installed or upgraded to ESX or ESXi 3.5u2.
Its temporary work-around requires sys admins to turn the clock back to kick-start virtual machines and imagine that 12 August was just a bad dream.
However, as we noted yesterday, a whole swathe of customers have grumbled that this is inadequate since it’s a legal requirement for most businesses to timestamp all server transactions.
The company, which claims to have "the industry’s most popular and reliable hypervisor", also plans to spit out a full replacement for Update 2 that should be used by customers who want to perform fresh installs of ESX or ESXi.
Here are a few choice words from a very sad-looking Maritz:
We are doing everything in our power to make sure this doesn’t happen again. VMware prides itself on the quality and reliability of our products, and this incident has prompted a thorough self-examination of how we create and deliver products to our customers. We have kicked off a comprehensive, in-depth review of our QA and release processes, and will quickly make the needed changes.I want to apologise for the disruption and difficulty this issue may have caused to our customers and our partners. Your confidence in VMware is extremely important to us, and we are committed to restoring that confidence fully and quickly.
Shares in VMware also took a hit yesterday, dipping more than five per cent on the New York Stock Exchange after news broke of the Palo Alto, California-based company's major code cock-up. ®
COMMENTS
Re: DRM not an issue here
"I don't think DRM was an issue here, and I don't understand why folks think it is."
Here's a quick primer on DRM, then.
"Most likely the problem was the beta of U2 had an expiry of 12 Aug and some fool didn't remove that code during the final build."
Having "an expiry" on something you've licensed from someone is a restriction, or if you buy into "R == rights" then it's something which supposedly protects the "right" of the vendor to deny you use of the software. Consequently, the users experience DRM because those "rights" are being managed (or mismanaged) at their expense: you have the vendor telling you exactly which software to use at any given time with no flexibility or trust placed in you, the paying customer.
"That's all, move along."
To DRM 101 in your case, I guess.
@Russell Jackson
I don't think Rob "bought into the industry propaganda", when he states:
"Criticizing poorly implemented DRM that allows a vendor to abuse customers' rights is what we need to fight against.".
The industry propaganda wanted (for a long time) to make us feel guilty for music that is not restricted, because "the artist" would be cheated that way. If he mentioned that DRM would be there to protect the income of the artist, THAT would be "buying into the industry propaganda"!
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
