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!

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.

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.

"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!

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.

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.

after Y2K bug flopped.