VMware Tools does not start after updating the kernel in RHEL 6

VMware Tools does not start after updating the kernel in RHEL 6

Issue:

VMware Tools does not start after updating the kernel with boot log messages:

Checking acpi hot plug                                     [  OK  ]

Starting VMware Tools services in the virtual machine:

Switching to guest configuration:                       [  OK  ]

VM communication interface:                             [FAILED]

VM communication interface socket family:          [FAILED]

Guest operating system daemon:                         [  OK  ]

 

·         Vmware tools not running after kernel patches are installed

·         VMTool not working

·         After latest OS patch set installed VM coming up without NIC interfaces

·         After upgrading the kernel some of my devices no longer work

 

Environment

• Red Hat Enterprise Linux (RHEL) 5 Virtual Machine
• Red Hat Enterprise Linux (RHEL) 6 Virtual Machine
• VMware ESX Hypervisor

 

Resolution

• After updating the kernel, VMware tools just needs to be reconfigured -- not reinstalled
  Run the vmware-config-tools.pl script (from inside the RHEL guest) to update the initramfs/initrd

# vmware-config-tools.pl

NOTE: There is a high possibility that running this script will interupt network services on the server; run it from the console during regularly-scheduled downtime to prevent problems with applications and users

Root Cause

• In order for VMware-specific virtual hardware (e.g.: VMXNET3 ethernet controller) to work with a new kernel, initial ramdisk (initramfs in RHEL 6 and initrd in RHEL 5 & earlier) needs to be rebuilt to include the appropriate VMware-specific kernel modules (drivers)

Diagnostic Steps

• Check for VMware specific hardware in the output of an lspci command

 

Email Exchanging on Linux system using Sendmail+Dovecot+Squirrelmail
 

ØSend message from one computer to another computer using  Mail Server around the world.

ØThere are many servers are used to exchange these email  among one network to different network
ØMail server is responsible to send and receive mail from  one client   to another client.

how to rename the interface in linux

Rename network interfaces

Prerequisites

§  ifrename tool which is a part of the wireless_tools package.

§  udev package, which is already installed, of course.

Generic network interfaces

Option 1: udev

Create /etc/udev/rules.d/10-network.rules file with content like following:

 SUBSYSTEM=="net", ATTR{address}=="00:1e:58:48:33:08", NAME="lan"

 SUBSYSTEM=="net", KERNEL=="tap1", NAME="vpn"

 SUBSYSTEM=="net", KERNEL=="tap5", NAME="qemu"

Note: Make sure to use the lower-case hex values in your udev rules. It doesn't like uppercase.

Note: Note that the example above avoids names such as eth0, eth1, etc... and instead uses names that are not initially assigned. Trying to rename using names like eth0, eth1, etc... may fail.

Note: If using systemd, you may find it necessary to inform your network service to hold until the network device has been renamed. This may be achieved by adding the following to the [Unit] section of your network.service file:

 Requires=systemd-udev-settle.service

 After=systemd-udev-settle.service

Option 2: ifrename

Run ifrename directly

 # ifrename -i eth0 -n lan

or create config file (/etc/iftab), for example:

lan            mac 00:0C:6E:C6:94:81

internet       mac 00:0C:6E:C6:94:82

and run

 # ifrename -c /etc/iftab

Example:

How to rename the interface in linux using ifrename 

__tmp469514561 Link encap:Ethernet  HWaddr 00:1F:29:60:B6:A5

__tmp1982053100 Link encap:Ethernet  HWaddr 00:26:55:D6:91:1B

Create a iftable file and include the new NIc with mac address and execute the ifrename command mentioned below

itab - 

eth12 mac 00:26:55:d6:91:1b

eth14 mac 00:1f:29:60:b6:a5

ifrename -i eth0 -n lan

ifrename -i __tmp469514561 -n eth14

ifrename -i __tmp1982053100 -n eth12

PPP interfaces

Add into /etc/ppp/ip-up script the following lines:

 IF=$1

 ip link set dev $IF down

 /usr/sbin/ifrename -i $IF -n <NEWNAME>

 ip link set dev <NEWNAME> up

