Just posted:
KB with a description of what happened: http://kb.vmware.com/kb/1006716
ESX Express Patches: http://www.vmware.com/go/esxexpresspatches
Let's close down the other thread, as it's getting really long and hard to navigate.
Letter from Paul Maritz: http://communities.vmware.com/thread/162713. Please post non-technical commentary here.
Please post further technical commentary about the patches in this thread.
Thanks. Rest assured that many people inside VMware are reading your feedback and experiences here.
Mine seemed to Download immediately - I'm not installing it until later today though so I have the night to recover if I hit any issues.
For us the download took about 5 minutes and then 10 minutes to fix the first host!
Once again: I want to thank all the vmware engineers that worked unter pressure on that big bug. The fix is quite good and needs no reboot!
it's ok.
Just to share
I used the Infratructure update to patch esxi 3.5 and all is well.
Started installing on our 11 Hosts this morning, so far so good, using Update Manager to Remidiate the fix and working a treat. Just having to do some jugling with VM's.
Thanks for all the hard work!!!
For us the download took about 7 minutes and then 10 minutes to fix the first ESX.
Thanks to all VMware team
rgds,
J.
@PaulMack:
You say the patch did not require a reboot.
Do you mean the host? (yes, I also found out that it doesn't reboot) Or do you mean the VMs?
I have a small 2-host cluster, Hopefully DRS in its infinite wisdom placed the critical machines on one of the hosts (!). So I didn't had any problems to stop the host with the non-critical VM and patch the host then moved the critical machines successfuly... Update manager completed all the process without problems. Thanks for the promptly fix.
This bug only affect 1 of my hosts. That host has 26 vm's running. I am planning to upgrade using VM Update Manager. Does anyone know if this patch requires the host to reboot. Do I need to shutdown the running virtual machines? Can I vmotion them successfully to another host?
I received them via the UM download (manually started in the Task List).
Dirk,
have you got past the Integrity Error message? Could you please share?
Thank you,
Irina
As a result for this command I get the message:
INFO: No -b specified, selecting all bundles in depot.
INFO: Configuring...
ERROR: Integrity Error!
Why "Integrity Error"? What is my mistake?
We had the same problem here, also with previous versions of "esxupdate". The solution is to change to the directory that contains the patches, and simply run "esxupdate update" there, without specifying the depot using the "-d" switch.
Tim
It was host reboot I meant.
Cheers
Paul
Hi David,
You will not need to reboot the host, but you will need to put the host into maintenance mode, which required there to be no VM's running on the host I am afraid.
Always good to have at lease two ESX hosts, so you have some HA.
A.
We also have 5 hosts affected (1 x AMD285, 4 x AMD8220). The AMD285 has no guests at the moment and was in maintenance mode, so I installed the timebomb patch with UM and it worked fine (no reboot of the host).
But now I have the next problem: these CPUs are only VMotion compatible if the appropriate CPU mask is set in the VM. Some of my VMs have set this CPU mask, there VMotion to the AMD285 went well.
Now I wanted to change the CPU mask on other running VMs (in earlier versions of VC this was possible and then VMotion worked well). But in the new VC the advanced CPU options are greyed out for runningVMs. And editing of the vmx file does not help.
How can I change the CPU mask without power down the VM? I want to get one of my AMD8220 free to continue with update ...
"We had the same problem here, also with previous versions of "esxupdate". The solution is to change to the directory that contains the patches, and simply run "esxupdate update" there, without specifying the depot using the "-d" switch."
This worked for me.
Thank you,
Irina
Many Thanks.
I do have more that 1 host, Fortunately for me I had not updated them so they are not affected by the bug. Will my virtual machines vmotion off successfully. Or will the bug affect it?
As long as you haven't installed Update 2 you should be able to vmotion your vm's off fine.
How can I change the CPU mask without power down the VM? I want to get one of my AMD8220 free to continue with update ...
Why not simply VMotion the remaining VMs to the other 8220s? Or don't they have enough resources in reserve?
All worked for me, just make sure it's in Maintenance mode before applying patches. Build number updated to 3.5.0.110181.