Showing posts from May, 2010

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 Rename the VM in vCenter Migrate the VM to another Datastore 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: Update one host in your cluster manually Migrate the Update Manager VM to that updated host 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.