I'm adding to myself to this thread mainly so I get updates as to when it is resolved - I've had about 5 emails from various people already... mainly asking me to blog about this issue to get the word out.... Which I have done this morning.... I would have to say chaning the date/time on the ESX host doesn't seem much of a work around - what about clock drift and the time on all the virtual machines...
I am still concerned about the avilability of this patch.
Currently the servers handling the kb.vmware.com area, is basically so slammed, that it's undergoing a kind of Denial of Service. (it's basically unavailable).
What will happen with the update and patch servers?
When it's available, will these servers be trampled too?
I hope someone has set a few engineers off on a task to beef up the mirror server numbers.
Anyone an idea / procedure how to roll back to U1 (apart from throwing in a CD an do a reinstall)? Will remove certain RPMs work??
We in New Zealand were first to experience this date/lic issue.
Setting the date back does not effect the time on the virtual machines, as long as the vmtools are not set to sync with the ESX Host.Our VM's sync time from the domain and not the ESX Host so they were unaffected. Do take care when changing the date/time.
I would suggest doing the date change via the service console and not through the gui. Once all your vm's have booted set the time back.
Just to add to the list...
We coincidentally performed our first upgrade from 3.0.2 to 3.5u2 this morning (Aug 12th, 10am UK time) and I noticed straight away while the upgraded host was still in maintenance mode that the licensing tab within VI client gave the general system error msg. Fortunately, this was only in our test cluster, but obviously, I will leave that host in maintenance until the fix appears.
Hope you guys with production hosts running on update 2 get things sorted quickly.
Aug 12. 4:09AM MDT can confirm the problem here as well. Also, cannot access the KB article "We're sorry, but this Document is not currently available". Fortunately I can revert to trial mode with 40+ days left...
In my previous post I wasn't clear enough with the workaround I proposed:
>If you want to be proactive, I suggest you find the ESX server hosting the less domageable VM's you have (maybe one hosting only dev servers, or the >one with the least VM's or the one where customers are the most tolerant) and stop all VM's on it (an orderly shutdown is always better than a crash), >restart them elsewhere on 3.5U2 and downgrade the empty box to 3.5U1. You can then use VMotion to move VM's from another ESX 3.5U2 server (it is >working, i tested it) and perform a "rolling downgrade" of your infrastructure. Re-installing ESX should not take more than one hour and you will be in a >much better situation when VMware release the fix, regardless of the form it will have, ISO, RPM ...
When I wrote "restart them elsewhere on 3.5U2" I meant "restart them elsewhere on 3.5U2 where you applied the workaround, i.e moving back the date" if you really can't avoid it.
I strongly suggest that anyone not wanting to wait 36 hours or more for a fix apply the workaround I described because time keeping is really a critical problem for a number of applications (as of now i can think of database, SAP even Kerberos....). A "not so planned" orderly shutdown is far better than data inconsistencies in your environment.
P.S. you can leverge this opportunity to apply Microsoft patches on your VM's (or Red-hat, or...) :0 :0
Hope this helps, best regards,
I agree with you. Changing the clock is NOT a workaround. Work around is an alternate solution, not temporary solution such as this: buying time solution...There are so many OSes/applications out there relying on the time...who knows what will get impacted by this changing time therapy and most importantly, how long it will last?
Maybe their Knowledge Base is hosted on a VM box that suddenly won't boot!
Well, as a matter of fact, we have a big Hyper-v installation at a customers factory and its running like clockwork. So maybe, just maybe if VmWare doesnt fix this really soon you could end up being quite lonely in here. 36 hrs is not acceptable for a fix when a problem of this magnitude arise. So please dont tell me to be calm while we and our customers are loosing thousand of Skr every hour just because they are more interested in licenseprotection stuff than to offer their customers software that will work and is properly tested. The only ones that are having problems with all the "copyprotection" stuff are "we", the ones that are paying for our software. Does that seems right to you. I really think that VmWare is really showing a total lack of respect for their customers when they are "fixing" things like this. I dont think their stocks will be wery high in the nearest future.
Unfortunately, there is no rollback option for updates.
I have the same problem. Changing date solved it, but i hope it's only temporary solution. Still waiting for patch - the one without restart / maintenance mode....
Regards from Poland
I agree with your, however, I did not Update to this "update 2" level manually.
Apparently, major update releases are put in place, automatically by Update manager!
I was unaware that Update Manager would do this, i thought it only put out interim patches, and not major OS updates!
We have (now HAD) Update Manager running the updates monthly.
Apparently this got put in the update sequence for installation and I didn't see it.
I have Change Control documents in the pipeline for U2, and had expected to install in phases.
(the right way)
But now, i'm apparently all updated. (Except for VirtualCenter and VCB).
Out of all of this whole thread - to me - this is the most worrying issue.
Is there no way to tell Update manager that updates have to be authorized?
Now this - for me - is unacceptable...
Systems Administrator & Virtualization Architect