Tips and Tricks site for advanced HP-UX Engineers

12 Jul 11 Migrate VXVM booted system to LVM

From the HP-UX Veritas Administration guide, buried on page 106

This example shows how to create an LVM root disk on physical disk c0t1d0
after removing the existing LVM root disk configuration from that disk.

BOOTBG=$(vxdg bootdg)

vxprint -htg $BOOTDG | grep ^dm

dm rootdisk01   disk233_p2   auto     1024     142450592 –
dm rootmirr     disk234_p2   auto     1024     142450592 –

# You get the boot disk from this command. Break off the s2 if you are using legacy devices you can use them or the agile SDF devices.

# You may need to use vxbrk_mirror to break the mirror. Make sure you know which disk you are booted from. Check syslog to be sure. setboot is not a good indicator.

# Due to a wordpress error I’ve been forced to take the path etc vx bin out of the commands. I will fix this when wordpress stops blowing chunks on this data. Where there are spaces there need to be slashes.
#  etc vx bin vxdestroy_lvmroot -v c0t1d0
# etc vx bin vxres_lvmroot -v -b c0t1d0
The -b option to vxres_lvmroot sets c0t1d0 as the primary boot device.
As these operations can take some time, the verbose option, -v, is specified to
indicate how far the operation has progressed.

This command takes care of setboot and all details. Then just boot from the console.

This procedure does not remove VxVM software. The daemon still runs. But your system now boots LVM and that makes using Dynamic Root Disk (DRD) much easier.


Tags: , , , , , ,

15 Jun 11 Why HP-UX root shell needs to be /sbin/sh

Thanks to Jibn Antony of the Best Buy IDC team for validating.

So who cares what the root shell is? You do if you try to boot your system into single user mode with root shell changed to a shared executable shell, you will find out the hard way. The system won’t boot.

root@dxd22hxd# ls -l /bin/ksh
-r-xr-xr-x   2 bin        bin         538632 Nov 12  2007 /bin/ksh*
root@dxd22hxd# ldd /bin/ksh =>  /usr/lib/hpux32/ =>  /usr/lib/hpux32/ =>    /usr/lib/hpux32/ =>    /usr/lib/hpux32/ =>  /usr/lib/hpux32/ =>   /usr/lib/hpux32/
root@dxd22hxd# ldd /sbin/sh
ldd: “/sbin/sh” is not a shared executable.
root@dxd22hxd# ls -l /sbin/sh
-r-xr-xr-x   1 bin        bin        1402600 Oct 23  2007 /sbin/sh*
Note that /bin/ksh requires /usr to be mounted which is not the case with single user or lv maintenance mode.

Tags: ,

06 Apr 11 setboot hardware path to legacy hardware path. A converter.

HP-UX 11.23

setboot provides output only including the hardware path (ioscan -H).

When calculating DRD clone targets and such you need the regular legacy device path.

Here is a converter, built with a little help from JRF on the ITRC forums.

First get the setboot path. Might want to use the full path of the setboot command in practice.

pboot=$(setboot | grep ^Primary | awk ‘{ print $NF }’);
aboot=$(setboot | grep ^Alternate |awk ‘{ print $NF}’);

abootdisk=$(ioscan -kfnCdisk | awk -v aboot=${aboot} ‘/aboot/ $0~aboot {getline;print aboot,$2}’ | awk ‘{ print $2 }’);

pbootdisk=$(ioscan -kfnCdisk | awk -v aboot=${pboot} ‘/pboot/ $0~pboot {getline;print pboot,$2}’ | awk ‘{ print $2 }’);

The slick part is getting the variable in and out of awk.

Uses ioscan.

Tags: , , ,

29 Oct 10 HP-UX APA help guide

HP APA Commands using lanadmin and nwmgr

