VMware admits 'time bomb' rolled past quality control
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 …
Oops
The "we must maintain control over our users" reflex seems to have bitten EMC on the bum.
What a shock.
Even the link on the Express Download fail
"Fix of virtual machine power on failure issue, refer to KB <1006716>"
...so it wasn't only Grouse that was being shot down yesterday!
It's easy to ensure this does not happen again.
just remove your crap DRM and *voila*.... Problem solved.
and these same companies want congress to grant them the ability to perform "self help" by allowing them to remotely disable anyone's software.
Digital Restriction Management isn't just for music remember, but anything where the makes decide your money isn't enough, they want to own your data too.
Make it stop: http://defectivebydesign.org/
And this is the first product pushed out the door?
What does this tell us?
I experienced firsthand how unreliable clock is in a virtual machine. If it's legal requirement to timestamp transactions, such process should not be hosted on a virtual machine in the first place.
Heads will roll, nothing will change. Welcome to Palo Alto.
This release was only made available 2 weeks ago, Do you mean to say that all the companies affected by this had managed to complete full testing of this release in an environment which would not affect their live systems? Doesn't sound like it. Especially if those companies are running critical systems on ESX, then to be honest they are partly at fault. I'm sure they don't do it with Microsoft, so why with VMWare? The first rule in running systems like this is test, test, test and then test again. The testing may not have shown up the bug, but if they had spent more time on testing it, it would have shown up when the dates change.
I don't think DRM was an issue here, and I don't understand why folks think it is. 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.
That's all, move along.
So glad we use Virtuozzo for our virtual machines here at work. So, so glad.
This is hardly VMwares first product... they've been on the virtualization scene for a very long time.
Mistakes happen, but anyone who runs a mission critical server in a VM is just asking for trouble.
Judging from Mr Maritz' letter, and discussion on the Communities page yesterday, it looks like it was regressed code, perhaps from the beta release. so we're talking about something that got regressed in by accident at some point before or at Update 2. Which means it:-
- predates Diane Greene's departure, and
- has nothing to do with DRM
It also means the whole thing was caused by perhaps one software engineer changing the wrong bit of code around, and that testing would always fail to spot it, unless the testing involved scanning code for beta time-stamps.
It must be safe to say that VMware will be making sure that all code is checked for this from now on!
"but anyone who runs a mission critical server in a VM is just asking for trouble"
Anyone who runs a mission critical server on bare metal that can't be immediately snapshotted and migrated to another piece of hardware is asking for trouble.
The screw up was nothing to do with VM, it could just as easily have happened in the OS or DB - and frequently has.
The best solution in my opinion is if future timebombs are limited to disabling only advanced features of the product, not basic functionality like powering on VM's.
It seems increasingly silly to limit things that much, because if users want a free hypervisor there's now ESXi, as well as VMware Server, plus Xen and MS.
VirtualConsole, vmotion etc. is VMware's value add, and I see why locking that down is fair.
"anyone who runs a mission critical server in a VM is just asking for trouble."
Listen up Solaris sysadmins! Stop using Zones this very instant! Tony Lewis said he's going to cause you trouble!
So have I. That's why - irregardless of virtualisation - all my servers sync their time with a multitude of time servers, every five minutes. Any good sysadmin should know that.
For all those wondering:
Seems like they had troubles with 'kb2' after they had long time trouble with the usual 'kb' server.
Replacing 'kb2' with 'kb' in the failed URL brings you to the same page on the other server respectively.
http://kb2.vmware.com/kb/1006721.html
equals
http://kb.vmware.com/kb/1006721.html
But as of now both servers just started responding again.
DRM stands for Digital Rights Management. "Rights" as in those of the customer as well as the vendor - their right to use software/data that they've paid for in the face of others that would illegally gain access to it had those rights not been enforced.
Not that DRM has anything to do with this case, but slagging off DRM universally is not the correct approach.
Criticizing poorly implemented DRM that allows a vendor to abuse customers' rights is what we need to fight against.
Wow. You really bought into the industry propaganda. DRM has nothing to do with the rights of anybody but the publisher.
Run-time licensing is a form of DRM, and the expiration of said licensing due to a bug would definitely make this DRM related.
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"!
"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.
Sign up, sign up for Blocks and Files, The Reg's weekly storage newsletter
