VMware update is time-bombed
Pay up or else!
Tuesday, 12 August 2008, 13:25
VMWARE USERS got a nasty surprise today when a recent software update turned out to contain an extortionate licencing bug.
According to a post on a VMware community forum, VMware ESX 3.5 Update 2 tipped up this morning with the message "A general system error occurred: Internal Error."
Digging into the system logfiles, specifically /var/log/vmware/hostd.log found the somewhat embarrassing "Who let anyone from the marketing department code anything?" explanation " http://msg.License.product.expired".
The bug only shows itself at system startup, and the workaround is turning off the ntp time updating daemon and resetting the system clock back a few days. µ
L'INQ
VMware
Communities
Share this:
Advertisement
Subscribe to the INQ Newsletter
Sign-up for the INQBot weekly newsletter
INQ Whitepapers
Business Intelligence Software
Customer Relationship Management (CRM)
Enterprise Accounting Software
Enterprise Resource Planning (ERP)
Enterprise Systems Management
Jobs
Advertisement
INQ Poll
in New Zealand - wait until USA wakes up...

36 hours to patch a mistake like this - not a good call from VMWare at all...
Patches like that are similar to heroin. They are mighty addictive to the company.
Note that this only affects a small time frame during ESX bootup, when it checks the license. Resetting the date on the physical machine for that time window and then correcting it before VMs boot seems to be a good idea.

In any case, there are several solutions discussed in the thread linked above. Take a deep breath, then take a look.

On a lighter note, it's good to know VMWare's engineers aren't infallible: this is the first bug I know of in their code... :-)
Watch out if your DC's don't have an external time source and they're virtualised, could cause some serious issues if they're picking up hardware time like our are..
As per a previous VMware engineer said: As a former VMware engineer I know a bit about the build process, and unfortunately this being tied into the licensing code means that any fix likely touches a lot of different places in the code-base itself. There probably isn't going to be a simple patch, but something along the lines of a 3.5u2v2 bundle with all new components. This is one of the reasons why licensing that hobbles applications sucks, I wish there was a better way for companies to protect their interests without leaving their customers (and therefore themselves) at so much risk. The awful thing is that this bug wasn't reflected correctly in the UI, causing us to really dig to find the answer. I found this thread after about 3 hours of searching through logs and googling, when there was only a few posts on this thread. Let's hope the updated bundles are available soon. Expect Maintenance Mode/Reboot."

I highly suspect that the licensing schema will change - especially now that ESX 3i is *free* there is no need for this falsetto.

Anyway, a patch for this issue that requires a reboot is *NOT* acceptable in a production environment. 

The actual thread link is here: http://communities.vmware.com/thread/162377?tstart=0 and it grows as you read it. Talk about a living document. The KB article for this is down as i imagine they're getting pelted...or they're running thier kb servers on 3.5u2 already and cant start the systems in question..

G