Luckily only 2 out of our 18 servers (the two I recieved last week) are running 3.5u2... The rest of the infrastructure is on 3.5U1 (95350).

It seems that the bug is affecting only the destination server (i.e. if the target is 3.5U2) because I was able to move out the 3+4 VM I had on the 3.5U2 servers back to 3.5U1 servers using VMotion and put the 3.5U2 in maintenance mode and bring them out of the DRS/HA cluster.

I just prefer not to imagine what could have happen if I finished the upgrade as I planned and the 200+ VM's we have would have been affected .

What really piss me off is the lack of communication from VMware directly as they have full lists of customers who registrated licenses and downloaded the binaries !!!! For cases such as this one I would have expected some kind of direct communication notifying those of us who luckily could benefit from the lessons learned from our colleagues in Australia who were hit first.

Thanks to all early publishers for sharing their experiences and keeping us informed.

BR Ludovic

Cheers

Lars

I think you should prioritize a PATCH for those stuck in this hell, instead of creating new isos.

This allows you to repair your logs easilly using a search/replace function later.

Be advised however that MOST compliance related logging occurs on the VirtualCenter server.
DO NOT CHANGE THIS DATE!

VirtualCenter server dates do not have any relation ot the problem.
Furthermore, MOST VC servers are members of Domains, and if you set this time back (even to the 10th) you will not be able to log on to the server, as Active Directory will fail on this server, and/or at the very least, the NTP client on the server will RESET the time back to correct.

Basically, there is no need to reset the VC time, but I reccomend a full year or two rollback on the ESX hosts, for ease of log repair at a later time.