Task Legacy Command nwmgr Command
Display command help lanadmin -X -H 900 nwmgr –help -S apa
View link aggregate status lanadmin -x -v 900 nwmgr -c lan900
Create a MANUAL mode link aggregate lanadmin -X -a 1 2 900 nwmgr -a -A links=1,2 -A mode=MANUAL -I 900 -S apa
Create a failover group lanapplyconf nwmgr -a -A links=1,2 -A mode=LAN_MONITOR -I 900 -S apa
Remove all ports from a link aggregate lanadmin -X -c 900 nwmgr -d -A links=all -I 900 -S apa
Remove all ports from a failover group landeleteconf -g lan900 nwmgr -d -A links=all -c lan900
Remove specific ports from a link aggregate lanadmin -X -d 1 2 900 nwmgr -d -A links=1,2 -I 900 -S apa
Update the load balancing algorithm and group
capability for a link aggregate
lanadmin -X -l LB_MAC 900
lanadmin -X -g 900 900 900
nwmgr -s -A lb=LB_MAC, gc=900 -I 900 -S apa
Update the group capability and configuration
mode for a port
lanadmin -X -p 3 900 900
lanadmin -X -p 3 FEC_AUTO 900
nwmgr -s -A gc=900, mode=FEC_AUTO -I 3 -S apa
Update the group capability for a link aggregate lanadmin -X -g 900 900 900 nwmgr -s -A gc=900 -I 900 -S apa
Update the administrative key and load
balancing for a link aggregate
lanadmin -X -k 900 900 900
lanadmin -X -l LB_IP 900
nwmgr -s -A key=900 -A lb=LB_IP -I 900 -S apa
Update the administrative key and
configuration mode for a port
lanadmin -X -k 4 900 900
lanadmin -X -p 4 LACP_AUTO 900
nwmgr -s -A key=900 -A mode=LACP_AUTO -I 4 -S apa
Update the administrative key for a port lanadmin -X -k 4 900 900 nwmgr -s -A key=900 -I 4 -S apa
Update the load balancing lanadmin -X -l LB_IP 900 nwmgr -s -A lb=LB_IP -I 900 -S apa
Set the configuration mode on a port lanadmin -X -p 5 MANUAL 900 nwmgr -s -A mode=MANUAL -I 5 -S apa
Set the system priority on a port lanadmin -X -s 5 10 900 nwmgr -s -A sys_pri=10 -I 5 -S apa
Display the MAC address lanadmin -a 900 nwmgr -A mac -c lan900
Display the speed lanadmin -s 900 nwmgr -A speed -c lan900
Display the MTU, MAC address, and speed lanadmin -m -a -s 900 nwmgr -A mtu,mac,speed -c lan900
nwmgr -A all -c lan900
Display group capability lanadmin -x -g 5 900 nwmgr -A gc -I 5 -S apa
Display aggregate port status lanadmin -x -i 900 nwmgr -A all -c lan900
Display administrative key lanadmin -x -k 5 900 nwmgr -A key -I 5 -S apa
Display load balancing algorithm lanadmin -x -l 900 nwmgr -A lb -c lan900 -S apa
Display port status lanadmin -x -p 5 900 nwmgr -A mode -I 5 -S apa
Display system priority lanadmin -x -s 5 900 nwmgr -A sys_pri -I 5 -S apa
Display current port priority lanadmin -x -t 5 900 nwmgr -A port_pri -I 5 -S apa
Display aggregate status lanadmin -x -v 900 nwmgr -v -c lan900
Check network connectivity linkloop -i 900 0xaabbccddeeff nwmgr –diag -A dest=0xaabbccddeeff -c lan900
Get statistics lanadmin -g 900 nwmgr –st -c lan900
Monitoring statistics apa-monitor -p 5 nwmgr –st monitor -S apa -I 900
Reset an APA interface lanadmin -r 900 nwmgr -r -c lan900
Reset statistics lanadmin -c 900 nwmgr -r –st -c lan900
View basic help lanadmin -x -h 900 nwmgr -h -S apa
View verbose help lanadmin -X -H 900 nwmgr -h -v -S apa
Clear data flows on a link aggregate lanadmin -X -o 900 nwmgr -r -q data_flow -c lan900
List all interfaces on the system lanscan nwmgr
List all APA interfaces lanscan -q nwmgr -S apa

