I’ve been using the ESX Deployment Appliance for a while now and really, really love it.  One thing that I have had to do though is to change the regional settings and keyboard settings to be UK based instead of US based for the deployed ESX installations.

It’s not difficult to do so here’s how:

Log into the appliance

Open /var/www/ks/ks.php with vi

Change the following:

lang en_US to lang en_UK

langsupport –default en_US to langsupport –default en_UK

keyboard us to keyboard uk

That should be it, as these changes don’t require a reboot. You can check whether they were applied correctly by clicking the ks link next to one of your hosts in the EDA web interface:

I had a customer that had a requirement to backup the ESX Service Console settings and wanted to know the best files to backup. I suggested that it may be more prudent to create unattended installation media to make restores more seamless. This took a turn and I was asked to make a single CD that was capable of restoring any one of the 11 ESX hosts in the clusters. With a lot of reading and a lot of testing this was achieved and this document explains how I did it.

Most of the information came from a multitude of different blog posts and knowledge base articles, but the two main articles are referenced in the appendix, but they deserve special mention:

VMProfessional – Custom .iso with integrated kickstarts

Yellow Bricks – Scripted install

These sites are always fantastic, but they proved absolutely invaluable for me during this exercise, so thanks guys.

I hope that the document adds some value, but if you think that I have got anything wrong or can offer some enhancements please don’t hesitate to comment on the post and I will update the document.

Daemon Behr has written a nice and succinct article on when and how to use more than one virtual CPU in a Virtual Machine.

A few of the highlights:

• Be very selective with vSMP only use it when applications can take advantage
• Don’t assign a VM the same amount of vCPUs as you have pCPUs
• Remember to change HALs for migrated physical machines if necessary

I know most of this is taught during the training courses, but you’d be surprised how many installs I have been to that have ignored them.

Always useful to keep in mind.

As most people will know by now there is a serious issue with licensing in the latest version of ESX 3.5 Update 2, which causes valid licenses to expire today (12th August).

The implications here being:

• No VMotion
• No DRS
• Inability to power on of machines that are not already powered on

The solution is to disable NTP and manually change the date to a few days past and then wait for VMware to release a patch within the next 36 hours.

To change the date simply check out this post.

Be careful when changing the time as any Virtual Machine that has the time synchronised with the host via VMware Tools will have the incorrect time applied. You may want to change this option to use either you time keeping DC or an ntp server directly.

Be careful and don’t do it unless you absolutely have to.

Existing Virtual Machines that are already powered on will continue to run, but if they are shut down they will not be able to be powered on again until either patched or the date has been changed.

Eric Siebert has compiled two more excellent Top Ten lists:

Storage in VMware

Get More Technical with VMware

Not much more to say, just that they are as excellent as I’ve come to expect.

Richard Bramley has written another excellent article that has stoked up some helpful comments as well.

It discusses the very useful RAMCheck tool in ESX that will check for faulty memory.  I have used the utility a few times and it turns out, courtesy of a reader comment, that it has been removed from ESX 3.5.  I usually use MemTest if I”m pretty certain that a machine has faulty memory, but RAMCheck was always quite useful.

Anyway, have a stroll over to Richard’’s blog and check out all the useful posts.