where <NEWNAME> is the new name for the ppp interface

Removing multipath disks

Removing multipath disks

in one of our RHEL4 blade servers, i need to remove
1x500G HP XP1000 LUN:

PV         VG             Fmt  Attr PSize   PFree

  /dev/dm-17 lx0080apps00vg lvm2 a-   200.00G  11.50G

  /dev/dm-18 lx0080apps00vg lvm2 a-   200.00G  11.50G

  /dev/dm-19 lx0080apps02vg lvm2 a-   500.00G 100.00G

  /dev/dm-20 lx0080apps01vg lvm2 a-   250.00G  50.00G

  /dev/dm-21 lx0080apps01vg lvm2 a-   100.00G  50.00G

  /dev/dm-22 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/dm-23 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/dm-24 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/sda2  vg00           lvm2 a-    67.88G   4.47G

[root@lx0080 ~]# pvdisplay /dev/dm-19

--- Physical volume ---

  PV Name               /dev/dm-19

  VG Name               lx0080apps02vg

  PV Size               500.00 GB / not usable 1.25 MB

  Allocatable           yes

  PE Size (KByte)       4096

  Total PE              128000

  Free PE               25600

  Allocated PE          102400

  PV UUID               O9b3hw-oSUO-pUpe-oGJw-zEBp-tKXo-3ba2g9

so here's how to do it without causing disruptions on the machine:
btw, this machine hosts a test environment.

