Latest News

Eat your own virtual dogfood

Our thanks to The Orange Rag reader who sent in this story…

With the increasing popularity of virtualization, I
thought you may be interested to see the email extract below.  If you can't
get to the link below, it will be because VMWare use their own software to host
parts of their own web site and they are also affected by the bug which is
causing parts of their own web site to be unavailable.  Eat your own dog

Separately, further to my
email of 21 July regarding the bug affecting a BES Server, Exchange Server 2007
and Out of Office messages, I can confirm that the Service Pack 6 for BES 4.1
does fix this issue.

Please be aware there is a major bug with VI
3,5 update 2 that doesn't allow customers to VMotion, resume or power on virtual
machines once the date reaches the 12 August. The bug appears as if it is
licensing issue.

“VMware support has a work around for this and is working
on a permanent solution.

2 replies on “Eat your own virtual dogfood”

The problem is not only related to 3.5u2, you will also be affected if you install the following updates via Update Manager:
The bug doesn't affect currently running virtual guests so if you can avoid restarting (or crashing) your VMs until VMWare patch the issue you'll be fine. If you do need to start a VM (or VMotion it to another ESX host), there is a work-around involving setting the date back to earlier than 12th August on the ESX Host, starting the guest VM(s) and then setting the date forwards on the host. Details here:
Important caveats:
a) If you have VMTools installed on the guests, make sure they are not configured to synchronise time with the ESX host.
b) As we (and others) have found, even if you have turned off host time synchronisation, some Windows guests still seem to sync the time regardless (haven't worked out why).
Either way this is a bad thing, especially if it is a domain controller as it buggers up lots of stuff (including exchange in our case). We managed to get the DC sorted out in the end after a couple of fraught hours but be careful.
The root cause of the problem hasn't been confirmed by VMWare as such, but general suspicion in the community is that the issue is caused by a timebomb meant to kill beta releases of the 3.5u2 code that made it into a production release in error and completely escaped the QA process.
A patch is due to be released by 12:00PM PST tomorrow (i.e. late tomorrow evening/early morning Thursday UK time.
Major problem for operators of giant server farms but luckily manageable for those of us with more modest set-ups.

Comments are closed.