installing vmware tools on RHEL7 / Centos7 linux

UPDATE
With RHEL and Centos 7 you can use a yum package to install VMware Tools, which is the preferred method

yum install open-vm-tools

or from the virtual infrastructure client

First you click on install VMware Tools.

Then do the following:
mkdir /mnt/cdrom
mount /dev/cdrom /mnt/cdrom
cp /mnt/cdrom/VMwareTools*.tar.gz /tmp/
umount /mnt/cdrom
tar -xzvf /tmp/VMwareTools*.tar.gz
rm -Rf /tmp/VMwareTools*.tar.gz
/tmp/vmware-tools-distrib/vmware-install.pl

You get an update

How often should I update my Linux server.

I run apt-get update -qq; apt-get upgrade -duyq daily. This will check for updates, but not do them automatically.

Then I can run the upgrades manually while I am watching, and can correct anything that might go wrong.

Besides the security concerns of maintaining a patched system, I find that if I leave it too long between patches, I end up with a whole bunch of packages that want to be upgraded, and that scares me a-lot more than just upgrading one or two every week or so. Therefore I tend to run my upgrades weekly, or if they are high priority, daily. This has the added advantage of knowing which package broke your system (ie. if you're only upgrading a couple at a time)

I always upgrade less critical systems first. I also have a "rollback plan" in place in case I can't fix the system. (since most of our servers are virtual, this rollback plan usually consists of taking a snapshot before the upgrade that I can revert to if necessary)

That being said, I think an upgrade has broken something only once or twice in the past 4 years, and that was on a highly customized system - so you don't have to be TOO paranoid :)

The datastore that was there but wasn't

Had an issue with a cluster where some of my vmfs datastores were present on HOST A but not B OR C. Digging into the host properties I could see the LUNs where the datastores were located from the storage controller. I noticed that the esx version where the datastores weren't present were older. So I decided to upgrade the esx host. After the upgrade even more datastores were missing. Doing some googling I found out the solution:

from the CLI do the following:

This will show you the datastores that are available.
 # esxcfg-volume -l

VMFS UUID/label: 521556dd-261dc458-6c2f-ac162d782b64/Promise VMs
Can mount: Yes
Can resignature: No (the volume is being actively used)
Extent name: eui.22bc000155ef63ec:1     range: 0 - 2096895 (MB)

VMFS UUID/label: 520e5089-cf57924a-6997-ac162d782b64/Promise SSD
Can mount: Yes
Can resignature: No (the volume is being actively used)
Extent name: eui.22a8000155c818b4:1     range: 0 - 456703 (MB)

VMFS UUID/label: 520e50ba-1a761aaa-8785-ac162d782b64/Promise SAS15K
Can mount: Yes
Can resignature: No (the volume is being actively used)
Extent name: eui.22e80001552f174d:1     range: 0 - 571135 (MB)

Mount the LUNs
# esxcfg-volume -m "Promise VMs"
Mounting volume Promise VMs

# esxcfg-volume -m "Promise SSD"
Mounting volume Promise SSD

# esxcfg-volume -m "Promise SAS15K"
Mounting volume Promise SAS15K

# esxcfg-volume -l

When two (tables) are really one

I had a funny issue where table in known working script was not found.

Error Executing Database Query
Table 'tableone' doesn't exist

It had a camel case name and I could see a table from the mysql cli, but not in phpmyadmin. It was strange because there were two versions of the table, TableOne and tableone. My first thought was to delete it from the cli, but that ended up deleting them both. I recreated the table and reinserted the data but the two tables showed up again.

Later on in the day I had a coworker tell me they had to change the mysql config to add the following in order to support a piece of software.

lower_case_table_names=1

Here is was it does:
Table names are stored in lowercase on disk and name comparisons are not case sensitive. MySQL converts all table names to lowercase on storage and lookup. This behavior also applies to database names and table aliases.

I removed that line from the config and restarted mysql and the script worked.

Zenoss device names are tied to the ip

If you use the change ip of a device in zenoss using the reset/change ip menu item, the ip will be update in zenoss. Unfortunately all of the worker calls go to the device id which is currently the old ip.

You can fix this by changing the Device Id in Zenoss using REST calls

Here’s how:

Go to zenoss Web Admin page, identify the device Id for which you want to change
e.g:
http://example.com:8080/zport/dmd/Devices/Server/Linux/devices/server01.contoso.com

Add to the end of the URL to include /renameDevice?newId=newDeviceId

to become:

http://example.com:8080/zport/dmd/Devices/Server/Linux/devices/server02.contoso.com/renameDevice?newId=server02.contoso.com

Press Enter and the DeviceId will change to the new one.

Troubleshooting:

If the server02 name is not recognized by the network, make sure the name is added into the DNS first before you do it.