Hi again,
In my previous post I wasn't clear enough with the workaround I proposed:
If you want to be proactive, I suggest you find the ESX server hosting the less domageable VM's you have (maybe one hosting only dev servers, or the >one with the least VM's or the one where customers are the most tolerant) and stop all VM's on it (an orderly shutdown is always better than a crash), >restart them elsewhere on 3.5U2 and downgrade the empty box to 3.5U1. You can then use VMotion to move VM's from another ESX 3.5U2 server (it is >working, i tested it) and perform a "rolling downgrade" of your infrastructure. Re-installing ESX should not take more than one hour and you will be in a >much better situation when VMware release the fix, regardless of the form it will have, ISO, RPM ...
When I wrote "restart them elsewhere on 3.5U2" I meant "restart them elsewhere on 3.5U2 where you applied the workaround, i.e moving back the date" if you really can't avoid it.
I strongly suggest that anyone not wanting to wait 36 hours or more for a fix apply the workaround I described because time keeping is really a critical problem for a number of applications (as of now i can think of database, SAP even Kerberos....). A "not so planned" orderly shutdown is far better than data inconsistencies in your environment.
P.S. you can leverge this opportunity to apply Microsoft patches on your VM's (or Red-hat, or...)
Hope this helps, best regards,
Ludovic