X
Business

Timebomb in VMware's ESX 3.5 and ESXi 3.5 (Update 2)

VMware appears to have neglected to remove the timebomb, that is software that stops a product from running on a specific date and time, from its VMware's ESX 3.5 and ESXi 3.
Written by Dan Kusnetzky, Contributor

VMware appears to have neglected to remove the timebomb, that is software that stops a product from running on a specific date and time, from its VMware's ESX 3.5 and ESXi 3.5 (Update 2) software when the company transitioned the software from beta test to the released product. This meant that when the system clock stuck 12:00 AM on August 12th, the license expired. So, virtual machines running on these hypervisors could not be powered on when they were turned off, awakened when they were suspended or moved from one machine to another using VMware's Vmotion technology.

This little issue, of course, could play havok with production systems if someone was foolish enough to put a new version of software into production without testing it. Paul Maritz, CEO of VMware, posted an apology here. The company has released an "express patch" to fix the technical problem. It is not at all clear these moves are enough to rebuild organizations' trust in VMware's development and distribution processes.

I've never been one to like timebombed software. I know of many cases in which the timebomb was triggered by some sort of failure, bad coding of the timebomb itself or some other issue. The fact that a company would put a timebomb into their software shows that it presumes that their customers are not to be trusted to move from beta test software to the final version when it becomes available. I don't know about you, but I don't like working with suppliers that treat me like I'm a thief or work with them in bad faith.

I believe that, in the end, it would be very wise for organizations to wait a bit before installing new versions of software when they are made available by suppliers, such as VMware. It is also very wise to test important pieces of software prior to deploying them into production environments.

VMware, it would be wise if you would tell your customers what you're going to do about this, when you're going to do it and then publish status reports until you've accomplished whatever changes you're planning to make. This, it would seem, is the minimum necessary to rebuild your customers' trust in you and your development processes.

Editorial standards