Why is this VMware time bomb issue such a big deal?
- You can’t fix it without breaking some of your environment, in that you have to set the physical hosts’ time back to get it to work. Then the VMs pick up the time change.
- You can’t uncheck the “Synchronize guest time with host” option from VirtualCenter while a VM is running, basically condemning you to going to each host to uncheck that option, or letting the time get unsynchronized briefly.
- [kb,kb2].vmware.com had been mostly unavailable all morning, preventing people from actually getting to see the articles on the problem.
- In my environment, Windows VMs with Tuesday/Wednesday maintenance windows to pick up Microsoft Patch Tuesday updates had problems where the VMware Tools didn’t complete their post-reboot VMware Tools upgrade (“Check and upgrade Tools before each power on”). Now as we fix the licensing issue those VMs are rebooting themselves outside of their maintenance windows to complete their Tools updates.
- People who actually have test environments for their Virtual Infrastructure, and actually have a test regimen for new code, have no way to test for problems like this. Setting the clock forward on machines is tenuous at best.
- Waiting longer to roll out patches like this isn’t a solution, because the time bomb could just as easily be three months from now.
- Virtual Infrastructure isn’t stable or bug-free enough to wait months to update; each update release like this fixes big problems people are having with their environments.
It all comes down to trust, and there’s a lot of us out here that just got hung out to dry. Doesn’t matter whether Paul Maritz is sorry. We’re sorry, too.
Update: John Troyer reports that the problems with the Knowledge Base are fixed. Thanks guys.
Comments on this entry are closed.
Bob,
“1. You can’t fix it without breaking some of your environment, in that you have to set the physical hosts time back to get it to work. Then the VMs pick up the time change.”
Are you using ESXi? From I have seen, with ESX the patch doesn’t require a reboot of the host and you can keep your guests up and running.
“4. In my environment, Windows VMs with Tuesday/Wednesday maintenance windows to pick up Microsoft Patch Tuesday updates had problems where the VMware Tools didn’t complete their post-reboot VMware Tools upgrade (”Check and upgrade Tools before each power on”). Now as we fix the licensing issue those VMs are rebooting themselves outside of their maintenance windows to complete their Tools updates.”
Why do you have your guests power down and then back up when doing the updates rather than just reboot?
1. No, using normal ESX. The update requires the host to be in maintenance mode or have all the VMs shut down. I didn’t try having esxupdate force the patch, that didn’t seem like the best idea.
4. We don’t have them power down. What seems to have happened is that the guest OSes rebooted, came up, ESX knew that they had downlevel Tools, ESX knew they needed patching, ESX didn’t patch for some reason (seems like it was related to the licensing issue), then when the licensing issue was resolved it remembered that it needed to do a Tools update.
And then it did.
re #1) I have not seen the update as I am running 3.0.2 but I had seen posts in various places saying that the update did not require a host reboot. I did not realize it did however require that there were no running guest VMs.
Good luck with things….
No offense, it’s nothing personal to you or the VMWare folks, but reading #7 (especially, but this whole thing in general too) makes me glad I don’t use VMWare on servers, only on desktops/laptops.
Steve, thing is that Xen/Microsoft aren’t really that much better. Everything is changing so quickly that companies are scrambling to keep up, and none of them are spending enough time (in my opinion) on QA/bugfixes.