nwmgr -s -f -c lan1 -A mtu=1500 –cu

### change mtu on lan1 to 1500 (lanadmin -M 1 1500)

Found some really useful information on APA. So good I won’t risk it disappearing. Pretty much here for my own reference.

Tags: ,

20 Oct 09 HP-UX Integrity Software mirror procedure

This was written by a former colleague. It is better than anything else I have seen. SEP

Mirroring a Boot Disk with LVM on HP-UX 11i for HP Integrity


The following diagram shows the disk layout of a boot disk. The disk

contains a Master Boot Record (MBR) and Extensible Firmware

Interface (EFI) partition tables that point to each of the partitions. The


command is used to create the partitions (see idisk (1M)).

Figure 6-5 Example LVM Disk Layout on HP Integrity Server

Before starting the procedure, make sure that add-on product HP

MirrorDisk/UX (B5403BA) is installed. This product is an extra-cost

product available on the HP-UX 11i application release media. For


swlist -l fileset | grep -i mirror


Step 1.


Partition the disk using the idisk command and a partition description


Create a partition description file. For example:

vi /tmp/idf

In this example the partition description file contains:



HPUX 100%



an EFI partition, an HP-UX partition, and an HP Service partition.

Boot disks of earlier HP Integrity Servers may have an EFI partition

of only 100MB and may not contain the HPSP partition.

The values in the example represent a boot disk with three partitions:


Partition the disk using idisk and your partition description file:

idisk -f /tmp/idf -w /dev/rdsk/c3t1d0


To verify you can run:

idisk /dev/rdsk/c3t1d0

Step 2.

the partitions. For example:

Use the insf command with the -e option to create the device files for all

insf -e -H 0/18/1/2/

You should now have eight device files for this disk:


(This refers to the entire disk)


(This refers to the EFI partition)


(This will be the HP-UX partition)


(This refers to the Service partition)

Step 3.


Use pvcreate to make the HP-UX partition of the disk an LVMmanaged

pvcreate -B /dev/rdsk/c3t1d0s2

Step 4.

Add the disk to vg00:

vgextend vg00 /dev/dsk/c3t1d0s2

Step 5.

Place the boot files on the disk using mkboot:

mkboot -e -l /dev/rdsk/c3t1d0

Step 6.

Copy any autoboot file from the original boot disk to this one.


partition to the current directory. Make sure to use the device file

with the

Use efi_cp to copy the AUTO file from the original boot disk’s EFIs1 suffix, as it refers to the EFI partition:

efi_cp -d /dev/rdsk/cntndns1 -u /efi/hpux/auto ./AUTO



Copy the file from the current directory into the new disk’s EFI

efi_cp -d /dev/rdsk/c3t1d0s1 ./AUTO /efi/hpux/auto

Step 7.

volume group onto the desired physical volume. The logical volumes

must be extended in the same order that they are configured on the

original boot disk. Use the

determine the list of logical volumes and their order. For example:

Use the lvextend command to mirror each logical volume in the rootpvdisplay command with the -v option to

pvdisplay -v /dev/dsk/c0t0d0s2 | grep ’current.*0000$’

00000 current /dev/vg00/lvol1 00000

00038 current /dev/vg00/lvol2 00000

00550 current /dev/vg00/lvol3 00000

00583 current /dev/vg00/lvol4 00000

00608 current /dev/vg00/lvol5 00000

00611 current /dev/vg00/lvol6 00000

00923 current /dev/vg00/lvol7 00000

01252 current /dev/vg00/lvol8 00000

In this example, mirror the logical volumes as follows:

lvextend -m 1 /dev/vg00/lvol1 /dev/dsk/c3t1d0s2

