Battered, bruised, but alive

Grab this badge here!

I only wish that I had the time to finish the rest of the games.  There is always next year I suppose.

Bug? Feature? VM Hardware 7 RHEL5 32-bit running 64-bit

Summary:

Under VM Settings --> Option Tab --> General Options –> Guest Operating System, Red Hat Enterprise Linux 5 (32-bit) is selected.  However, the installed OS is actually RHEL5 64-bit.  Under VM Hardware version 4, this combination was not possible as RHEL would detect that the processor was not 64-bit capable probably because of masking.  Not that I care all that much since it seems to work fine, but what would this be considered?  A feature or a bug?  Only reason I noticed was because our Linux admins were wondering why in a set of 6 VM’s running 32-bit, this one was running a 64-bit version…

Answer: Because someone on their end screwed up and installed the wrong version, can’t completely blame them though since in version 4 they would have been denied.

Example:

Side Note:

Interestingly, the Guest OS field now seems to update w/ the actual Guest OS information provided by the VMWare tools.

Rename a VM without shutting down…using storage vMotion

Summary

When renaming a VM in vCenter, underlying files and folders remain named the same as when the VM name was first designated.  This can make for a difficult recovery scenario if file/folders and names in vCenter are out of sync.

Config

• vCenter 4.0 U1
• ESX 4.0 U1

Solution

1. Rename the VM in vCenter
2. Migrate the VM to another Datastore
3. Done!
• If you check the VM’s settings and/or datastore, all related files/folders should now match the VM name in vCenter.

Maybe this was obvious to some folks, but it wasn’t until I was doing maintenance @ the wonderful hour of 2am that this dawned on me as a possible solution.  I’m so used to having to go through this process.

There are errors during the remediation operation…updating esx host using update manager.

Summary:

One of the greatest features of Update Manager (4.0 U1 P1) is that you can click on a cluster and remediate the whole thing.  It places one host @ a time into maintenance mode and does it’s thing.  Unless of course Update Manager happens to be a VM that resides on one of those hosts in the cluster.

Example of Error:

WorkAround:

1. Update one host in your cluster manually
2. Migrate the Update Manager VM to that updated host
3. Remediate the entire cluster.

Rant:

I like the fact that vCenter returns such an obvious error, but why can’t it move itself to another host like any other self-respecting VM.