His unprofessional and offensive response was removed, please try and act in a civil manner in these forums or we may be forced to lock user accounts and/or this thread.

Eric Siebert
VMware Communities User Moderator
-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-
Check out my website: VMware-land
Read my virtualization blog: SSV Blog
-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Anyone that says we patched to early is wrong... People exploit vunerabilities in days and therefore its best to update as soon as possible, we did our testing before updating and we were happy however here I find myself working late to reinstall our esx servers to protect us from any sort of risks or esx servers falling over during office hours.

We put our faith in a company like vmware to release stable updates that can be used in multi million dollar bussinesses however today we found out we were wrong

Wow, a lot of emotion out here today! I agree, this sucks, but, unfortunatly it happens to the best. I saw some post about poeple being foolish for applying the update so quickly, well, ponder this; you applied Update1 2 months after it was out, and then today you find it has this drop-dead date of August 12th. Where you foolish for applying that? No, not at all.
My company has a policy that patches and updates will be applied within 30 days, regardless how I feel about it. So I got hit by this bug, but, instead of panicking of attacking the QA folks at VMware, I've been pondering how to solve this problem.

So, if anyone else has posted this solution, then I am sorry for repeating.

I totally agree that changing the date is only a small step in the workaround. So, here's what I am planning to do to fix this since it seems that only the target server is effected, not the host server.

1) Change the date on 1 server in your farm. Luckily I have a spare server I can put into the farm temporarily.
2) Shut off DRS and HA
3) Manually move the VM's from 1 host to this temp host.
4) Place the host you just moved all your VM's off of in Maintenance Mode and remove from Virtual Center.
5) Reinstall ESXi U1 on the host you have removed from Virtual Center.
6) VMotion the VM's from another U2 host to the new U1 host and repeat steps 4 & 5 until all hosts in the cluster are at U1.

Problem fixed, you are now back on U1 code that AFAIK is stable. This will allow VMware to properly fix and test the U2 code before releasing it, and ensures that you are still able to run. For validated systems (those that can't have the clocked changed), I would have a discussion with your legal department to ensure that the time requirements extend all the way down to the host, or just stop at the guest OS. Most legal departments have not taken into consideration the seperation of guest and host OS in the virtual world. It's a grey area to be addressed.

Hi everyone,

hope that the bug is being fixed right now. Do you know, if I can Update my ESX U2 Servers with the Update Manager to fix the problem or do I need to install the ESX Servers new???

regards

Since this is the thread we're all hanging out in, let's get a poll going on how big of a headache this actually was for you:

1) How big is your virtual infrastructure and what advanced VMWare features do you use?

2) How many minutes of downtime did your production/test environment suffer?

3) Are all your VMs back up and running now?

4) What solution have you employed? And any other relevant information.

I'll go first.

1) 5 ESX hosts with 70 VMs. I use DRS and VMotion.

2 and 3) No downtime as I haven't shut down anything.

4) I expect to be able to wait until the end of the week when paches come through update manager. If a VM did by chance get shut down I will use the date reversal fix.

Philip Arnason

Since this is the thread we're all hanging out in, let's get a poll going on how big of a headache this actually was for you:

1) How big is your virtual infrastructure and what advanced VMWare features do you use?

-------Not too big, but management has decided to put very critical servers in a virtual environment. I dont have to deal with it enough to really have issues.

2) How many minutes of downtime did your production/test environment suffer?

-------None so far, hope it stays that way.

3) Are all your VMs back up and running now?

---Never went down except for our test vm's which I already had off from the 3.5u2 update the other night.

4) What solution have you employed? And any other relevant information.

--Right now Im just waiting for VMware to fix it. If somethign happens I'll just bring up one of my nightly backups and run it from my computer. We spend a lot of effort making sure we can handle disasters properly.