awbc-au, I agree with part of you post:
the difference between the word "licensing" and "time bomb" is semantics in this case... even the vmware logs use the term licensing in the error message they output when the vm can't be started...
Not sure if I agree with this, ESX has some of the worst error handling I have ever seen, what the hell is a General System Error tell me? Not much.
I agree that technically the issue is caused by the time bomb, which revokes the "license", which causes the guests not to boot.. the problem is with the licensing code, whether it be a legitimate expired license or a timebomb it's the same thing and the result is the same.... if you forget to renew your license the same problem occurs, if your VC host goes down for a number of days (cant remember exaclty how many) and the host can't contact it this will also occur as well... VMWare wont let you start your guests until you re-license....
Exactly, it's a nasty cause-effect loop. The time-bomb expires the products, preventing the licensing module from running, and with out the licensing, you can't use Vmotion. The time-out is 15 days BTW.
Agreed the issue is an inconvience as works arounds can be put in place.. I can set the time back, rebuild the ESX server or even try and uninstall the U2 patch (as someone else mentioned) and all of these things will allow me to get the servers back online.. The issue with all of these things is either technical (ie you can't set time back for other reasons) or resourcing (ie you need to have someone perform those tasks, and I doubt an ESX rebuild can be done in 30 mins as someone commented...) by the time you reattach all the LUN's, setup agents, enable the SSH etc..etc.. this all takes time and needs to be paid for... especially compaines that don't have ESX skills in house and outsource.... Is VMWare going to cover those costs?
So my ESXi servers take about 30 minutes to install, I have established steps and procedures that are followed. The hardest part is setting up the VSwitches and such, but in comes Powershell to do the leg work for me. I do not believe something as critical as an ESX server should ever have anything other than itself on the box. No extra scripts, agents, etc. That sucker is too critical. Plus, the VMware pipeline only has the ESXi version available, so all these scripts will be a moot point, but that is not a debate I think anyone should have with anyone else, I have no clue what your environment looks like, or what your needs are, or what resources you have available. So with that, I will take my comments and concede the point.
Everyone is different,.. for some people it's not a big deal and they have commented as such with all the "dont get to worked up" posts.. for other people it is a major problem and is causing downtime that in some cases they can't control.... either way everyone is awaiting the patch and communication so we can get back to a reliable base again... personally we have very complex servers with scripts and all sorts of stuf that will take a long time to reconfigure... we also have a lot of them and to do it on all would take days.... It's a real shame that benefits for VMWare in having a common code library between the ESX and ESXi products means a time bomb meant for the free version slipped into the production ESX codebase and caused this error. Thats probably the biggest issue for VMWare to deal with, and hence my comment that a change in the licensing restrictions needs to be put in place, especially for the flagship ESX server, which is the product that generates the coin to be able to build the free ones i nthe first place..
I don't think it has anything to do with ESXi's free release, which was probably part of u2. I think it's just a bad coincidence.
