Hi guys,
As vmware support points out, the setting of the host clock trick can be fatal for lots of us, causing many things to break within the vm's. So, here is a thought I'd like to share. If your vm's won't start, login to the unsupported console, and use the date command to set the date back a couple of days or so, then boot your vm guests, and immediately and I mean immediately, set the date back to current time, back in the host console. This would mean that the time/date discrepancies on the vm's will be minimal, if not none. We've done this here with success on a fairly sizeable virtual infrastructure and we seem not to have any problems. But keep in mind that the time on the host should be set back very quickly, preferably before the OS's in the vm's actually boot (like while the vm is in POST or thereabouts). This method means you don't have to turn off time sync from guests, or stop NTP update from the host, or any other config within running guests (which would of course be running in the 'past').
Setting the esx host time to before 12 August alone seems to have allowed us to boot all our vm's without that damn error, and if you can 'pause' at POST from the VM's (hit pause/break, F2 and enter vm bios or whatever), and while all VM's are paused set the esx host time back to normal, all machines will be already running. Might be an idea to CTRL-R and issue a reset to the VM's before they start booting their os's.
Let me know how you guys go with this, especially those of you who are hosting DB, AD, and other time critical applications on your vm's that are likely to break; i'd appreciate finding how successful this method is.
May the force be with the wonderful team at vmware in trying to fix this issue for all of us.. Thanks guys, and god speed..
-yarrix
ps: btw, we almost only exclusively run esx3i, but i'm quite certain this should work the same for esx3.5. let me know...