lvextend -m 1 /dev/vg00/lvol2 /dev/dsk/c3t1d0s2

lvextend -m 1 /dev/vg00/lvol3 /dev/dsk/c3t1d0s2

lvextend -m 1 /dev/vg00/lv0l4 /dev/dsk/c3t1d0s2

lvextend -m 1 /dev/vg00/lvol5 /dev/dsk/c3t1d0s2

lvextend -m 1 /dev/vg00/lvol6 /dev/dsk/c3t1d0s2

lvextend -m 1 /dev/vg00/lvol7 /dev/dsk/c3t1d0s2

lvextend -m 1 /dev/vg00/lvol8 /dev/dsk/c3t1d0s2


lvextend fails with following message:

“m”: Illegal option

then HP MirrorDisk/UX is not installed.

Step 8.

Update the root volume group information:

lvlnboot -R /dev/vg00

Step 9.

disk and that the boot, root, and swap logical volumes appear to be on

both disks:

Display the BDRA. Verify that the mirrored disk is displayed as a boot

lvlnboot –v

Step 10.

Specify the mirror disk as the alternate boot path in nonvolatile memory:

setboot -a path_to_disk

Step 11.

text editor:

Add a line to /stand/bootconf for the new boot disk using vi or another

vi /stand/bootconf

l /dev/dsk/c3t1d0s2


l denotes LVM.

Tags: , , , , , , , ,

09 Sep 09 Case Study: Capacity & Migration planning for a small organization

This is our first case study. The events leading up to it occur between 1998 and 2002. It is a real life case study based on my experience. For legal reasons, I can not identify the organization. It is a charity that raises now around $100 million, 92% of funds raised go to actual charitable work. 8% is overhead. IT infrastructure is overhead, even though it is critical to actually raising funds.

From 1991-2005 I worked at this charity in IT, first as a programmer analyst, then as a dba, finally becoming the backup Unix Admin in 1998 and the full time Unix Admin in 2000. The organization ran its legacy fund raising systems on a pair of D class HP-UX systems. The back end database was Software AG adabas. The user fund raising community wanted to have an sql like ability to look into the database and run queries. they wanted flexible use of strategic data. An attempt was made in early 1997 to install a sql front end, but it did not provide acceptable results.

An internal study was done and it was decided in late 1997 to migrate legacy systems to a web based front end, with Oracle as the back end database, Oracle Application Server using forms and reports to build applications. Initially no plan was made to migrate to stronger hardware, due to the assurance from Oracle that their software would run on the existing infrastructure.

By 2000 it was obvious that this was not true. Though the database server itself ran acceptably, there was not sufficient memory or disk capacity to run the application server. So I was asked to prepare a plan to migrate legacy systems. Here were the guidelines:

  • To run three environments, to be described below, each with a database server, an application server and forms and reports development tools on them.
  • Sandbox was to be used to test OS patches, Oracle patches, and tools upgrades. It was to belong to the systems administrator who was permitted to restart this system on short or no notice.
  • The development environment was to be where the developers were to develop code. It needed to be stable and available 100% during normal development hours 8 a.m. to 6 p.m. Any changes made to his system were first to be vetted on the sandbox system.
  • The production system had the same uptime requirements accept that all changes needed to be vetted first on the other two systems.
  • The hardware was to be the same model for all the systems. This was defined to avoid hardware surprises. Only the production system needed to be at full capacity. the other systems were to be the same to permit realistic load testing.
  • Databases would be hosted on SAN disk with an HBA fiber channel connection. Systems were to boot locally.

Overall, I thought this was a solid foundation. Some of the points were made by management, some were suggested by me.

The following basic technical requirements were developed:

  • Overall database needed to be approximately 5 GB for server. Actual use hit 15 GB by 2005. This growth factor was planned.
  • Oracle Server, one instance had to run on each server.
  • Oracle Application server one instance had to run on each server.
  • Legacy applications Natural/Software AG Adabas needed to run on each server.
  • Server configuration needs to be manged and tracked responsibly.
  • HP-UX bi-annual updates needed to be installed in a timely basis after quality assurance.
  • The replacement cycle on hardware would be 3-5 years to maintain cost savings provided by being under warranty (First three years)

