On the HP-UX operating system it is often thought that we must either go through some elaborate procedure to extend "/" and/or "/stand" file systems, or that it simply cannot be done at all. And that such an elaborate procedure involves down time and restoring from Ignite-UX which in most cases requires "after hours" work. In truth, the HP-UX file system is quite flexible, perhaps due to the underlying and native Veritas "roots". Manipulating any (VXFS) file system under HP-UX is very easy and can be accomplished dynamically if the system meets certain prerequisites. The following procedure will examine these requirements and detail the process.

Background
Assumptions
Requirements
Architecture
Procedure
Conclusion
Printing

Background

The real issue with extending either of these two file systems is that the underlying logical volumes were created with a strict/contiguous extent allocation policy. A logical volume that is created with contiguous block allocation can only be extended if there are more contiguous blocks available. In the case of these two logical volumes the allocation cannot be changed either.

So how do we "dynamically" extend either or both of these logical volumes? One way to accomplish this is to move the logical volume somewhere within the volume group where enough total contiguous space exists, and then extend it. Before we can move a logical volume we must certainly break any associated mirrors. This of course creates a single point of failure but only for a short amount of time. Naturally prior to this operation it is highly recommended to take a full image backup of the root volume group with Ignite-UX. The general idea of this solution is to move logical volumes around, extend them and then move them back to form the same logical mirrored environment from which we started. Of course keep in mind that we do not want our users and their applications effected performance-wise at all.

The assumptions in our case will be that we are starting with a properly mirrored OS; mirrored across two identically sized physical disks, and that all logical volumes are mirrored. We can also assume that this system has been tested successfully booting from the primary boot disk as well as the alternate, but we will take a closer look in this procedure just to make sure. We are also going to assume that we really only want to extend "/". There should hardly ever be a need to extend "/stand". However, if /stand needs extending, this article can be used for instruction. The only difference, since /stand can be unmounted, is that OnLineJFS may be unnecessary.

The requirements for this exercise are really quite basic and most HP "shops" consider them as a "standard", but nonetheless we will list them.

• Experience moving data around. Even though this procedure is "fool proof", it should be required that the person "pulling the trigger" be comfortable doing it.

• OnlineJFS is required to dynamically extend "/". Extending "/stand" does not require OnlineJFS because it can be unmounted at any run level. However, if there is unexpected activity within the file system, like someone manually building a new kernel, OnlineJFS will be required here as well.

• MirrorDisk-UX is required if the logical volumes are mirrored.

• Disk space is required to perform this procedure. Either add a spare disk to the volume group temporarily or better yet simply use one of the mirrored disks.

This image illustrates the method that (by default) the HP-UX installer created file systems. File systems are layed down one after another, contiguously, unless you tell the installer otherwise, which is rarely done. Also depicted is the boot disk configuration used in this article. Notice that the only volume, if all were created strict/contiguous, that could be extended would be lvol8.

For the remainder of this article, we will refer to the two physical disks as the "primary" and "alternate" boot disks.

The hardware and Software configuration that we are using for this exercise is as follows:

• HP 9000 B132 Workstation
• Two (2) 4GB SCSI Drives
• HP-UX 11.0
• Hostname: hp1
• HP OnLineJFS (Advanced VxFS) B5118BA
• HP MirrorDisk/UX B5403BA

Now that we have laid the groundwork, let's get going with the actual steps. Remember that all we are really doing is (1) breaking all mirrors, (2) moving (pvmove) data to a place where it can be extended, (3) moving it back to where we started, and (4) establishing the mirrors.

NOTE: DO NOT PROCEED WITHOUT A FULL OS BACKUP! There are several ways and several products that can be used to backup your Operating System. We prefer Ignite-UX, but there are others. OS image-level backups are outside the scope of this article so we will not do one here. You certainly can assume that we have protected ourselves prior to moving to the next steps of this exercise.

Let's check things out and make sure that all the prerequisites have been met. First, check to see if the appropriate software has been installed.

	      
hostname
swlist | egrep -i 'jfs|mirror'
	      
            

Next, let's take a look at the booting configuration of the root volume group (vg00). Since we are in a situation where a reboot is not possible, we are going to assume that whoever set this system up did so correctly and tested booting from both the primary and alternate boot device. After performing this procedure the system should be booted again from both devices whenever it can be scheduled. Performing this step, as shown, will give you a good idea if the system has been configured correctly. Still no guarentees.

              
hostname
vgdisplay -v vg00 | grep "PV Name"
lvlnboot -v vg00
setboot
              
            

So how do we confirm that we have a problem extending the "/" file system? Let's try to extend it "as is" and see what happens. The problem is exposed, but of course we already knew this didn't we?

              
hostname
bdf
lvextend -L 300 /dev/vg00/lvol3
              
            

