Comments (0) Finally, it’s officially supported.
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!
I was trying to VMotion some VMs recently from one ESX host to another. Sounds simple enough. Except these VMs have RDMs in physical compatibilty mode. As such, they cannot be VMotioned whilst powered on. I powered down one of the VMs and retried the VMotion. Again, it failed, but with an error as follows:
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.
Virtualization
| 
ESX, RDM, VMWare
It might seem a little odd to some, attempting to install Microsoft Windows XP into a Virtual Machine running on VMware’s ESX 3.5. That’s more of a job for VMware Workstation or Player. However, I wanted to install a Windows XP VM in my ESX test environment, to try some things out. I was a little surprised when I was greeted with this message during the initial install though:
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. Continue reading 'Installing Windows XP on VMware ESX/ESXi – No Hard Disk Drive Found'»
I was experiencing some issues whilst restoring some backups made with Vizioncore vRanger Pro. I’m currently using version 3.2.5.6, which is well over a year old. The obvious first step is to update the software to the latest version. At the time of writing, vRanger Pro is at version 3.2.9.7, but version 4 is on the horizon. Upgrading something as crucial as backup software makes me a little twitchy. Its important to know that you’ll still be able to take backups successfully once the upgrade is complete, and that you’ll be able to restore backups you’ve previously made. I had a good look around Vizioncore’s website for some information on the recommended upgrade procedure. Aside from a vague posting on their support forum, there was no official procedure that I could find. Should you really have to place a support call for something like this? Anyway, I managed to get the answers I was looking for, so thought I’d post them here:
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.
Virtualization, Windows
| backup, ESX, upgrade, vizioncore, VMWare, vranger
I’ve been using VMWare ESX 3.5 for a while now, and whilst pretty much all configuration can be performed using the Virtual Infrastructure Client, there are a few configuration changes that I’ve come across that need to be performed from the command line. These configuration commands are generally prefixed with ‘esxcfg-’, and there are quite a few of them. They appear to be largely (publicly) undocumented by VMWare (especially if you dont like sifting through man pages), but I came across an excellent break-down of these commands by the consultants & trainers at Taupo Consulting.
For example:
….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.
Panorama Theme by 
Themocracy
