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

SummaryWhen 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.ConfigvCenter 4.0 U1ESX 4.0 U1SolutionRename the VM in vCenterMigrate the VM to another DatastoreDone!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 manuallyMigrate the Update Manager VM to that updated hostRemediate 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.