I didn’t notice any fanfare about this and it doesn’t seem to be in the release notes for vSphere 4.1 or the What’s New document, but I noticed it in the compatibility matrix:

As of vSphere 4.1, Microsoft Windows Server 2008 R2 is now an officially supported Operating System for vCenter Server. It’s about time!

Unable to migrate: Virtual Disk is a mapped direct access LUN that is not accessible

This suggested that the target host couldn’t see the LUN relating to the RDM. I double-checked, but already knew that all of my hosts had the same LUNs presented. So what was the problem?

It turns out that in order to VMotion a VM with an RDM, both the original and target host must have the LUNs presented using the same LUN ID. Somewhere along the way, one of the hosts had the LUNs presented in a different order, causing different LUN IDs to be assigned for that host.

To resolve this, you need to unpresent each incorrectly identified LUN and then re-present with the correct IDs. Not a trivial task if your cluster is made up of few hosts.

I’ve installed countless Windows Server 2003 VMs, and not had any issues. Pre-morning-coffee, it wasn’t immediately obvious why Windows XP would have any issues installing, especially as its listed as a supported VM type during the virtual hardware configuration steps.I found some very helpful instructions here:  http://vantoft.org/2009/01/05/esx-esxi-windows-xp-guest-install-reports-no-hard-disk-found/

Essentially, VMware ESX gives you a choice of Buslogic or LSI Logic SCSI adapters for Windows XP VMs. The Windows XP CD installer doesn’t have built-in support for these adapters, and therefore cannot see the VMs hard drive(s). As such, you need to download a floppy disk image containing the necessary SCSI adapter driver. Thankfully, VMware provides this floppy disk image for download. Follow the 6 steps in the above link to proceed with the Windows XP installation.

Firstly, and it’s a biggie: You cannot ‘upgrade’ using the installation executable. You must first uninstall the old product.
What about configuration settings? – I was assured by Vizioncore support that after the uninstall, all configuration settings, license files, logs, etc, are all left behind. Once you install the new version, it will pick up all of your previous configuration settings from these files.

If, like me, you want to be extra sure that you wont lose your configuration, make a copy of *.dat, *.mdb and *.lic files from your vRanger installation folder before the uninstall. You may also wish to backup your log files, etc.

Then  just execute the .msi that you downloaded from the Vizioncore website, and follow the prompts.

Your scheduled tasks should also be unaffected, and will run as before using the newly installed vRanger executable.

For example:

• esxcfg-advcfg – Get/Set Advanced Configuration (e.g. modify ‘EnableResignature’)
• esxcfg-firewall – Modify the iptables firewall configuration
• esxcfg-module – View and set options for start-up of the VMkernel modules (drivers)
• esxcfg-vswitch – List, add, modify or delete virtual Ethernet switches
• esxcfg-info – Information about the host
• esxcfg-boot – Configure the GRUB options presented at boot time
• esxcfg-vmknic – View and set configuration of the VMkernel ports on virtual Ethernet switches

….and many more, with full descriptions and usage examples.

They also mention many of the configuration files and their locations, along with some popular Linux commands for those unfamiliar with working at the Linux command line. Definitely worth a bookmark if you administer ESX hosts.

After a little headscratching, I discovered (as I’d suspected) that this was nothing to do with VMWare or the SRM plugin. Updating my Windows Installer using the package on the Microsoft site here, allowed me to continue with the plugin install.