Break all mirrors as shown here. Note that the screen shot was taken before the operation completely finished.

              
hostname
bdf
for i in 1 2 3 4 5 6 7 8
  do lvreduce -m 0 /dev/vg00/lvol$i \
                   /dev/dsk/c1t4d0
done
              
            

After all mirrors are broken, we expect the alternate boot disk to now be empty. Verify this fact as shown here.

              
hostname
bdf
pvdisplay -v /dev/dsk/c1t4d0 | egrep 'Total PE|Free PE'
              
            

Now we begin the interesting part of this exercise. Recall that we are only interested in extending "/" or lvol3. Since lvol3 has a strict/contiguous extent allocation policy we must put it somewhere with available extents immediately following the logical volume itself. This part of the exercise can probably be done any number of ways. Our way will be to move (pvmove) lvol1, lvol2, and lvol3 to the alternate boot disk, respectively. Logical volume lvol3 must be the last one moved. Again, please note that we took the screenshot before the command completed.

              
hostname
bdf
for i in 1 2 3 4 5 6 7 8
do
  pvmove -n /dev/vg00/lvol$i /dev/dsk/c0t6d0 \
  /dev/dsk/c1t4d0
done
              
            

Now that we have moved lvol3 to a "good place" we can extend it as necessary. We have chosen to extend it from 250MB to 300MB. Use lvextend and fsadm as shown. Notice we no longer get the error we saw earlier, because there ARE now available extents immediately following lvol3.

              
hostname
bdf
lvextend -L 300 /dev/vg00/lvol3
fsadm -F vxfs -b 307200 /
bdf
              
            

It seems to us that at this point we will simply move (pvmove) the remaining logical volumes to the alternate boot disk, appending them to the newly extended lvol3. Once there we can simply mirror back to the primary boot disk. Again, the screenshot was taken before command completion.

              
hostname
bdf
for i in 4 5 6 7 8
do
  pvmove -n /dev/vg00/lvol$i /dev/dsk/c0t6d0 \
                             /dev/dsk/c1t4d0
done
              
            

Now you should verify that the primary boot disk is actually empty as shown here.

              
hostname
bdf
pvdisplay -v /dev/dsk/c0t6d0 | egrep 'Total PE|Free PE'
              
            

Now comes the "smoke and mirrors" part of the procedure. The intent is to mirror all the logical volumes back to their original state and when completed, have a perfectly bootable (primary and alternate) system. Of course the only difference that we want to see is an extended "/" file system. We will not elaborate on the individual commands used below, but if you are seasoned enough to follow this article that you should have already had experience with all the commands. If not, look them up prior to their execution. Here you can see that we remove the primary boot disk from the volume group, re-initialize it and then bring it back into vg00.

              
hostname
vgreduce /dev/vg00 /dev/dsk/c0t6d0
pvcreate -B /dev/rdsk/c0t6d0
vgextend /dev/vg00 /dev/dsk/c0t6d0
vgcfgrestore -n /dev/vg00 /dev/rdsk/c0t6d0
vgchange -a y /dev/vg00
vgsync /dev/vg00
              
            

Continue preparing the primary boot disk.

              
hostname
mkboot -l /dev/dsk/c0t6d0
lvlnboot -r /dev/vg00/lvol3
lvlnboot -b /dev/vg00/lvol1
lvlnboot -s /dev/vg00/lvol2
lvlnboot -d /dev/vg00/lvol2
lvlnboot -R
              
            

Now that the primary boot disk as back in vg00 and has been prepared, mirror all logical volumes from the alternate boot disk to the primary boot disk as shown here.

              
hostname
for i in 1 2 3 4 5 6 7 8
do
lvextend -m 1 /dev/vg00/lvol$i \
              /dev/dsk/c0t6d0
done
              
            

After the mirrors have been successfully created, re-execute the commands from above that check out the boot configuration of vg00. It should look exactly as it did then.

              
hostname
lvlnboot -v vg00
setboot
              
            

NOTE: Now that you have completed this exercise, you will want to schedule a reboot to test booting from both primary and alternate boot devices. Also it would not hurt to get another image-level backup at this time since you have now changed the OS.

Well, there you have it! If you are not familiar with HP-UX disk layouts and the LVM command set, it might seem a little complicated. But if you are comfortable with the concepts and commands, the only slow part of this exercise will be waiting on particular commands (pvmove, lvextend) to complete.

If systems administration has become simply a matter of executing commands and you have been forced into "thinking inside the box" perhaps this article will help move you to the outside of the box. Remember, even when you cannot find reference to performing a particular task, give it some thought and maybe you can come up with the right, better solution as we did here.

As it turns out, as we are busy working on the HTML/CSS/php/Java Script formatting of our articles, pretty printing is not yet possible. We are working on it at a low priority.