Deployment Diagram

Server Deployment

Other Relevant facts on the decision making process.

  • HP Hardware and Software agreements were running over $30,000 per year on existing infrastructure.
  • Much of the cost was hardware support due to the age and near obsolescence of the hardware.
  • Significant savings could be obtained by using current hardware that was under warranty.
  • Systems would be configured and used to provide a disaster recovery solution.

Three vendors were picked to provide proposals. All ended up recommending HP-9000 L2000(later renamed rp5450) servers. Here are the highlights:

  • rp5450 systems with 2 GB system memory.
  • 146 GB dual disks to server as boot disks with software mirroring.
  • 2 CPU would be installed per server.
  • Memory capacity and purchase was planned to enable an upgrade to 8 GB without replacing exiting memory.
  • Two HBA Fiber channel cards provided per machine to provide redundancy and fail over.
  • A capital budget request was made showing that support cost savings would over the course of 4 years, completely recover the cost of the systems.
  • Systems would each have a Ultirum tape drive, for locally provided backups and Ignite-UX make_tape_recovery backups as part of the DR plan.
  • Systems had two Gigabit Network Interface cards.
  • Systems would have a private network for use in Ignite backup, recovery and system replication.
  • Systems were to be delivered with HP-UX 11.11
  • HP provided RAC and UPS and PDU were specified.

How it went:

  • Systems were delivered in May of 2002.
  • Initial OS install began immediately. Systems were initially delivered with HP-UX 11.00. We delayed start of installation until correct media was provided.
  • All three systems were installed with a base OS to insure that hardware was working.
  • OS patch requirements for Oracle, security and bi-annual updates were installed on the sand box. It was decided that Ignite Golden Image would be used to replicate the sand box configuration, once a stable configuration was found.
  • Significant problems were encountered with the Oracle and Oracle Application Server installations. The version was changed twice. Several major Oracle patch sets had to be installed to deal with “show stopper” bugs that were encountered.
  • After the September 11 attacks in New York City in 2001, a security review was conducted and the deployment plan was modified to include improved security. Several rounds of patching and tools testing occurred on the OS level.
  • In December of 2002, the application development team notified us that they were satisfied with the sandbox and asked that an Ignite image be made and transferred to the development system.
  • In January-February of 2003 Imaging was done and the system was replicated. There were OS problems with the Ignite replication that took several weeks to work out.
  • Several changes were requested by the development staff. They were tested on the sand box and then deployed on the development system.
  • An Ignite central server was built on the sand box to handle images which were shared on NFS and available for use after booting of the sandbox Ignite configuration.
  • In June of 2003 after several change cycles the configuration was approved for deployment.
  • Ignite replication was completed on the production environment using the sandbox, which had been frozen for this purpose as the image template.
  • In August of 2003 all legacy systems were cut over to the rp5450 systems. HR would be migrated 18 months later due to Integration issues.
  • In the early of 2004 due to performance and memory use issues all systems were upgraded to 8 GB of system RAM.
  • For the year 2004 there was no downtime in production systems during normal business hours.
  • Weekly Ignite tape backups were taken on all systems and network based backup to shared NFS was used as a secondary DR method.
  • In February of 2004 a DR test was run at the HP Performance center and we successfully migrated a sandbox image to an rp5470 server in the HP infrastructure. Legacy systems were tested and approved as functional.

Note: This document was designed entirely using the wordpress interface and a Linux system. The diagram was created with a free Linux alternative to visio called dia. The tool is in evaluation, and might be replaced. Still a pretty good start. Cost to produce this environment in licensing fees?: Zero dollars.

Tags: , , , , , , , ,

WhatsApp chat