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?
4 hosts - 75 vm's - DRS - VMotion
2) How many minutes of downtime did your production/test environment suffer?
0:00
3) Are all your VMs back up and running now?
Yes
4) What solution have you employed? And any other relevant information.
Waiting for the patch. Will use the date regression if necessary.

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

1) 24 hosts, 205 VMs, DRS, VMotion, HA
2) 0:00
3) yes, never went down
4) None - we dont reboot VMs very often.

--Matt

1. 6 Hosts (8 way single core/32GB Ram), 1 VirtualCenter Server, 330 VM's (all production)
2. Zero Downtime
3. Still Going
4. Haven't upgraded to 3.5 U anything yet.

Jase McCarty
http://www.jasemccarty.com
Co-Author of VMware ESX Essentials in the Virtual Data Center
(ISBN:1420070274) from Auerbach

This isn't the first time Beta time bombs have been left behind. They seldom live long past the release date so these things can be somewhat anticipated and planned for. Having a patch policy of applying patches based on date or without thorough understanding of what they apply to is very poor policy. Relying on some company for the safety of your data WILL get you in trouble and over and over. A good compliance auditor will tell you that it isn't just about applying patches. They MUST solve a problem that YOU have and the security risk must be something that you are at risk for or don't apply them.

The old saw "If it ain't broke don't fix it" somewhat applies although now you must truely understand what the broke is.

There's no way to find this problem. QA can't do exhaustive testing just because there are many ways to implement functionality and there is almost infinite number of possible tests. I think engineer who hardcoded 12th of August and forgot to remove in release already got his "prize" from management.

New SAN and two ESXi Servers - 72K
Migrating 7 of 35 VM's from GSX to ESX - 3 days

Training IT Staff and finding out there is a bug when trying to create a new VM - PRICELESS

Reports of problems with ESX 3.5 U1 with the following 3.5 Update 2 patches applied: ESX350-200806201-UG

So, does anyone know what the build number would be if you've got 3.5 U1 with that patch applied? I don't normally maintain the patching on our VM environment and just want to make sure this isn't affecting or won't affect my production environment.

Oh, and I agree, VMWare could have at least sent us an email regarding this issue. I'm not trying to flame or get into it too much, but I believe that would have been good customer service. Allowing me to potentially do some work on my machines and maybe or maybe not find this problem on my own seems very much like a tactic to 'handle' the problem through obscurity.

Thanks,

D.

Free Admission would be nice.