VMware License Enforcement Bug Causes Chaos
This morning VMware infrastructure users worldwide discovered that VMware's update 2 for ESX 3.5 and ESXi 3.5 decided that their ESX licenses had expired when they attempted to start up virtual machines or use Infrastructure's Vmotion or DRS to move a VM from one ESX host to another. To put it bluntly, VMware customers had their VMware product stop working because VMware doesn't trust them and the copy protection code VMware built into its product did way more harm than any good it would ever do
This morning VMware infrastructure users worldwide discovered that VMware's update 2 for ESX 3.5 and ESXi 3.5 decided that their ESX licenses had expired when they attempted to start up virtual machines or use Infrastructure's Vmotion or DRS to move a VM from one ESX host to another. To put it bluntly, VMware customers had their VMware product stop working because VMware doesn't trust them and the copy protection code VMware built into its product did way more harm than any good it would ever do.While we don't know how many users were affected, we do know it was enough to crash VMware's knowledge base. Even our own Real World Labs were hit. At least that's how I interpret the message from Joe Hernick "Went back in the office, fired up the lab. VMs running on Lab ESX 3.5 update 2 = not start. Joe = sad."
While VMs that aren't moved or powered down will continue to run today, it's Microsoft's monthly Patch Tuesday, so lots of servers are going to be rebooted tonight and some of them won't come back when an admin takes the opportunity to rebalance their server farms. Clearly, if you haven't installed update 2, wait!! If you've downloaded it, delete it and wait for the fixed version.
VMware is promising a solution by noon Pacific time tomorrow, which is 36 hours after users in the Pacific time zone were affected and somewhat more than that since the first users on Gilligan's Island were affected. Until then, the best solution is to disable the NTP client on your ESX servers and roll the clock back to Aug. 10.
Of course, you'll also have to make sure that your guest machines aren't syncing with the ESX host and your ESX logs and backups are going to be out of sync.
While I'm glad there's a workaround, the fact that setting the clock back works means that VMware's copy protection software was crap to begin with. Even evaluations of games you download from the Web are smart enough to not be fooled by a clock setback.
Face it, VMware, I don't care how much you're losing to piracy, active license enforcement always costs too much. The medium-sized and large organizations that would/can/do buy infrastructure enterprise don't steal software. Consumers steal software, small businesses steal software -- organizations with 10 server administrators don't steal things like VMware.
I'm pretty sure the cost to VMware of writing and maintaining the copy protection system plus the cost to customers when it screws up is greater than the value of the VMware infrastructure the copy protection scheme legitimately stops from running.
About the Author
You May Also Like