I'm with you, this is a major screw up, let's just get people back up and running. You seem to be competent, what part of the work around is giving you trouble? The date twiddle workaround is not that complex, and works for almost every installation scenario I can think of. You basically are just setting the clock back during a very short time window where the bad code checks the time. Most (all?) VM's are not even at the stage where they are picking up the time form the ESX host, so they boot and behave as expected. This requires you to be using the command line on the specific ESX host, but I'm sure someone here could hack up some sort of VI plugin that does this through the GUI for the people who really don't know what they are doing.

KyawH,

You are right, I opened my eyes now and I can see that this could be a solution. Sorry.

But I suppose it has to go through testing and acceptance within VMware and that this may also means downtime on the ESX box.

I suppose or I hope they are working on a fix that would not require reboots of VM or host ( I believe this is achievable because this is a licensing check part of code and should not have nothing to do with the kernel , may be in "vmware-cmd ... start" ??).

Maybe replacing vmware-cmd with the one from 3.5U1 would do the trick, if possible ?????? I'm gonna give a try to this one now.

I also think that announcing the worse, like 36 hours, is a worst case scenario and I hope they will be able to do it in less than that.

Best regards,

Ludovic

Right. I wish I had studied the VI plug-in architecture, it may be as simple as modifying the command that the VI console is sending to the ESX hosts. I suppose this is the quick fix that VMware engineers and this community should be looking at. There is a 99% chance that real fix is going to require maintenance mode in my opinion though.

There is a rollback option, but it only helps if you are able to reset your ESX-Servers. It works with 3i embedded (on usb)
I don't know if it works on the installable.. but here's how it works:

Restart your ESX-Server

At the bootloader screen (the first white progress bar), hit shift+r
(uppercase R), this allows you to
go back to the previous system image. (Thanks to ocremel, http://communities.vmware.com/message/965902)

There you can select to go back to the previous image....

No, Macrovision authentication hooks are typically spread far and wide throughout the code so that hackers can't easily patch it out. This likely touches many places.


You are making it hard on yourself. Please read the above command line based solutions to launching your VM's by hand.


That's called managing expectations. Let's hope it is soon. But as I said previously, I'm very aware of the build process, and it will take them almost that long just to branch, modify and compile (Moderator: I hope I'm not giving away any trade secrets, delete my post's if this is too much information.)

In the 4-5 years I've been using vmware this is the first major bug I've encountered. Finding vendors that are major bug free, will be a long journey. Microsoft have done it too, several times at that. Don't judge the products on this problem, but see the big picture. Would it be any different on another virtualization platform? At least it's a software problem that can be solved easily compared to any hardware based problems like the one AMD and Intel did.

We only have two 3.5u2 hosts, both not yet live, so we've managed to avoid any production issue here.

With the issue of putting the date back then affecting VM timestamps when they boot up would the following work :
1) unconfigure NTP
2) set time back to 1 Aug
3) Turn on all VMs, but press F12 or Del to go into the guest's BIOS config or Choose Boot Device screen - ie prevent bootup into OS.
4) correct time back to 12 Aug
5) Press Ctrl-Alt-Ins in each VM so they then reboot, pick up correct time and start OS bootup

This is presuming that the license check is only done at VM startup, and not at VM reboot (ie ctrl-alt-ins in VM, not a VM reset).

Gary.