To get the current value for vm.swappiness
$ sudo sysctl vm.swappiness
OR
cat /proc/sys/vm/swappiness

To change vm.swappiness to 10 for current session (upon restart value will be reset to default value)
sudo sysctl vm.swappiness=10
OR
echo 10 > /proc/sys/vm/swappiness

To set vm.swappiness value permanently to 10 (it will take effect upon reboot)
sudo sysctl -w vm.swappiness=10
OR
sudo vi /etc/sysctl.conf
Search for vm.swappiness and change its value as desired; if vm.swappiness does not exist, add it to the end of the file e.g : vm.swappiness=10

Install a VM with your favourite operating system (Linux or Windows).

Install patches and make OS up-to-date with all security fixes.

Shut-down the VM; open ‘Virtual Media Manager’ for Virtual Box.

Select the desired Virtual Disk and click Release icon on the menu bar (this will release the disk from VM).

Open a terminal window and run following command:
VBoxManage modifyhd –type immutable {full path to vdi file}

Run following file to verify the change:
VBoxManage showhdinfo {full path to vdi file}

Attach the virtual disk to the VM using VM Settings Editor and configuration is complete now.

To change virtual disk back to normal from read-only mode:
VBoxManage modifyhd –type normal {full path to vdi file}

Virtual disk needs to be released from VM to run any ”modifyhd’ commands.

lanscan and lanadmin are the two tools which are used to configure most the network parameters on a network interface. (click on the links to get to the man page for both tools)

List of all interfaces along with names, type and their corresponding drivers:

>lanscan -v

In the above output; this server has two interfaces lan1/lan3 and lan1 is igelan based device and lan3 is btlan based device.

To display the duplex and speed configuration of any interface:

lanadmin -x 0 (where 0 is lan0 and for lan1 use lanadmin -x 1)

To set/change the duplex and speed configuration of any interface:

lanadmin -X 100FD (As per requirement 10HD or 10FD or 100HD or 100FD or AUTO_ON can be used)

To change the duplex and speed configuration in the start-up scripts:

Edit the appropriate file for btlan or igelan device config:

for igelan device edit /etc/rc.config.d/hpigelanconf
change HP_BTLAN_SPEED parameter to 10HD or 10FD or 100HD or100FD or AUTO_ON

for btlan device edit /etc/rc.config.d/hpbtlanconf
change HP_IGELAN_SPEED parameter to 10HD or 10FD or 100HD or 100FD or AUTO_ON

then restart the device:

/sbin/init.d/hpbtlan start
/sbin/init.d/hpigelan start

To verify the changes; display the current  duplex and speed configuration:

lanadmin -x 0

List the version of Management server (Unix based) :

use the what command to get the detailed information about installed version of OVO:

#what /opt/OV/bin/OpC/opc*

OR

#swlist -l product | grep OVO

List of Available OVO Agent versions on Management server:

#/opt/OV/bin/OpC/agtinstall/opcversion -a

List the Installed version of OVO Agent on a node:

#/opt/OV/bin/OpC/opcragt -agent_version <NodeName>

Following steps were taken to diagnose/fix the problem:

ps -ef | grep inetd – make sure inetd daemon is running

ps -ef | grep cmcl shows approximately 50 processes for cmclconfd daemon on both nodes; on the 3rd node there are only 2 processes for cmclconfd.

kill cmclconfd daemon processes except the first one

run “inetd -k; inetd“  to restart a fresh inetd daemon

This should restart the inetd daemon and cmviewcl command should start working after this.

05/27/09 04:51:21 WARNING opcmona   (Monitor Agent)(24834) [genmona.c:4693]: Can’t start monitor script for object ‘OSSPI-inetdproc_1′. Script still running. (OpC30-610)

/var/opt/OV/log/OpC/opcerror on the agent machine showed that this message is being generated every 5 minutes.

ps -ef | grep -i osspi output shows multiple instances of these OpenView monitor scripts being run and some of the these instances were running for couple of hours.

The most common cause of this error is heavy I/O or processor usage; agent script starving for processor usage and another script is kicked off in the mean while causing this warning. That was not the case in this instance as resource usage was normal on this server. We tried restarting theOpenView agent but it didn’t fix the issue.

The easiest way to troubleshoot the problem is run this script manually and review the output to see why the script is failing:  (make sure you have /var/opt/OV/bin/OpC/cmds in your PATH variable)

run following command from /var/opt/OV/bin/OpC/monitor directory
sh -x ./osspi_procmon.sh OSSPI-inetdproc_1 inetd

It will provide a long output and will give you a starting point where the script is hanging. In our case it was trying to run cmviewcl which was causing this script to hang as there were some problems with cluster state (which will be discussed in next post).

Create/Edit a file called ifcfg-bond0 in /etc/sysconfig/network-scripts/

vi /etc/sysconfig/network-scripts/ifcfg-bond0

Add the required network parameters e.g.

DEVICE=bond0
IPADDR=192.168.1.20
NETWORK=192.168.1.0
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
USERCTL=no
BOOTPROTO=none
ONBOOT=yes

Edit the existing ifcfg-eth0 and ifcfg-eth1 files and remove IP address, network ID, network mask and gateway address. Add the parameter MASTER=(your bond ID i.e. bond0 or bond1). Following are the sample files after editing:

# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
# vi /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

Edit /etc/modeprobe.conf and add following two lines: 

# vi /etc/modprobe.conf
alias bond0 bonding
options bond0 miimon=100 mode=1

Mode value is used to determine the operational mode of Bond e.g. active-backup or active-active. Different bonding modes are documented in /usr/share/doc/kernel-doc-2.4.21/networking/bonding.txt

Run following commands to activate bonding; make sure you are connected to console otherwise you will loose your session as network services will be restarted.

# modprobe bonding
# modprobe -r -v bonding
# modeprobe -r -b bonding -o bond0

# service network restart

To verify that bond is working; use following commands:

# less /proc/net/bonding/bond0
# ifconfig -a

/usr/lbin/modprpw -l -k username

It will unlock the user account. This utility is only available on trusted system and you will have to run it as root.

Man page for modprpw can be found here    http://www.docs.hp.com/en/B2355-90691/modprpw.1M.html

IBM has an ifix for this issue which updates following filesets:

cluster.es.server.events

You can apply this ifix using emgr command; there is no outage to HACMP when you apply this fix.

This ifix is not available to public yet; you will have to contact IBM Support for this.

Thanks for visiting; I will be putting my thoughts about technology, general life and whatever I can think of here.

I am an IT Professional and currently working as a Unix Systsem Administrator.