Trying to help the technically challenged... so mainly myself. 日本語訳が必要な方は、コメントをください。
Battered, bruised, but alive
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.