CAUTION: DON'T DO THIS IN PRODUCTION ENVIRONMENT ON A REGULAR
BUSINESS DAY (Even if you are sure it won't cause any problems)

make sure no i/o activity on the disk
- i've removed it from nfs exports
- unmounted the FS
remove from VG group
remove from multipath definitions
delete from system

below here are the actual steps.

1. remove from VG group

[root@lx0080 ~]# vgremove lx0080apps02vg

Found duplicate PV O9b3hwoSUOpUpeoGJwzEBptKXo3ba2g9: using /dev/sdb1 not /dev/sdq1

Do you really want to remove volume group "lx0080apps02vg" containing 1 logical volumes? [y/n]: y

Do you really want to remove active logical volume "lx0080apps02LV"? [y/n]: y

  Logical volume "lx0080apps02LV" successfully removed

  Volume group "lx0080apps02vg" successfully removed

pvs

PV         VG             Fmt  Attr PSize   PFree

  /dev/dm-17 lx0080apps00vg lvm2 a-   200.00G  11.50G

  /dev/dm-18 lx0080apps00vg lvm2 a-   200.00G  11.50G

  /dev/dm-19                lvm2 --   500.00G 500.00G 

/dev/dm-20 lx0080apps01vg lvm2 a-   250.00G  50.00G

  /dev/dm-21 lx0080apps01vg lvm2 a-   100.00G  50.00G

  /dev/dm-22 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/dm-23 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/dm-24 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/sda2  vg00           lvm2 a-    67.88G   4.47G

as you can see - /dev/dm-19 is now an orphan. since its the only 500G
LUN in the server, its easy to identify.

2. remove from multipath

from multipath -ll (other entries removed):

mpath8 (360060e8004a51a000000a51a00000200)

[size=500 GB][features="1 queue_if_no_path"][hwhandler="0"]

\_ round-robin 0 [active]

 \_ 3:0:0:0 sdb 8:16   [active][ready]

 \_ 4:0:0:0 sdq 65:0   [active][ready]

it has two active paths.

multipath -f mpath8

(-f flush a multipath device map specified as parameter, if unused)

[root@lx0080 ~]# multipath -f mpath8
[root@lx0080 ~]# multipath -ll | grep 360060e8004a51a000000a51a00000200


360060e8004a51a000000a51a00000200 is the UUID of the disk from
scsi_id -gus /block/sdb (or /block/sdq)

now the multipath map is removed. but the disk is still in the system.

[root@lx0080 ~]# fdisk -l /dev/sdq

Disk /dev/sdq: 536.8 GB, 536877465600 bytes

255 heads, 63 sectors/track, 65271 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

/dev/sdq1               1       65271   524289276   8e  Linux LVM

[root@lx0080 ~]# fdisk -l /dev/sdb

Disk /dev/sdb: 536.8 GB, 536877465600 bytes

255 heads, 63 sectors/track, 65271 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

/dev/sdb1               1       65271   524289276   8e  Linux LVM

[root@lx0080 ~]#

[root@lx0080 ~]# pvs

Found duplicate PV O9b3hwoSUOpUpeoGJwzEBptKXo3ba2g9: using /dev/sdb1 not /dev/sdq1

  PV         VG             Fmt  Attr PSize   PFree

  /dev/dm-17 lx0080apps00vg lvm2 a-   200.00G  11.50G

  /dev/dm-18 lx0080apps00vg lvm2 a-   200.00G  11.50G

  /dev/dm-20 lx0080apps01vg lvm2 a-   250.00G  50.00G

  /dev/dm-21 lx0080apps01vg lvm2 a-   100.00G  50.00G

  /dev/dm-22 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/dm-23 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/dm-24 lx0080apps01vg lvm2 a-   200.00G  10.00G

  /dev/sda2  vg00           lvm2 a-    67.88G   4.47G

  /dev/sdb1                 lvm2 --   500.00G 500.00G

3. delete from the system

[root@lx0080 ~]# echo 1 > /sys/block/sdb/device/delete
[root@lx0080 ~]# echo 1 > /sys/block/sdq/device/delete
[root@lx0080 ~]# dmesg

Synchronizing SCSI cache for disk sdb:

Synchronizing SCSI cache for disk sdq:

[root@lx0080 ~]# fdisk -l /dev/sdb
[root@lx0080 ~]# fdisk -l /dev/sdq


here are some entries generated thru syslog:

- when multipath -f was run:

Apr 22 09:17:20 lx0080 multipathd: dm map mpath8 removed

Apr 22 09:17:20 lx0080 udevd[2444]: udev done!

- when deleting sdb

Apr 22 09:22:52 lx0080 kernel: Synchronizing SCSI cache for disk sdb:

Apr 22 09:22:52 lx0080 multipathd: remove sdb path checker

Apr 22 09:22:52 lx0080 udevd[2444]: udev done!

- when deleting sdq

Apr 22 09:22:57 lx0080 kernel: Synchronizing SCSI cache for disk sdq:

Apr 22 09:22:57 lx0080 multipathd: remove sdq path checker

Apr 22 09:22:57 lx0080 udevd[2444]: udev done!

Apr 22 09:23:02 lx0080 udevd[2444]: udev done!

our storage admin can now remove the disk definition from storage
server.

df –h mismatch size in linux

df –h mismatch size in linux

Change ext3′s reserved block count and gain Gigabytes

while I was running df to check the disk space I found that there is huge different in free size.

# df -h /dev/sda2

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda2              90G   79G  7.3G  92% /

I noticed that there was a huge gap between the total space (79 used + 7.3 available = 88.3) and the actual size of the file system. According to me this was due to the reserved block count, which is set to five percent by default in ext2 and ext3 file systems—clearly a legacy from a time where disks were smaller.

# dumpe2fs /dev/sda2|grep -i 'reserved block count'

dumpe2fs 1.40.8 (13-Mar-2008)

Reserved block count:     1196559

# dumpe2fs /dev/sda2|grep 'Block count'

dumpe2fs 1.40.8 (13-Mar-2008)

Block count:              23931180

# echo 'scale = 2; 1196559 / 23931180'|bc

.05

I changed the reserved block count with tune2fs:

# tune2fs -m 1 /dev/sda2

tune2fs 1.40.8 (13-Mar-2008)

Setting reserved blocks percentage to 1% (239311 blocks)

# dumpe2fs /dev/sda2|grep -i 'reserved block count'

dumpe2fs 1.40.8 (13-Mar-2008)

Reserved block count:     239311

# df -h /dev/sda2

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda2              90G   79G   11G  88% /

Now, the reserved blocks take up roughly 934 MiB; I’ve freed 3.7 GiB with this little file system tweak. 

 use at your own risk :)