2010.H3064S StudentGuide-01 PDF

HP-UX System and Network
Administration I
H3064S J.00
Student guide
1 of 3
Use of this material to deliver training without prior written permission from HP is prohibited.
HP-UX System and Network
Administration I
H3064S J.00
Student guide
1 of 3
Use of this material to deliver training without prior written permission from HP is prohibited.
© Copyright 2010 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice. The only warranties for
HP products and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an additional
warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
This is an HP copyrighted work that may not be reproduced without the written permission of
HP. You may not use these materials to deliver training to any person outside of your
organization without the written permission of HP.
UNIX® is a registered trademark of The Open Group.
X/Open® is a registered trademark, and the X device is a trademark of X/Open Company
Ltd. in the UK and other countries.
Export Compliance Agreement
Export Requirements. You may not export or re-export products subject to this agreement in
violation of any applicable laws or regulations.
Without limiting the generality of the foregoing, products subject to this agreement may not be
exported, re-exported, otherwise transferred to or within (or to a national or resident of)
countries under U.S. economic embargo and/or sanction including the following countries:
Cuba, Iran, North Korea, Sudan and Syria.
This list is subject to change.
In addition, products subject to this agreement may not be exported, re-exported, or otherwise
transferred to persons or entities listed on the U.S. Department of Commerce Denied Persons
List; U.S. Department of Commerce Entity List (15 CFR 744, Supplement 4); U.S. Treasury
Department Designated/Blocked Nationals exclusion list; or U.S. State Department Debarred
Parties List; or to parties directly or indirectly involved in the development or production of
nuclear, chemical, or biological weapons, missiles, rocket systems, or unmanned air vehicles
as specified in the U.S. Export Administration Regulations (15 CFR 744); or to parties directly
or indirectly involved in the financing, commission or support of terrorist activities.
By accepting this agreement you confirm that you are not located in (or a national or resident
of) any country under U.S. embargo or sanction; not identified on any U.S. Department of
Commerce Denied Persons List, Entity List, US State Department Debarred Parties List or
Treasury Department Designated Nationals exclusion list; not directly or indirectly involved in
the development or production of nuclear, chemical, biological weapons, missiles, rocket
systems, or unmanned air vehicles as specified in the U.S. Export Administration Regulations
(15 CFR 744), and not directly or indirectly involved in the financing, commission or support
of terrorist activities.
Printed in the US
HP-UX System and Network Administration I
Student guide (1 of 3)
September 2010
Contents
Module 1 ⎯ Course Overview

1–1. SLIDE: Course Audience ...................................................................................................... 1-2
1–2. SLIDE: Course Agenda.......................................................................................................... 1-3
1–3. SLIDE: HP-UX Versions ........................................................................................................ 1-4
1–4. SLIDE: HP-UX System Administration Resources ............................................................ 1-6
Module 2 — Navigating SAM and the SMH

2–1. SLIDE: SAM and SMH Overview ......................................................................................... 2-2
2–2. SLIDE: Launching the SMH TUI .......................................................................................... 2-5
2–3. SLIDE: Launching the SMH GUI via Autostart .................................................................. 2-7
2–4. SLIDE: Launching the SMH GUI via Start-on-Boot ........................................................... 2-9
2–5. SLIDE: Verifying the SMH Certificate ............................................................................... 2-11
2–6. SLIDE: Logging into the SMH............................................................................................. 2-13
2–7. SLIDE: SMH Menus and Tabs ............................................................................................ 2-14
2–8. SLIDE: SMH->Home (1 of 2) .............................................................................................. 2-16
2–9. SLIDE: SMH->Home (2 of 2) .............................................................................................. 2-18
2–10. SLIDE: SMH->Tools (1 of 4)............................................................................................. 2-19
2–14. SLIDE: SMH->Settings ...................................................................................................... 2-24
2–15. SLIDE: SMH->Tasks .......................................................................................................... 2-26
2–16. SLIDE: SMH->Logs ............................................................................................................ 2-27
2–17. SLIDE: SMH Group Access Control ................................................................................ 2-29
2–18. SLIDE: SMH Authentication............................................................................................. 2-32
2–19. SLIDE: SMH and SIM Integration Possibilities .............................................................. 2-34
2–20. SLIDE: For Further Study................................................................................................. 2-36
2–21. LAB: Configuring and Using the System Management Homepage.............................. 2-37
2–22. LAB SOLUTIONS: Configuring and Using the System Management Homepage....... 2-43
Module 3 ⎯ Managing Users and Groups

3–1. SLIDE: User and Group Concepts ....................................................................................... 3-2
3–2. SLIDE: What Defines a User Account? ............................................................................... 3-4
3–3. SLIDE: The /etc/passwd File .......................................................................................... 3-5
3–4. SLIDE: The /etc/shadow File .......................................................................................... 3-9
3–5. SLIDE: The /etc/group File........................................................................................... 3-14
3–6. SLIDE: Creating User Accounts......................................................................................... 3-17
3–7. SLIDE: Modifying User Accounts ...................................................................................... 3-21
3–8. SLIDE: Deactivating User Accounts.................................................................................. 3-24
3–9. SLIDE: Removing User Accounts ...................................................................................... 3-26
3–10. SLIDE: Configuring Password Aging .............................................................................. 3-28
3–11. SLIDE: Configuring Password Policies........................................................................... 3-31
3–12. SLIDE: Managing Groups ................................................................................................. 3-33
3–13. SLIDE: Managing /etc/skel......................................................................................... 3-36
3–14. LAB: Managing User Accounts ........................................................................................ 3-40
3–15. LAB SOLUTIONS: Managing User Accounts.................................................................. 3-46
http://education.hp.com i H3064S I.00

© 2009 Hewlett-Packard Development Company, L.P.
Contents
Module 4 ⎯ Navigating the HP-UX File System

4–1. SLIDE: Introducing the File System Paradigm...................................................................4-2
4–2. SLIDE: System Directories ...................................................................................................4-4
4–3. SLIDE: Application Directories ............................................................................................4-8
4–4. SLIDE: Commands to Help You Navigate ...........................................................................4-9
4–5. LAB: HP-UX File System Hierarchy...................................................................................4-11
4–6. LAB SOLUTIONS: HP-UX File System Hierarchy ............................................................4-13
Module 5 — Configuring Hardware

5–1. SLIDE: Hardware Components ............................................................................................5-2
5–2. SLIDE: CPUs...........................................................................................................................5-3
5–3. SLIDE: Cell Boards, Blades, Crossbars, and Blade Links .................................................5-7
5–4. SLIDE: SBAs, LBAs, and PCI Expansion Buses ...............................................................5-10
5–5. SLIDE: iLO / MP Cards ........................................................................................................5-13
5–6. SLIDE: Core I/O Cards.........................................................................................................5-15
5–7. SLIDE: Internal Disks, Tapes, and DVDs ..........................................................................5-17
5–8. SLIDE: Interface Adapter Cards.........................................................................................5-18
5–9. SLIDE: Disk Arrays and LUNs ............................................................................................5-20
5–10. SLIDE: SANs and Multipathing ........................................................................................5-23
5–11. SLIDE: Partitioning Overview ..........................................................................................5-25
5–12. SLIDE: nPar, vPar, VM, and Secure Resource Partition Overview ..............................5-26
5–13. SLIDE: Part 2: System Types ............................................................................................5-29
5–14. SLIDE: Integrity Server Overview....................................................................................5-30
5–15. SLIDE: Entry-Class Rackmount Server Overview .........................................................5-33
5–16. SLIDE: Entry-Class Rackmount Server Example: HP Integrity rx2660 (front)..........5-35
5–17. SLIDE: Entry-Class Rackmount Server Example: HP Integrity rx2660 (rear) ...........5-36
5–18. SLIDE: Mid-Range Cell-Based Server Overview ............................................................5-37
5–19. SLIDE: Mid-Range Cell-Based Server Example: HP Integrity rx8640 (front) .............5-38
5–20. SLIDE: Mid-Range Cell-Based Server Example: HP Integrity rx8640 (rear)...............5-39
5–21. SLIDE: High-End Cell-Based Server Overview...............................................................5-40
5–22. SLIDE: High-End Cell-Based Server Example: HP Integrity Superdome (front) .......5-41
5–23. SLIDE: High-End Cell-Based Server Example: HP Integrity Superdome (rear).........5-43
5–24. SLIDE: HP BladeSystem Overview ..................................................................................5-44
5–25. SLIDE: HP BladeSystem Enclosure Overview ...............................................................5-47
5–26. SLIDE: HP BladeSystem Enclosure Example: HP BladeSystem c7000 Enclosure....5-49
5–27. SLIDE: HP Integrity Blade Server Model Overview.......................................................5-50
5–28. SLIDE: HP Integrity Server Blade Example: HP Integrity BL890c i2...........................5-51
5–29. SLIDE: HP Integrity Superdome 2 Overview ..................................................................5-54
5–30. SLIDE: HP Integrity Superdome 2 Example: HP Integrity Superdome 2 ....................5-55
5–31. SLIDE: Viewing the System Configuration .....................................................................5-57
5–32. SLIDE: Viewing nPar, vPar, and VM Hardware ..............................................................5-60
5–33. SLIDE: Part 3: HP-UX Hardware Addressing..................................................................5-61
5–34. SLIDE: Hardware Addresses ............................................................................................5-62
5–35. SLIDE: Legacy vs. Agile View Hardware Addresses ......................................................5-63
5–36. SLIDE: Legacy HBA Hardware Addresses ......................................................................5-66
5–37. SLIDE: Legacy Parallel SCSI Hardware Addresses .......................................................5-68
5–38. SLIDE: Legacy FC Hardware Addresses (1 of 2)............................................................5-70
5–39. SLIDE: Legacy FC Hardware Addresses (2 of 2)............................................................5-72
5–40. SLIDE: Viewing Legacy HP-UX Hardware Addresses ...................................................5-73
5–41. SLIDE: Agile View HBA Hardware Addresses................................................................5-77
5–42. SLIDE: Agile View Parallel SCSI Hardware Addresses .................................................5-79
5–43. SLIDE: Agile View FC Lunpath Hardware Addresses (1 of 2).....................................5-81
H3064S I.00 ii http://education.hp.com

Contents
5–44. SLIDE: Agile View FC Lunpath Hardware Addresses (2 of 2) .................................... 5-83

5–45. SLIDE: Agile View FC LUN Hardware Path Addresses ................................................ 5-84
5–46. SLIDE: Viewing LUN Hardware Paths via Agile View................................................... 5-86
5–47. SLIDE: Viewing LUNs and their lunpaths via Agile View ............................................. 5-88
5–48. SLIDE: Viewing HBAs and their lunpaths via Agile View ............................................. 5-90
5–49. SLIDE: Viewing LUN Health via Agile View ................................................................... 5-92
5–50. SLIDE: Viewing LUN Attributes via Agile View ............................................................. 5-94
5–51. SLIDE: Enabling and Disabling lunpaths via Agile View .............................................. 5-96
5–52. SLIDE: Part 4: Slot Addressing ........................................................................................ 5-98
5–53. SLIDE: Slot Address Overview ........................................................................................ 5-99
5–54. SLIDE: Slot Address Components................................................................................. 5-100
5–55. SLIDE: Viewing Slot Addresses ..................................................................................... 5-102
5–56. SLIDE: Part 6: Managing Cards and Devices................................................................ 5-104
5–57. SLIDE: Installing Interface Cards w/out OL* (11i v1, v2, v3) ..................................... 5-105
5–58. SLIDE: Installing Interface Cards with OL* (11i v1) ................................................... 5-107
5–59. SLIDE: Installing Interface Cards with OL* (11i v2, v3) ............................................. 5-110
5–60. SLIDE: Installing New Devices (11i v1, v2, v3) ............................................................ 5-114
5–61. LAB: Exploring the System Hardware .......................................................................... 5-116
5–62. LAB SOLUTIONS: Exploring the System Hardware ................................................... 5-125
Module 6 ⎯ Configuring Device Files

6–1. SLIDE: Device Special File Overview ................................................................................. 6-2
6–2. SLIDE: DSF Attributes .......................................................................................................... 6-4
6–3. SLIDE: DSF Types: Legacy vs. Persistent........................................................................... 6-7
6–4. SLIDE: DSF Directories ........................................................................................................ 6-9
6–5. SLIDE: Legacy DSF Names ................................................................................................ 6-10
6–6. SLIDE: Persistent DSF Names ........................................................................................... 6-14
6–7. SLIDE: LUN, Disk, and DVD DSF Names ......................................................................... 6-16
6–8. SLIDE: Boot Disk DSF Names ........................................................................................... 6-17
6–9. SLIDE: Tape Drive DSF Names ......................................................................................... 6-19
6–10. SLIDE: Tape Autochanger DSF Names........................................................................... 6-22
6–11. SLIDE: Terminal, Modem, and Printer DSF Names ...................................................... 6-24
6–12. SLIDE: Listing Legacy DSFs............................................................................................. 6-27
6–13. SLIDE: Listing Persistent DSFs........................................................................................ 6-29
6–14. SLIDE: Correlating Persistent DSFs with LUNs and lunpaths..................................... 6-31
6–15. SLIDE: Correlating Persistent DSFs with WWIDs......................................................... 6-33
6–16. SLIDE: Correlating Persistent DSFs with Legacy DSFs ............................................... 6-35
6–17. SLIDE: Decoding Persistent and Legacy DSF Attributes ............................................. 6-37
6–18. SLIDE: Managing Device Files......................................................................................... 6-40
6–19. SLIDE: Creating DSFs via insf ...................................................................................... 6-42
6–20. SLIDE: Creating DFSs via mksf ...................................................................................... 6-44
6–21. SLIDE: Creating DSFs via mknod.................................................................................... 6-46
6–22. SLIDE: Removing DSFs via rmsf.................................................................................... 6-48
6–23. SLIDE: Disabling and Enabling Legacy Mode DSFs...................................................... 6-50
6–24. LAB: Configuring Device Files......................................................................................... 6-51
6–25. LAB SOLUTIONS: Configuring Device Files .................................................................. 6-56
Module 7 ⎯ Managing Disk Devices

7–1. SLIDE: Disk Partitioning Concepts ..................................................................................... 7-2
7–2. SLIDE: Whole Disk Partitioning Concepts ......................................................................... 7-4
7–3. SLIDE: Logical Volume Manager Concepts........................................................................ 7-6
http://education.hp.com iii H3064S I.00

Contents
7–4. SLIDE: LVM Physical Volume Concepts .............................................................................7-8

7–5. SLIDE: LVM Volume Group Concepts...............................................................................7-10
7–6. SLIDE: LVM Logical Volume Concepts .............................................................................7-12
7–7. SLIDE: LVM Extent Concepts ............................................................................................7-14
7–8. SLIDE: LVM Extent Size Concepts ....................................................................................7-16
7–9. SLIDE: LVM Volume Group Versions and Limits .............................................................7-18
7–10. SLIDE: LVM DSF Directories............................................................................................7-21
7–11. SLIDE: LVMv1 Volume Group and Logical Volume DSFs.............................................7-23
7–12. SLIDE: LVMv2 Volume Group and Logical Volume DSFs.............................................7-25
7–13. SLIDE: Creating Physical Volumes ..................................................................................7-26
7–14. SLIDE: Creating LVMv1 Volume Groups.........................................................................7-29
7–15. SLIDE: Creating LVMv2 Volume Groups.........................................................................7-33
7–16. SLIDE: Creating Logical Volumes ....................................................................................7-35
7–17. SLIDE: Verifying the Configuration .................................................................................7-37
7–18. SLIDE: Disk Space Management Tool Comparison.......................................................7-42
7–19. LAB: Configuring Disk Devices ........................................................................................7-46
7–20. LAB SOLUTIONS: Configuring Disk Devices .................................................................7-57
Module 8 ⎯ Managing File Systems

8–1. SLIDE: File System Overview...............................................................................................8-2
8–2. SLIDE: File System Types .....................................................................................................8-4
8–3. SLIDE: Part 1: File System Concepts...................................................................................8-8
8–4. SLIDE: Superblock Concepts ...............................................................................................8-9
8–5. SLIDE: Inode Concepts .......................................................................................................8-11
8–6. SLIDE: Directory Concepts.................................................................................................8-13
8–7. SLIDE: Block and Extent Concepts...................................................................................8-14
8–8. SLIDE: Hard Link Concepts................................................................................................8-16
8–9. SLIDE: Symbolic Link Concepts ........................................................................................8-18
8–10. SLIDE: Intent Log Concepts .............................................................................................8-20
8–11. SLIDE: HFS / VxFS Comparison ......................................................................................8-22
8–12. SLIDE: Part 2: Creating and Mounting File Systems .....................................................8-27
8–13. SLIDE: Overview: Creating and Mounting a File System..............................................8-28
8–14. SLIDE: Creating a File System .........................................................................................8-30
8–15. SLIDE: Mounting a File System........................................................................................8-33
8–16. SLIDE: Unmounting a File System...................................................................................8-37
8–17. SLIDE: Automatically Mounting File Systems................................................................8-39
8–18. SLIDE: Mounting CDFS File Systems..............................................................................8-41
8–19. SLIDE: Mounting ISO Files ...............................................................................................8-44
8–20. SLIDE: Mounting LOFS File Systems ..............................................................................8-46
8–21. SLIDE: Mounting MemFS File Systems...........................................................................8-48
8–22. LAB: Creating and Mounting File Systems .....................................................................8-50
8–23. LAB SOLUTIONS: Creating and Mounting File Systems...............................................8-63
H3064S I.00 iv http://education.hp.com

Module 1 ⎯ Course Overview
Objectives
Upon completion of this module, you will be able to do the following:
• Describe the target audience for this course.
• List the topics covered in this course.
• List the currently supported HP-UX operating system versions.
• List some common reference sources used by HP-UX system administrators.
• Determine a system’s current OS version.
http://education.hp.com 1-1 H3064S J.00

Module 1
Course Overview
1–1. SLIDE: Course Audience
Course Audience
This fast-paced 5-day course is the first of two courses HP offers to prepare
new UNIX administrators to successfully manage an HP-UX server or
workstation.
The course assumes that the student has experience with general UNIX user
commands.
Student Notes
This fast-paced 5-day course is the first of two courses HP offers to prepare new UNIX
administrators to successfully manage an HP-UX server or workstation.
The course assumes that the student has experience with general UNIX user commands.
H3064S J.00 1-2 http://education.hp.com

Module 1
Course Overview
1–2. SLIDE: Course Agenda
Course Agenda
Course Overview Accessing the System Console
Navigating the SMH Booting PA-RISC Systems
Managing Users and Groups Booting Integrity Systems
Navigating the HP-UX File System Configuring the Kernel
Managing Hardware Managing Software with SD-UX

Managing Device Files Managing Patches with SD-UX
Managing Disk Devices Installing the OS with Ignite-UX
Course Review
Managing File Systems
Managing Swap Space
Maintaining Disks and File Systems
Preparing for Disasters
Student Notes
HP-UX System Administrators often serve a number of roles – from configuring peripherals,
to managing user accounts, to installing software and patches. Over the span of five days,
this course covers the core skills required by all HP-UX system administrators.
HP recommends that students attend the follow-on to this course, HP-UX System and
Network Administration 2 (H3065S), to complete the course sequence for new HP-UX
administrators.
HP Education also offers courses covering numerous advanced HP-UX system and network
administration topics. See our website, http://www.hp.com/education for more
information.

Module 1
Course Overview
1–3. SLIDE: HP-UX Versions
HP-UX Versions
• HP currently supports several HP-UX 11i versions
• Slides and notes in this course cover all three current versions
• Labs will be completed on 11i v3
Release Release Supports PARISC Supports Integrity

Identifier Name Servers Workstations Servers Workstations
11.11 11i v1 yes yes no no
11.23.yymm* 11i v2 yes no yes no
11.31.yymm* 11i v3 yes no yes no
* Updated 11i v2/v3 media kits continue to be released every ~six months
Student Notes
Since HP-UX 11i was first released for PA-RISC in 2000, HP has released a number of
versions of the operating system for the Integrity product line. The table on the slide lists the
release identifier (as reported by HP-UX commands), release name (as used in the HP-UX
documentation), and supported platform for each release of HP-UX 11i. HP distributes
updated media kits with new patches and minor software updates approximately every six
months. The four digits following “11i v1v2/v3” indicate each release’s release year and
month.
Use the uname -r command to determine which HPUX version your system is currently
running:
# uname -r
B.11.31

Module 1
Course Overview
To determine which media kit your system was installed from, use swlist to check the
version# on the QPKBASE patch bundle.
# swlist -l bundle QPKBASE

# Initializing...
# Contacting target "rx26u221"...
#
# Target: myhost:/
#
QPKBASE B.11.31.0903.334a Base Quality Pack Bundle for HP-UX 11i
v3, March 2009
The slides and notes in this course cover all three currently supported versions of the
operating system: 11i v1, v2, and v3. The lab exercises require 11i v3.
To determine end of support dates for each current HP-UX version, see HP’s support
roadmap online at http://www.hp.com/go/hpuxservermatrix.

Module 1
Course Overview
1–4. SLIDE: HP-UX System Administration Resources
HP-UX System Administration Resources

In addition to the traditional UNIX HP’s product website:
man pages, HP provides a number http://www.hp.com/
of resources that you can use to
learn more about your HP-UX HP’s IT Resource Center:
system. http://itrc.hp.com/
HP’s documentation website:

http://docs.hp.com/
HP’s software download website:

http://software.hp.com/
HP Education Services:
http://www.hp.com/education
Student Notes
Beyond this course, there is a wealth of resources available to assist new HP-UX system
administrators.
http://www.hp.com HP’s corporate/product website describes all of

HP’s current hardware, software, and service
offerings.
http://itrc.hp.com HP’s IT Resource Center provides a wealth of

cookbooks, white papers, FAQ lists, patches, user
forums, and an online response center that you can
use to research HP-UX features and problems. The
ITRC user forums are particularly helpful. Portions
of the ITRC content are only available to customers
with support contracts.

Module 1
Course Overview
http://docs.hp.com HP’s documentation website provides an online,

searchable library containing all of HP’s HP-UX
manuals. If your site doesn’t have Internet access,
the Instant Information DVD included in the HP-UX
media kit provides DVD-based access to the same
documents.
The HP-UX System Administrator’s Guide,

volumes 1-5, provides particularly useful
information for new HP-UX 11i v3 system
administrators.
The equivalent HP-UX 11i v1 and v2 manual is titled

Managing Systems and Workgroups: A Guide for
HP-UX System Administrators.
http://software.hp.com/ Visit HP’s software download website to download

and purchase HP-UX software products and
updates.
http://www.hp.com/education HP Education Services offers a wide variety of

courses on HP-UX and other HP products. Visit our
website regularly to stay abreast of the latest course
offerings.

Module 1
Course Overview

Module 2 — Navigating the SMH
Objectives
• Describe the purpose and features of SAM and the SMH.
• Launch the SMH GUI and TUI interfaces.
• Enable SMH autostart functionality.
• View hardware status information via the SMH.
• Launch SMH tools.
• Create custom SMH tools.
• Execute SMH tasks.
• View log files via the SMH.
• Configure SMH group access rights.
• Configure SMH authentication.
• Describe SMH/SIM integration possibilities.

Module 2
Navigating the SMH
2–1. SLIDE: SAM and SMH Overview
SAM and SMH Overview

• SAM provides an intuitive, menu-based administration interface in 11i v1 and v2
• SMH provides an intuitive, menu-based administration interface in 11i v3
• Both tools simplify complex administration tasks and minimize errors
• Both tools are sometimes less flexible than the command-line interface
Feature SAM SMH

HP-UX versions support 11i v1, v2 11i v1*, v2*, v3
Intuitive Terminal User Interface (TUI) Yes Yes, in 11i v3 only
Intuitive Graphical User Interface (GUI) X-based Web-based
Configurable to provide access to non-root users Yes Yes
Built-in help facility Yes Yes
Customizable and extensible Yes Yes
Uses standard HP-UX commands to perform tasks No Yes
Integrates with HP Systems Insight Manager (SIM) No Yes
Windows, Linux support No Yes
Student Notes
New HP-UX System Administrators often find that the HP’s System Administration Manager
(SAM) and the System Management Homepage (SMH) interfaces simplify many
administration tasks.
Both tools provide intuitive, menu-based interfaces for adding users, configuring the kernel,
configuring network interface cards, and other common administration tasks. Both also
include informative help screens, and automatic error-checking.
Like many menu-based interfaces, though, both SAM and SMH often provide less flexibility
than command line utilities.
The notes below describe the features of both tools. The remainder of this module focuses
on the SMH. An appendix at the end of the course discusses SAM in a bit more detail.

Module 2
Navigating the SMH
HP-UX versions supported

SAM is the primary menu-based administration tool for 11i v1 and v2. The SMH is available
for these older versions of the operating system, but with limited functionality.
SMH replaces SAM entirely in 11i v3. The /usr/sbin/sam command is still available in 11i
v3, but launches the SMH rather than SAM. The latest version of the SMH for all versions of
HP-UX may be downloaded from http://software.hp.com.
Intuitive Terminal User Interface (TUI)

SAM provides an intuitive Terminal User Interface (TUI) that may be accessed in any 80x24
terminal or terminal emulator window. The TUI interface relies on standard keyboard keys
rather than a mouse to navigate the SAM menus.
In 11i v3, the SMH provides a TUI interface, too.
Intuitive Graphical User Interface (GUI)

SAM and the SMH both provide an intuitive graphical user interface. Administrators use a
mouse and keyboard to navigate the administration menus.
SAM’s GUI requires X-windows. The SMH uses a more flexible, SSL-protected, web-based
GUI interface that may be accessed from any Internet Explorer or Firefox web browser.
Accessing the system via a web interface provides much greater flexibility for administrators
who manage systems remotely.
Configurable to provide access to non-root users

By default, only users with root privileges can access SAM and the SMH. However,
administrators can grant full or restricted access to other users and operators who help
manage the system, too. This makes it possible to provide root-like privileges without
sharing the root password.
Built-in help facility

SAM and the SMH both provide extensive online help.
Customizable and extensible

Administrators can add custom tools to the SAM and SMH interfaces. For instance, an
administrator might add a custom tool to launch database daemons directly from the
SAM/SMH interface.
Uses standard HP-UX commands to perform tasks

The SMH relies primarily on standard HP-UX commands. Administrators can review
commands in the SMH log file and can use those commands in scripts.
SAM uses HP-UX commands and backend scripts and executables to complete
administration tasks. Administrators can review the commands in the
/var/sam/log/samlog file, but many of the commands called from the SAM interface
cannot be executed outside of SAM.

Module 2
Navigating the SMH
Integrates with HP Systems Insight Manager (SIM)

HP Systems Insight Manager (SIM) provides an intuitive web interface for managing multiple
of HP servers, blades, network, and storage devices. When SIM reports a problem with a
server, a few mouse clicks automatically launch the server’s SMH page so the administrator
can research the cause of the problem or execute an SMH tool to resolve the issue.
SAM is not integrated with SIM.
Windows, Linux support

Though this course focuses on using SMH to manage HPUX, the product is also available for
customers running Microsoft Windows or Linux on any HP Proliant or Integrity servers. The
SMH tools vary somewhat, but the SMH interface, architecture, and look and feel is
consistent across platforms and operating systems.
SAM is only available on HP-UX.

Module 2
Navigating the SMH
2–2. SLIDE: Launching the SMH TUI
Launching the SMH TUI

• The SMH offers a web interface and, in 11i v3, a TUI interface
• Use smh to launch the TUI interface
• Use the arrow keys and shortcuts listed at the bottom of each screen to navigate the TUI
# smh
SMH->Accounts for Users and Groups->Local Users

----------------------------------------------------------------
Login Name User ID Primary Group Real Name Last Login
================================================================
user1 301 class student NEVER
user2 302 class student Mon Jun 11 12:56:10
user3 303 class student NEVER
user4 304 class student Thu Jun 14 10:23:20
<-------------------------------------------------------------->
x-Exit smh ESC-Back 1-Help m-Modify User
ENTER-Details /-Search a-Add User Ctrl o-Other Actions16
NOTE: this screenshot has been formatted and truncated to fit the slide
Student Notes
SMH is included on the operating environment DVDs for HP-UX 11i v1 (since September
2005), 11i v2 (since May 2005), and 11i v3 (all media kits). You can also download the
product from http://software.hp.com.
Not all SMH features are available on all HP-UX versions. New media kits often introduce
new SMH functionality. Use the swlist command to determine your system’s SMH version.
# swlist SysMgmtWeb
SMH has several additional dependencies, all of which are included in the 11i v2 and 11i v3
operating environments. On 11i v1, HP also recommends installing the KRNG11i patch
bundle from http://software.hp.com for improved security.
The SMH offers a web interface in all HP-UX versions, and, in 11i v3, a TUI interface as well.
To launch the TUI interface, log into the target system as user root using any 24x80 terminal
emulator, and run smh.

Module 2
Navigating the SMH
Use the [Tab] key to jump back and forth between the menu bar and the other regions on
the screen, and the arrow keys to scroll up and down and left and right. Look for keyboard
shortcuts at the bottom of the screen.

Module 2
Navigating the SMH
2–3. SLIDE: Launching the SMH GUI via Autostart
Launching the SMH GUI via Autostart
• SMH web access is provided via an Apache web server daemon

• By default, SMH is configured to run in “autostart” mode
• A lightweight smhstartd daemon starts at boot time
• Users connect to smhstartd via web address http://server:2301/
• smhstartd launches the Apache/SMH daemon when needed
• smhstartd redirects each request via HTTPS to the Apache/SMH daemon
• Apache/SMH terminates after 30 minutes of inactivity
Enable SMH autostart

# smhstartconfig –a on –b off Browser
Verify SMH autostart http://server:2301/

# smhstartconfig
HPSMH 'autostart url' mode.........: ON smhstartd
HPSMH 'start on boot' mode.........: OFF
Start Tomcat when HPSMH starts.....: OFF https://server:2381/
Access the SMH from any web browser Apache/SMH

# firefox http://servername.hp.com:2301/
Student Notes
HP-UX provides the SMH web interface via a dedicated Apache web server daemon. There
are two common techniques for launching this daemon. By default, SMH is configured to run
in “autostart” mode, as described below. The next slide describes “start on boot” mode.
• During the system boot process, the /sbin/init.d/hpsmh startup script launches a
lightweight smhstartd daemon during the boot process. smhstartd runs continuously
until system shutdown, listening for incoming connection requests from clients.
• Users connect to smhstartd via web address http://servername:2301/.
• When the server receives a connection request on http://servername:2301/,

smhstartd launches the Apache/SMH daemon via the following command.
/opt/hpws/apache/bin/httpd \
-k start \
-DSSL -f \
/opt/hpsmh/conf/smhpd.conf

Module 2
Navigating the SMH
• smhstartd then redirects the client’s request to the newly-launched, SSL-enabled

Apache daemon at https://servername:2381/,
• smhstartd also launches an /opt/hpsmh/lbin/timeoutmonitor script, which

automatically terminates the Apache/SMH daemon after 30 minutes of inactivity. The
timeout period is configurable via the TIMEOUT_SMH variable in
/opt/hpsmh/conf/timeout.conf.
Autostart is the default SMH configuration mode. If another administrator disabled autostart,
re-enable it via the smhstartconfig command. Then execute smhstartconfig again
without any options to verify your work.
# smhstartconfig –a on –b off
/etc/rc.config.d/hpsmh has been edited to enable
HPSMH to be autostarted using port 2301.
NOTE: HPSMH 'start on boot' mode is already disabled.
# smhstartconfig
HPSMH 'autostart url' mode.........: ON
Start Tomcat when HPSMH starts.....: OFF
If your organization’s security policy prohibits web servers on production servers, you can
disable the SMH web interface entirely with the following commands:
# smhstartconfig -a off -b off

/etc/rc.config.d/hpsmh has been edited to disable
the autostarting of HPSMH using port 2301.
# smhstartconfig
HPSMH 'autostart url' mode.........: OFF
Changes made via smhstartconfig simply modify variables in the

/etc/rc.config.d/hpsmh file, which is read by the /sbin/init.d/hpsmh startup
script during the boot process. This file can also be edited directly with the vi editor. After
making changes, be sure to re-run the startup script.
# vi /etc/rc.config.d/hpsmh
# /sbin/init.d/hpsmh start

Module 2
Navigating the SMH
2–4. SLIDE: Launching the SMH GUI via Start-on-Boot
Launching the SMH GUI via Start-on-Boot
• Alternatively, configure the Apache/SMH daemon to run perpetually

– Apache/SMH daemon starts at boot time and runs perpetually
– Users connect directly to the Apache/SMH daemon via HTTPS
• Advantage: SMH clients can connect directly via HTTPS, avoiding a redirect
• Disadvantage: Apache runs perpetually on the system
Enable SMH start-on-boot

# smhstartconfig –a off –b on Browser
Verify SMH autostart

https://server:2381/
# smhstartconfig
HPSMH 'start on boot' mode.........: ON Apache/SMH
Access the SMH from any web browser

# firefox https://server:2381/
Student Notes
The previous slide explained how to launch the Apache/SMH daemon on an as-needed basis
via SMH autostart. Administrators who wish to connect to the SMH directly via HTTPS may
prefer to start the Apache/SMH daemon during the boot process and allow it to run
perpetually.
Autostart is the default SMH configuration mode. Use the smhstartconfig command to
enable and verify SMH start-on-boot.
# smhstartconfig -a off -b on
/etc/rc.config.d/hpsmh has been edited to enable
the 'start on boot' startup mode of HPSMH server.
# smhstartconfig
HPSMH 'start on boot' mode.........: ON

Module 2
Navigating the SMH
If your organization’s security policy prohibits web servers on production servers, you can
disable the SMH web interface entirely with the following commands:
# smhstartconfig -a off -b off

# smhstartconfig
Changes made via smhstartconfig simply modify variables in the

/etc/rc.config.d/hpsmh file, which is read by the /sbin/init.d/hpsmh startup
script during the boot process. This file can also be edited directly with the vi editor. After
making changes, be sure to re-run the startup script.
# vi /etc/rc.config.d/hpsmh
# /sbin/init.d/hpsmh start

Module 2
Navigating the SMH
2–5. SLIDE: Verifying the SMH Certificate
Verifying the SMH Certificate

Browsers use security “certificates” to authenticate the identity of HTTPS servers
• By default, SMH uses “self-signed” security certificates
• Some administrators install certificates signed by a Certificate Authority (CA) instead
If using “self-signed” certificates, browsers may display a security warning
Mozilla security certificate warning: IE security certificate warning:
Student Notes
If the SMH start-on-boot functionality is enabled, users connect directly to the SMH via
https://server:2381/. If SMH autostart functionality is enabled, users initially connect
to http://server:2301/, then get redirected to https://server:2381/. In either
case, the user ultimately accesses the SMH server through an https Secure Socket Layer
(SSL) connection.
Accessing the server via SSL ensures that:

• All communications between the browser and SMH server are encrypted, and
• Users can verify the identity of the SMH server to which they are connected.
Any time a web browser accesses a website via the HTTPS protocol, the web server presents
a security “certificate”. The client browser compares the certificate provided by the web
server with information obtained from a trusted “certificate authority” (CA) such as
http://www.verisign.com.

Module 2
Navigating the SMH
By default, SMH uses “self-signed” certificates, which are signed by the SMH server itself
rather than a well-known CA. The browser can’t determine the authenticity of self-signed
certificates, so it displays a warning similar to the messages shown on the slide. If you see a
security certificate warning message, but your server and client reside on a secure, trusted
network, you may choose to ignore the message and proceed with the connection.
For better security, security-conscious administrators prefer to install a “signed” certificate

on the SMH server from a trusted CA. The process required to install a signed certificate on
an SMH server is described on the SMH Settings->Security->Local Server
Certificate screen in the SMH interface.

Module 2
Navigating the SMH
2–6. SLIDE: Logging into the SMH
Logging into the SMH

• After connecting to the SMH daemon, enter an authorized HP-UX username/password
• By default, only members of the HP-UX root group can log into the SMH
• Other HP-UX groups can optionally be granted access to the SMH, too
Student Notes
After connecting to the SMH daemon, enter an authorized HP-UX username/password. By
default, only members of the HPUX root group can log into the SMH. User root is typically
the only member of the root group. To determine which users belong to your system’s
root group, use nsquery.
# nsquery group root
No policy for group in nsswitch.conf.

Using "files nis" for the group policy.
Searching /etc/group for root

Group name: root
Group Id: 0
Group membership: root
Switch configuration: Terminates Search
A later slide in this chapter explains how to grant other user groups access to the SMH, too.

Module 2
Navigating the SMH
2–7. SLIDE: SMH Menus and Tabs
SMH Menus and Tabs

SMH utilizes a tabbed interface
• Use the “Home” tab, the default tab, to view hardware/status information
• Use the “Settings” tab to customize SMH security and add custom menu items
• Use the “Tasks” tab to execute arbitrary commands on the server
• Use the “Tools” tab to view and configure OS features
• Use the “Logs” tab to launch SMH’s web-based log file viewers
• Use the “Support” and “Help” tabs to get help
Menu Tabs Return to Main Menu Logout Disable Timeout
Which SMH General Host MP Icon Refresh Toggle

screen am I viewing? Information Link Legend Data Menu
Format
Student Notes
The SMH utilizes a tabbed interface.
• Use the “Home” tab, the default tab, to view summary system status information.
• Use the “Settings” tab to customize SMH security and add custom menu items.
• Use the “Tasks” tab to execute arbitrary commands on the server.
• Use the “Tools” tab to view and configure OS features.
• Use the “Logs” tab to launch SMH’s web-based log file viewers.
• Use the “Support” tab to access HP’s online IT Resource Center and user forums.
• Use the “Help” tab to learn more about the SMH.

The next few slides describe each tab in detail.

Module 2
Navigating the SMH
The SMH banner graphic includes links to a number of other resources in the SMH, too.
• On the far left, the SMH reports which SMH screen you are currently viewing.
• The next block reports your system hostname and model string.
• The next block provides a link to the Management Processor, which provides a console
login interface that is required for some system administration tasks.
• Two icons on the far right enable you to select the SMH list or icon menu format.
• Two links above the menu format buttons take you back to the SMH “Home” screen, or
log you out.
• The “Legend” link displays a legend that explains the meaning of the SMH icons.
• The “Refresh” link refreshes the current SMH screen when system conditions change.
• By default, SMH sessions terminate after several minutes of inactivity. Click the
checkbox at top right to disable the auto-logout feature.

Module 2
Navigating the SMH
2–8. SLIDE: SMH->Home (1 of 2)
SMH->Home (1 of 2)
• The SMH “Home” tab summarizes the status of the system’s subsystems
• Click any subsystem for more detailed information
• Contents of the “Home” tab vary from model to model
• Click the “Legend” link to view an icon legend
Student Notes
The SMH “Home” tab summarizes the status of the cooling, power, memory, and other
hardware subsystems. The subsystems listed may vary somewhat from system model to
system model. To learn more about a subsystem, click the subsystem name.
To the left of each subsystem name, the SMH displays a color-coded icon that represents the
subsystem’s health status. Click the “Legend” link in the SMH header, or see the legend
included on the slide, to determine what each icon represents.
The oversize status icon at the top left of the SMH “Home” page summarizes the overall
system status. In the sample system shown on the slide, one of the network interface cards is
disconnected, which results in a minor warning for the network subsystem, and for the
system as a whole.
Though not shown in the screenshot on the slide, the “Home” tab also includes a “System
Configuration” box containing links to some of the commonly used SMH system
administration tools. A slide later in this chapter discusses tools in detail.

Module 2
Navigating the SMH
WBEM
The SMH collects status information about the operating system and the system hardware via
Web Based Enterprise Management (WBEM) protocols and standards. WBEM is an industry
standard developed and used by multiple vendors. Most HP operating systems, platforms
and devices include WBEM “providers” that provide information to SMH and other HP
management tools.
To learn more about HP’s WBEM providers and solutions, visit

http://www.hp.com/go/wbem. To learn more about WBEM standards and protocols,
visit http://www.dmtf.org/standards/wbem/.
Use the swlist command to see which WBEM providers are installed on your HP-UX 11i v1,
v2, or v3 system.
# swlist -l product | grep -i wbem

LVM-Provider R11.23.007 LVM WBEM Provider
SCSI-Provider B.11.23.050 CIM/WBEM Provider for SCSI HBA
SGWBEMProviders A.01.00.00 HP Serviceguard WBEM Providers
WBEMP-LAN B.11.23.03 LAN Provider: CIM/WBEM Provider
WBEMServices A.02.00.11 WBEM Services CORE Product
vmProvider A.01.20.69 WBEM Provider for Integrity VM
HP adds new and updated WBEM providers in each media kit release. The latest WBEM
providers are also available on http://software.hp.com.

Module 2
Navigating the SMH
2–9. SLIDE: SMH->Home (2 of 2)
SMH->Home (2 of 2)
From the “Home” tab …
• Click a hardware subsystem (e.g.: “Physical Memory”) for more details
• Output varies from model to model
NOTE: screenshot has been formatted and truncated to fit the slide
Student Notes
From the SMH “Home” tab, you can click any subsystem link to view more detailed
information about that subsystem. The screenshot on the slide shows the physical memory
subsystem detail, including the status, location, capacity, type, and serial number of each
DIMM (Dual Inline Memory Module).

Module 2
Navigating the SMH
2–10. SLIDE: SMH->Tools (1 of 4)
SMH->Tools (1 of 4)
The “Tools” tab provides GUI interfaces for many common admin tasks
• Some tools launch GUI interfaces, some launch web interfaces, others run CLIs
• Supported tools vary from release to release
Student Notes
The SMH “Tools” tab provides GUI interfaces for many common system administration tasks.
The slide shows some of the tools included by default in the SMH.
Some tools launch GUI interfaces, some launch web interfaces, others run command line
utilities. In the current release, some SMH tools launch legacy SAM interfaces, too.
Supported tools vary from OS release to OS release.

Module 2
Navigating the SMH
SMH->Tools (2 of 4)
To run a tool...
• Click a tool (e.g.: “File Systems”) on the “Tools” tab
• Select an object (e.g.: “/home”) from the resulting object list
• Select an action (e.g.: “Unmount”) from the resulting action list
• Provide the information requested in the dialog box that follows
Student Notes
In order to launch a tool, simply click the tool’s link on the SMH “Tools” tab.
The interface that follows varies from tool to tool. Most of the recently developed tools use a
web interface similar to the “File System” tool shown on the slide.
• Click a tool (e.g.: “File Systems”) on the “Tools” tab.
• Select an object (e.g.: “/home”) from the resulting object list.
• Select an action (e.g.: “Unmount”) from the resulting action list on the right side of the
screen.
• Provide the information requested in the dialog box that follows.

Module 2
Navigating the SMH
SMH->Tools (3 of 4)
• Dialog boxes vary
from tool to tool
• Most include an
explanation of the tool
and it’s limitations and
side-effects
• Most include a
preview button that
displays the HP-UX
command(s) executed
by the tool
Student Notes
Tool dialog boxes vary from tool to tool.
Most include an explanation of the tool’s purpose, its limitations, and any potential side-
effects.
Most include a “Preview” button that displays the HP-UX command(s) that will be executed
by the tool.

Module 2
Navigating the SMH
SMH->Tools (4 of 4)
Some SMH tools are simply wrappers for external non-web-based applications
• Select your preferred language
• Enter your desktop system’s $DISPLAY variable value
• Look at the command preview to determine which command the tool executes
• Click “Run”
NOTE: screenshot has

been formatted and
truncated to fit the slide
Student Notes
Some SMH tools simply launch legacy SAM interfaces, or other GUI and CLI applications.
Launching these types of tools displays a window similar to the dialog box shown on the
slide. To use these tools:
• Select your preferred language from the pull-down menu. English users should select
“C”.
• If the tool is GUI-based, enter your desktop system’s $DISPLAY name. Execute echo
$DISPLAY in a shell window to determine the appropriate display name.
• Look at the command preview at the bottom of the screen to determine which
command the tool executes.
• Click “Run”.

Module 2
Navigating the SMH
What happens next varies from tool to tool. CLI-based tools simply execute the command
and display the resulting STDOUT/STDERR output. Web-based tools run in a new browser
window. X-based applications, such as the swinstall tool shown on the slide, launch an X-
based interface similar to the swinstall interface below.

Module 2
Navigating the SMH
2–14. SLIDE: SMH->Settings
SMH->Settings
The “Settings” tab allows you to add and remove your own custom tools, too
• Access the “Settings” tab
• Click “Add Custom Menu”
• Use the resulting dialog box to create the custom tool
• Custom tools may be added to existing SMH tool categories, or new custom categories
• Custom tools may launch X applications, CLI commands, or web applications
• Custom tools may be configured to run as root when launched by non-root users
• Custom tools may be executed just like built-in SMH tools
Student Notes
The SMH has quite a few built-in tools. For even more flexibility, SMH allows the
administrator to add custom tools, too.
• Access the “Settings” tab.
• Click “Add Custom Menu”.
• Use the resulting dialog box to create the custom tool.
• Custom tools may be added to existing tool categories, or new custom categories.
• Custom tools may launch X applications, non-interactive CLI commands, or web-based

applications.
• Custom tools may be configured to run as root when launched by non-root users.
• To execute a custom tool, just click the tool’s link as you would any other SMH tool. CLI-
based tools execute the command non-interactively and display the resulting

Module 2
Navigating the SMH
STDOUT/STDERR output. Web-based tools run in a new browser window. GUI-based

tools open a new X-window.

Module 2
Navigating the SMH
2–15. SLIDE: SMH->Tasks
SMH->Tasks
Use the “Tasks” tab to execute a single command through the SMH
• Access the “Tasks” tab
• Click “Launch” or “Run”, and follow the prompts to run the program
• SMH reports the command’s STDERR and STDOUT output
Student Notes
The SMH “Settings” tab allows administrators to create permanent custom tools to execute
frequently-used commands. The SMH “Task” tab allows administrators to execute one-time
commands remotely, without permanently adding a tool to the SMH menus.
• Access the “Tasks” tab.
• Click “Launch” or “Run” and follow the prompts to run the program. Select your
preferred language from the pull-down menu. English users should select “C”. If the tool
is GUI-based, enter your desktop system’s $DISPLAY name. Execute echo $DISPLAY
in a shell window to determine the appropriate display name.
• SMH reports the command’s STDERR and STDOUT output.

Module 2
Navigating the SMH
2–16. SLIDE: SMH->Logs
SMH->Logs
SMH provides web-based log file viewers for viewing some common system log files
• Access the “Logs” tab
• Select a log file viewer (e.g.: “System Log Viewer”)
• Use the “Select” tab to select a log file (e.g.: “syslog.log” vs. “OLDsyslog.log”)
• Use the “Layout” and ”Filters” tabs to customize the column layout
• Use the “Display” tab to view the log contents
• Log file viewer features for other log files may vary
Student Notes
SMH provides web-based log file viewers for viewing and filtering several common system
log files.
• Access the “Logs” tab.
• Select a log file viewer (e.g.: “System Log Viewer”). Different log viewers may have
slightly different interfaces. The steps below apply to the “System Log Viewer”, which
displays the contents of the /var/adm/syslog/syslog.log log file. The
syslog.log file captures error, warning, and status messages from a variety of
subsystems and services.
− Use the “Select” tab to select a log file (e.g.: “syslog.log” vs. “OLDsyslog.log”).
− Use the “Layout” and tab to customize the column layout, and use the “Filters” tab to
filter the log file contents by date and time.

Module 2
Navigating the SMH
− Use the “Display” tab to view the log file contents. Use the scroll bar to move
forwards and backwards through the file. Use the “Search” text box to search the file
for specific patterns.
− Log file viewer features for other log files may vary.
If you want to add log file viewers for other log files into the SMH, use the “Add Custom
Menu” feature described previously, put the tool on the “Logs” page, and enter
“/usr/bin/cat /my/log/file/name” in the “Command/URL” field.

Module 2
Navigating the SMH
2–17. SLIDE: SMH Group Access Control
SMH Group Access Control

• Users must enter a valid HP-UX username/password in order to access the SMH
• SMH determines a user’s access rights (if any) via the user’s HP-UX group memberships
• By default, only members of the root group can access the SMH
• Use Settings->Security->User Groups to grant SMH access to other HP-UX groups
Student Notes
Users must enter a valid HP-UX username/password in order to access the SMH. SMH
determines a user’s access rights (if any) via the user’s HP-UX group memberships. By
default, only members of the root group can access the SMH. If other users such as
operators, backup administrators, or database administrators need access to the SMH, use
the “Settings->Security->User Groups” menu to grant SMH access to other HP-UX groups.
The “User Groups” menu offers three different access levels.
Members of groups that have SMH “Administrator” privileges can use all of the SMH tools
and features, add custom tools, and grant SMH access rights to other user groups. By default,
the SMH grants members of the root group SMH “Administrator” privileges.
Members of groups that have SMH “Operator” privileges can access most SMH tools and
features, but cannot add or remove custom tools, execute arbitrary tasks as root, or modify
the SMH user, group, security, and authentication settings.
Members of groups that have SMH “User” privileges can use tools that display information
but cannot use SMH tools to modify either the system or SMH configuration.

Module 2
Navigating the SMH
Access Control in the SMH TUI

The SMH TUI interface manages access control via a different mechanism. By default, only
the administrator can launch the SMH TUI. To provide TUI access to non-root users, launch
the TUI-based smh –r restricted SMH user configuration tool and select a user.
# smh -r
The privileges set for the user from the Text User Interface doesn't
apply to Graphical User Interface. System Management Homepage(SMH)
in Graphical User Interface has a different way of setting the
privileges. Please look at smh(1M) man page for more information
Do you want to continue (y/n) <y>: y
SMH->Restricted SMH->Select users

--------------------------------------------------------------------
Login Primary Has SAM
users Group privileges
====================================================================
user1 users Yes
user2 users No
user3 users No
user4 users No
user6 users No
user7 users No
user8 users No
user9 users No
user10 users No
--------------------------------------------------------------------
x-Exit smh ENTER-Select /-Search
r-Remove Privileges g-Display Groups

Module 2
Navigating the SMH
Next, specify which SMH functional areas the user should be allowed to access. Be sure to
press s to save the selected privileges before exiting.
SMH->Restricted SMH->Functional Areas

Selected user : user1
--------------------------------------------------------------------
Functional Areas Access Status
====================================================================
Resource Management Disabled
Disks and File Systems Enabled
Display Disabled
Kernel Configuration Disabled
Printers and Plotters Disabled
Networking and Communications Disabled
Peripheral Devices Disabled
Security Attributes Configuration Disabled
Software Management Disabled
Auditing and Security Disabled
Accounts for Users and Groups Disabled
--------------------------------------------------------------------
x-Exit smh Esc-Back s-Save Privileges D-Disable All
e-enable d-disable E-Enable All
The user should then be able to run /usr/sbin/smh and access the selected SMH
functional areas.

Module 2
Navigating the SMH
2–18. SLIDE: SMH Authentication
SMH Authentication
Security conscious system administrators can enable
additional SMH authentication features via other links on
the Settings->Security menu
• Anonymous/Local Access:
Allow local and/or remote users to access the SMH without providing a
username/password
• IP Binding:
Only allow users to access SMH from selected networks
• IP Restricted login:
Only allow users to access SMH from selected IP addresses
• Local Server Certificate:
Import a security certificate for the SMH server from a third party
• Timeouts:
Specify SMH session timeout values
• Trust Mode:
Determine how SMH authenticates configuration requests from remote
SIM servers
• Trusted Management Servers:
Import security certificates for SIM servers, if using SIM to remotely
manage SMH nodes
Student Notes
Security conscious system administrators can enable additional SMH authentication features
via other links on the “Settings->Security” menu.
Local/Anonymous Access
Anonymous Access enables a user to access the System Management Homepage without
logging in. This feature is disabled by default. HP does not recommend enabling anonymous
access.
Local Access enables local users to access the System Management Homepage without being
challenged for authentication.
If Local Access/Anonymous is selected, any local user has access limited to unsecured pages
without being challenged for a username and password.
If Local Access/Administrator is selected, any user with access to the local console is granted
full access to all SMH features.

Module 2
Navigating the SMH
IP Binding
IP Binding specifies which IP networks and subnets the System Management Homepage
accepts requests from. A maximum of five subnet IP addresses and netmasks can be defined.
The System Management Homepage allows access from 127.0.0.1. If IP Binding is enabled
and no subnet/mask pairs are configured, then the System Management Homepage is only
available to 127.0.0.1. If IP Binding is not enabled, users can access the SMH from any
network or subnet.
IP Restricted login
IP Restricted Login allows the administrator to specify a semi-colon separated list of IP
address ranges that should be explicitly allowed or denied SMH access.
If an IP address is excluded, it is excluded even if it is also listed in the included box. If there
are IP addresses in the inclusion list, then only those IP addresses are allowed log-in access
with the exception of localhost. If no IP addresses are in the inclusion list, then log-in access
is allowed to any IP addresses not in the exclusion list.
Local Server Certificate

When a user connects to the server’s SMH, the client browser uses public/private key
authentication to verify that the browser connected to the legitimate server. SMH uses “self-
signed” certificates by default. For greater security, SMH administrators can obtain
authentication keys for the SMH server from a third party Certificate Authority. The SMH
help screens explain this process in detail.
Timeouts
Use this feature to change SMH session and interface timeout values.
Trust Mode
HP Systems Insight Manager (SIM) is an HP product that allows administrators to monitor
and manage multiple servers and devices from a central management station. The next slide
provides a brief overview of SIM functionality. SIM utilizes SMH for some management
tasks. The SMH “Trust Mode” screen determines how SMH authenticates requests received
from remote servers.
Trusted Management Servers

If the SMH “Trust Mode” described above requires public/private key authentication of SIM
servers, use the “Trusted Management Servers” link in SMH to import certificates from the
SIM server.
User Groups
See the previous slide for a discussion of SMH User Groups.

Module 2
Navigating the SMH
2–19. SLIDE: SMH and SIM Integration Possibilities
SMH and SIM Integration Possibilities

HP SMH provides an intuitive web interface for managing a single system
HP SIM provides an intuitive web interface for managing multiple systems
• SIM manages all HP-supported operating systems, and most HP-supported devices
• SIM can automatically, seamlessly launch any server’s SMH page
• SIM consolidates status, log, and other information from multiple nodes
• SIM provides robust role based security and key-based authentication
• SIM is included with HP-UX; other licensed plug-ins provide even greater functionality
Student Notes
HP SMH provides an intuitive web interface for managing a single HP system. HP Systems
Insight Manager provides an intuitive web interface for managing multiple HP servers and
devices from a consolidated central management interface.
SIM manages all HP-supported operating systems, and most HP-supported devices, including
storage devices, blade servers, Proliant Windows/Linux servers, blade enclosures and
servers, and much more.
SIM integrates with the SMH, and can seamlessly launch any HP Windows/Linux/HP-UX
server’s SMH.
SIM consolidates status, log, and other information from multiple nodes. In large
environments, this consolidated monitoring greatly simplifies monitoring and
troubleshooting tasks.
SIM provides robust role-based security, using single-sign-on key-based authentication, so

authorized administrators can seamlessly access multiple servers in a secure fashion without
entering multiple usernames and passwords.

Module 2
Navigating the SMH
Basic SIM functionality is included with HP-UX. Some customers purchase additional SIM
plug-ins for even greater flexibility.
For more information about SIM, attend HP Education’s HB508S “HP-UX Systems Insight
Manager” class, or visit the SIM product page at http://www.hp.com/go/hpsim.

Module 2
Navigating the SMH
2–20. SLIDE: For Further Study
For Further Study

Course from HP Customer Education:
HB508S HP Systems Insight Manager (SIM) for HP-UX
Manuals on http://docs.hp.com:
HP System Management Homepage User Guide
HP System Management Homepage Installation Guide
HP System Management Homepage Release Notes
Student Notes

Module 2
Navigating the SMH
2–21. LAB: Configuring and Using the System Management

Homepage
Directions
Carefully follow the instructions below and record your answers in the spaces provided.
Part 1: Configuring SMH autostart functionality
1. Verify that the SysMgmtWeb product is installed on your system.
# swlist SysMgmtWeb
# swconfig –x reconfigure=true SysMgmtHomepage.*
2. Use smhstartconfig to determine which SMH startup mode is enabled by default.

Module 2
Navigating the SMH
Part 2: Accessing the SMH (Internet Explorer)

Depending on your lab equipment setup, your instructor will tell you to do either lab Part 2 or
Part 3.
1. Launch the Internet Explorer web browser and point it to the SMH autostart URL,
http://server_ip:2301/. Replace server_ip with your server's IP address.
a. If you are accessing your lab system remotely via a Virtual Lab portal server, launch
the portal’s Internet Explorer via the browser link on the VL webtop. In some VL
environments, there may be an SMH link on the webtop that opens a browser directly
to the SMH.
b. If you are accessing your lab system from a PC that has full network connectivity to
your lab system, launch Internet Explorer on your PC.
2. If asked if you wish to be redirected to “view pages over a secure connection”, click
[OK].
You should see a “Security Alert” indicating that the security certificate provided by the
SMH server was “issued by a company you have not chosen to trust”.
By default, the SMH uses “self-signed” authentication certificates, issued by the SMH
server itself. It’s possible to obtain a security certificate for the SMH server from a third
party “Certificate Authority”; for the sake of the lab, we’ll use the self-signed certificate.
When asked if you want to proceed, click [Yes].
3. Login as user root on the SMH login page. If your browser’s status bar is enabled, note
the padlock icon in the bottom right corner of the browser window indicating that the
connection to the server is secure.

Module 2
Navigating the SMH
Part 3: Accessing the SMH (Firefox; Mozilla is still available)

Part 3.
1. Launch a Firefox web browser.
2. Point your web browser to the SMH autostart URL, http://server:2301/.

Replace server with your fully-qualified server hostname.
3. A window titled “Website Certified by an Unknown Authority” window may appear.
a. Click the “Accept this certificate permanently” radio button to permanently accept
the self-signed certificate from the SMH server.
b. Click [OK] to proceed past the “Website Certified by an Unknown Authority”

window.
c. A “Security Warning” message should appear indicating that you “have requested an
encrypted page”. Click [OK] to proceed to the SMH login screen.
4. Login as user root on the SMH login page. Note the padlock icon in the bottom right
corner of the browser window, indicating that you are connected to the server via a
secure connection.

Module 2
Navigating the SMH
Part 4: Navigating the SMH web interface

Use the SMH to complete the tasks below. If you wish, explore other SMH pages of interest,
too.
1. Use the SMH “Home” tab links to view detailed status reports on some of your lab
system’s hardware components.
2. Use the SMH “Home” tab links to view detailed reports of your lab system’s process
information, networking information, and memory utilization.
3. Navigate to the SMH “Tools” tab and use the Defragment Extents link to
“defragment” the /home file system.
4. Navigate to the SMH “Tasks” tab and use the Run Command as Root link to execute
/usr/bin/passwd –f user1, which forces user1 to change his/her password at
next login.
5. Navigate to the SMH “Logs” tab and use the System Log Viewer link to view all lines
in /var/adm/syslog/syslog.log that contain the string inetd.

Module 2
Navigating the SMH
Part 5: Creating custom SMH tools (Optional)

SMH includes quite a few built-in features. For even greater flexibility, though, SMH also
allows the system administrators to create custom SMH tools on any SMH screen.
1. Access the SMH “Settings” screen.
2. Click Add Custom Menu.
3. From the Type pulldown menu, select Command Line.
4. From the Page pulldown menu, select Tools.
5. In the Category field, enter Disks and File Systems.
6. In the Tool Name field, enter Purge /tmp.
7. In the Command/URL field enter the following command, which purges all files from
/tmp which haven’t been accessed in at least seven days:
/usr/bin/find /tmp –type f –atime +7 –exec rm +
8. Click [Add].
9. Access the SMH “Tools” tab.
10. In the Disk & File Systems category, click the new Purge /tmp tool.
11. Click [Run] to run the tool.

Module 2
Navigating the SMH
Part 6: Cleanup
Close your SMH browser window before proceeding to the next chapter.

Module 2
Navigating the SMH
2–22. LAB SOLUTIONS: Configuring and Using the System

Management Homepage
Directions
Carefully follow the instructions below and record your answers in the spaces provided.
Part 1: Configuring SMH autostart functionality
1. Verify that the SMH product is installed and configured on your system.
# swlist SysMgmtWeb
# swconfig –x reconfigure=true SysMgmtHomepage.*
2. Use smhstartconfig to determine which SMH startup mode is enabled by default.
Answer:
# smhstartconfig
HPSMH 'autostart url' mode.........: ON
Autostart mode is the default SMH startup mode.

Module 2
Navigating the SMH
Part 2: Accessing the SMH (Internet Explorer)

Part 3.
1. Note that when performing these labs in the HP Virtual Lab, there is an SMH button in the
HPVL Reservation Window that will open an SMH browser window.
The other method is to launch the Internet Explorer web browser and point it to the SMH
autostart URL, http://server_ip:2301/. Replace server_ip with your server's IP
address.
a. If you are accessing your lab system remotely via a Virtual Lab portal server, launch
the portal’s Internet Explorer via the browser link on the VL webtop. In some VL
environments, there may be an SMH link on the webtop that opens a browser directly
to the SMH.
b. If you are accessing your lab system from a PC that has full network connectivity to
your lab system, launch Internet Explorer on your PC.
2. If asked if you wish to be redirected to “view pages over a secure connection”, click
[OK].
a. You should see a “Security Alert” indicating that the security certificate provided by
the SMH server was “issued by a company you have not chosen to trust”.
server itself. It’s possible to obtain a security certificate for the SMH server from a
third party “Certificate Authority”; for the sake of the lab, we’ll accept the self-signed
certificate.
When asked if you want to proceed, click [Yes].
3. Login as user root on the SMH login page. If your browser’s status bar is enabled, note
the padlock icon in the bottom right corner of the browser window indicating that the
connection to the server is secure.

Module 2
Navigating the SMH
Part 3: Accessing the SMH (Firefox; Mozilla is still available)

Part 3.
1. Launch Firefox web browser.
2. When performing these labs in the HP Virtual Lab, there is an SMH button in the HPVL
Reservation Window that will open an SMH browser window.
The other method is to point your web browser to the SMH autostart URL,
http://server:2301/. Replace server with your fully-qualified server hostname.
3. A window titled “Website Certified by an Unknown Authority” window may appear.
a. Click the “Accept this certificate permanently” radio button to permanently accept
the self-signed certificate from the SMH server.
b. Click [OK] to proceed past the “Website Certified by an Unknown Authority”

window.
c. A “Security Warning” message should appear indicating that you “have requested an
encrypted page”. Click [OK] to proceed to the SMH login screen.
4. Login as user root on the SMH login page. Note the padlock icon in the bottom right
corner of the browser window, indicating that you are connected to the server via a
secure connection.

Module 2
Navigating the SMH
Part 4: Navigating the SMH web interface

Use the SMH to complete the tasks below. If you wish, explore other SMH pages of interest,
too.
1. Use the SMH “Home” tab links to view detailed status reports on some of your lab
system’s hardware components.
2. Use the SMH “Home” tab links to view detailed reports of your lab system’s process
information, networking information, and memory utilization.
3. Navigate to the SMH “Tools” tab and use the Defragment Extents link to
“defragment” the /home file system.
Answer:
a. Navigate to the SMH “Tools” tab.
b. Click the File Systems link.
c. Select the radio button for the /home file system.
d. Click the Defragment Extents link. You may have to scroll to the bottom right
corner of the SMH screen to see this link.
e. Review the comments and command preview.
f. Click [Defragment] to proceed with the defragmentation.
g. There shouldn’t be any output or errors.
h. Click [Back] to return to the file system list.
4. Navigate to the SMH “Tasks” tab and use the Run Command as Root link to execute
/usr/bin/passwd –f user1, which forces user1 to change his/her password at
next login.
Answer:
a. Navigate to the SMH “Tasks” tab and click the Run Command as Root link.
b. Enter C in the Language field.
c. Enter /usr/bin/passwd –f user1 in the Command field.
d. Click [Run].
e. Click [Back] when the command completes.

Module 2
Navigating the SMH
5. Navigate to the SMH “Logs” tab and use the System Log Viewer link to view all lines
in /var/adm/syslog/syslog.log that contain the string inetd.
Answer:
a. Navigate to the SMH “Logs” tab and click the System and Consolidated Log
Viewer link.
b. On the Select tab, select the /var/adm/syslog/syslog.log file.
c. On the Filters tab, enter inetd in the Search field.
d. Click the Display tab to view the results.

Module 2
Navigating the SMH
Part 5: Creating custom SMH tools (Optional)

SMH includes quite a few built-in features. For even greater flexibility, though, SMH also
allows the system administrators to create custom SMH tools on any SMH screen.
1. Access the SMH “Settings” screen.
2. Click Add Custom Menu.
3. From the Type pulldown menu, select Command Line.
4. From the Page pulldown menu, select Tools.
5. In the Category field, enter Disks and File Systems.
6. In the Tool Name field, enter Purge /tmp.
7. In the Command/URL field enter the following command, which purges all files from
/tmp which haven’t been accessed in at least seven days:
/usr/bin/find /tmp –type f –atime +7 –exec rm +
8. Click [Add].
9. Access the SMH “Tools” tab.
10. Click the new Purge /tmp tool.
11. Click [Run] to run the tool.

Module 2
Navigating the SMH
Part 6: Cleanup
Close your SMH browser window before proceeding to the next chapter.

Module 2
Navigating the SMH

Module 3 ⎯ Managing Users and Groups
Objectives
• List the minimum requirements for a user account.
• Identify each field in the /etc/passwd file.
• Identify each field in the /etc/shadow file.
• Identify each field in the /etc/group file.
• Create, modify, and remove user accounts.
• Create, modify, and remove user groups.
• Deactivate and reactivate a user account.
• Configure shadow passwords.
• Configure password aging.
• Customize default user account security attributes in /etc/default/security.
• Customize default user shell startup scripts in /etc/skel/.

Module 3
Managing Users and Groups
3–1. SLIDE: User and Group Concepts
User and Group Concepts
Su J im k
e Fran Users
Sales
Jean Sue Ann

M
ar Bo nk
ie b Fra
Develop
Student Notes
In order to gain access to an HP-UX system and its resources, users are required to log in. By
controlling access to your system, you can prevent unauthorized users from running
programs that consume resources, and control access to the data stored on your system.
Every user on an HP-UX system is assigned a unique username, password, and User
Identification (UID) number. HP-UX uses the user’s UID number to determine which files
and processes are associated with each user on the system.
Every user is also assigned a primary group membership and, optionally, up to 20 additional
group memberships. HP-UX grants access to files and directories based on a user’s UID and
the groups to which the user belongs.
Use the id command to determine a user’s UID and primary group membership.
# id user1
uid=301(user1) gid=301(class)

Module 3
Use the groups command to determine a user’s secondary group memberships.
# groups user1
class class2 users
This chapter describes the configuration files that define user accounts and groups, and the
commands required to manage those files.

Module 3
3–2. SLIDE: What Defines a User Account?
What Defines a User Account?

/etc/passwd
user1:x:1001:20:111-1111:/home/user1:/usr/bin/sh
/etc/shadow (optional; strongly recommended to enable)

user1:btp2SLRCK70es:1001::::::
/etc/group
users::20:
accts::1001:user1,user2
sales::1002:user1,user2,user3,user4,user5,user6
/home
user1 user2 user3
Student Notes
User accounts are defined in the /etc/passwd file. Each line in the /etc/passwd file
identifies a user’s username, password, User ID, primary group, home directory, and other
critical user-specific information.
Some users may belong to multiple user groups. The /etc/passwd file defines each user’s
primary group membership. The /etc/group file defines additional group memberships.
Finally, most users have a home directory under /home, beneath which they can store their
personal files and directories.

Module 3
3–3. SLIDE: The /etc/passwd File
The /etc/passwd File
/etc/passwd contains a one-line definition of each valid user account
/etc/passwd (r--r--r--)
root:qmAj8as.,8a3e:0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
user1:AdOK60AazRgXU:1001:1001:111-1111:/home/user1:/usr/bin/sh
Username Password UID GID Comments Home Directory Shell
Use /usr/sbin/vipw to edit /etc/passwd
Use /usr/sbin/pwck to check the /etc/passwd file syntax
Student Notes
The /etc/passwd file contains a one-line entry for each authorized user account. All fields
are delimited by colons (:).
Username The username that is used when a user logs in. The first character in each
username should be alphabetic, but remaining characters may be
alphabetic or numeric. Usernames are case sensitive.
In 11i v1 and v2, the username must be 1-8 characters in length. If a name
contains more than eight characters, only the first eight are significant.
11i v3 supports usernames up to 255 characters in length. However, this

functionality must be manually enabled by temporarily stopping the pwgrd
password hashing daemon, executing the lugadmin (long username
groupname) command, and restarting pwgrd. This process shouldn’t
impact existing users or running processes. Once enabled, long usernames
cannot be disabled.

Module 3
# /sbin/init.d/pwgr stop
pwgrd stopped
# lugadmin –e
Warning: Long user/group name once enabled cannot
be disabled in future.
Do you want to continue [yY]: y
lugadmin: Note: System is enabled for

long user/group name
# /sbin/init.d/pwgr start
pwgrd started
To determine if long usernames are enabled, execute lugadmin –l. 64

indicates that the maximum username length is 8 characters. 256 indicates
that long usernames are enabled.
# lugadmin –l
256
Commands such as who, ll, and ps that display usernames may truncate
usernames greater than 8 characters. The user represented in the who
output below has username ThisIsALongName.
$ who
ThisIsA+ console Jun 13 13:27
Long usernames may cause problems for scripts and applications that
attempt to parse the output from these commands or the contents of the
/etc/passwd file.
Password The encrypted password. You can encrypt a new password for a user via
the passwd command. /etc/passwd supports user passwords up to
eight characters.
If the password field is empty, the user can login without entering a
password.
An asterisk (*) in the password field deactivates an account. Nothing you

can type will encrypt to an asterisk, so, no one can log in using the
associated login name.
User ID Each user must be assigned a user ID. User ID 0 is reserved for root, and
UIDs 1-99 are reserved for other predefined accounts required by the
system. SAM, SMH, and ugweb automatically assign UID numbers when
creating new groups.
Version 10.20 of HP-UX introduced support for User IDs as large as

2,147,483,646. Prior to HP-UX 10.20, UIDs greater than 60,000 were not
supported. To determine your system’s maximum UID, check the MAXUID

Module 3
parameter in /usr/include/sys/param.h.
Using large UIDs may cause problems when sharing files with other
systems that do not support large UIDs.
Group ID The user’s primary group ID (GID). This number corresponds with an
entry in the /etc/group file. See the /etc/group discussion later in the
chapter for more information.
Comments The comment field. It allows you to add extra information about the users,
such as the user's full name, telephone extension, organization, or building
number.
Home directory The absolute path to the directory the user will be in when they log in. If
this directory does not exist or is invalid, then the user’s home directory
becomes /.
Command The absolute path of a command to be executed when the user logs in.
Typically, this is a shell. The shells that are usually used are
/usr/bin/sh, /usr/bin/ksh, and /usr/bin/csh. Administrators
must use the/sbin/sh POSIX shell. Most non-root users should use the
/usr/bin/sh POSIX shell. If the field is empty, the default is
/usr/bin/sh.
The command entry does not have to be a shell. For example, you can
create the following entry in /etc/passwd:
date:rc70x.4.hGJdc:20:1::/:/usr/bin/date
The command is /usr/bin/date. If you type date at the login prompt,

then type the appropriate password, the system will run the
/usr/bin/date command, and then log you out.
NOTE: The permissions on the passwd file should be read only (r--r--r--) and
the owner must be root.
Required Entries in /etc/passwd

Several entries are required in /etc/passwd to support various system daemons and
processes. The list below lists the most critical required user accounts; other may be
required, too, to support your system’s applications.
root:rZ1lps2JYh3iA:0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico

Module 3
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:60001::/:
Editing /etc/passwd
If you are using vi to edit /etc/passwd and a user attempts to change a password while
you are editing, the user's change will not be entered into the file. To prevent this situation,
use vipw when editing /etc/passwd.
# vipw
This command puts a lock on the /etc/passwd file by copying /etc/passwd to

/etc/ptmp. If a user attempts to change a password, he or she will be told that the passwd
file is busy. When you leave vipw, some automatic checks are done, and if your changes are
correct, the temporary file is moved to /etc/passwd. Otherwise, /etc/passwd will
remain unchanged.
Checking the /etc/passwd File

The consistency of the /etc/passwd file can be checked with the /usr/sbin/pwck
command. It will check for the number of fields in each entry, and whether login directory
and optional program name exist, and validate the number of fields, login name, user ID and
group ID.
# pwck
[/etc/passwd] user1:fnnmD.DGyptLU:301:301:student:/home/user1
Too many/few fields

Module 3
3–4. SLIDE: The /etc/shadow File
The /etc/shadow File
y Passwords can optionally be stored in /etc/shadow

y/etc/shadow is more secure than /etc/passwd
/etc/shadow (r--------)
user1:AdOK60AazRgXU:12269:70:140:70:35::
User Encrypted Min Warn

Unused
Name Password Days Days
Last Max Inactive

Changed Days Days
Install the ShadowPassword product (only necessary in 11i v1)

Use /usr/sbin/pwck to verify your current /etc/passwd file syntax
Use /usr/sbin/pwconv to move passwords from /etc/passwd to /etc/shadow
Use /usr/sbin/pwunconv to move passwords back to /etc/passwd
Student Notes
The default permissions on the /etc/passwd file are r--r--r--. Since the file is world-
readable, anyone with a valid login can view the file and view encrypted passwords. Hackers
sometimes exploit this fact to extract a list of encrypted passwords and run a password
cracking utility to gain access to other users’ accounts.
Unfortunately, removing world-read permission on the /etc/passwd file isn’t a viable

solution to this problem. Many commands, from login, to ps, to ll use the /etc/passwd
file to convert UIDs to usernames, and vice versa. Changing the /etc/passwd file
permissions to 400 would cause these commands to fail.
HP’s shadow password functionality addresses this problem by moving encrypted passwords
and other password information to the /etc/shadow file, which has 400 permissions to
ensure that it is only readable by root. Other user account information (UIDs, GIDs, home
directory paths, and startup shells) remain in the /etc/passwd file to ensure that login,
ps, ll, and other commands can still convert UIDs to usernames.

Module 3
Configuring Shadow Passwords

By default, the /etc/shadow file doesn’t exist. Use the cookbook below to convert to a
shadow password system:
1. Shadow password support is included by default in 11i v2 and v3. HP-UX 11i v1
administrators, however, must download and install the ShadowPassword patch bundle
from http://software.hp.com/. Use the swlist command to determine if the
product has already been installed.
# swlist ShadowPassword
2. Run pwck to verify that there aren’t any syntax errors in your existing /etc/passwd file.
# pwck
3. Use the pwconv command to move your passwords to the /etc/shadow file.
# pwconv
*Warning*: There is a restriction on the use of shadow password

functionality in this release of HP-UX. Failure to consider this
limitation may lead to an inability to log in to the system after
the conversion is performed. A system converted to use shadow
passwords is not compatible with any repository other than files
and ldap. This means that the passwd entry in the nsswitch.conf
file must not contain nis, nis+, or dce.
Would you like to proceed with the conversion? (yes/no): yes
4. Verify that the conversion succeeded. The /etc/passwd file should remain world-
readable, but the /etc/shadow file should only be readable by root. The encrypted
passwords in /etc/passwd should have been replaced by “x”s.
# ll /etc/passwd /etc/shadow
-r--r--r-- 1 root sys 914 May 18 14:35 /etc/passwd
-r-------- 1 root sys 562 May 18 14:35 /etc/shadow
5. You can revert to the traditional non-shadowed password functionality at any time via the
pwunconv command.
# pwunconv
All of the standard password commands, including passwd, useradd, usermod, userdel,
and pwck are shadow password aware.

Module 3
Fields in /etc/shadow
The /etc/shadow file is an ASCII file consisting of any number of user entries separated by
newlines. Each user entry line consists of the following fields separated by colons:
username Each login name must match a username in /etc/passwd. In 11i v3,
/etc/shadow is compatible with long usernames as described on the
/etc/passwd slide previously.
password When you convert to a shadowed system, each password in /etc/passwd is

replaced with an “x”, and the encrypted passwords are copied to the second
field in /etc/shadow. If the /etc/shadow password field is null, then there
is no password and no password is demanded on login. Login can be
prevented by entering a “*” in the /etc/shadow password field.
last changed The number of days since January 1, 1970 that the password was last
modified. This field is used by the password aging mechanism, which will be
described later in the chapter.
min days The minimum number of days that a user must retain a password before it can
be changed. This field is used by the password aging mechanism, which will
be described later in the chapter.
max days The maximum number of days for which a password is valid. A user who
attempts to login after his password has expired is forced to supply a new one.
If min days and max days are both zero, the user is forced to change his
password the next time he logs in. If min days is greater than max days, then
the password cannot be changed. These restrictions do not apply to the
superuser. This field is used by the password aging mechanism, which will be
described later in the chapter.
warn days The number of weeks the user is warned before his password expires. This
field is used by the password aging mechanism, which will be described later
in the chapter.
inactivity The maximum number of days of inactivity allowed after a password has
expired. The account is locked if the password is not changed within the
specified number of days after the password expires. If this field is set to zero,
then the user is required to change his password. This field is only used by
HP-UX trusted systems, which aren’t discussed in this course.
expiration The absolute number of days since Jan 1, 1970 after which the account is no
longer valid. A value of zero in this field indicates that the account is locked.
reserved The reserved field is always null, and is reserved for future use.

Module 3
Editing /etc/shadow
Manually editing the /etc/shadow file isn’t recommended. On a shadow password system,
you should use the useradd, usermod, userdel, and passwd commands to manage user
accounts in both /etc/passwd and /etc/shadow. These commands will be described in
detail later in the chapter.
Enabling SHA-512 Passwords in /etc/shadow
Traditionally, HP-UX has used a variation of the DES encryption algorithm to encrypt user
passwords in /etc/passwd. HP-UX 11i v2 and v3 now support the more secure SHA-512
algorithm if you install the Password Hashing Infrastructure patch bundle from
http://software.hp.com. HP-UX 11i v3 also supports long passwords up to 255
characters if you add the LongPass11i3 patch bundle, too. Use the following commands to
determine if your system has these patch bundles:
In 11i v2:
# swlist SHA
In 11i v3:
# swlist PHI11i3 LongPass11i3
These patches are not available for 11i v1.
After installing the software, add the following two lines to /etc/default/security to
enable SHA512 password hashing:
# vi /etc/default/security
CRYPT_DEFAULT=6
CRYPT_ALGORITHMS_DEPRECATE=__unix__
The lines above ensure that when passwords are created or changed, HP-UX always uses the
new SHA-512 algorithm rather than the legacy 3DES __unix__ algorithm. Existing users
can continue using their legacy passwords until their passwords expire, or until they
manually change their passwords.
As users change their passwords, note that the resulting passwords in /etc/shadow
become much longer. The $6$ prefix in the second password field below indicates that the
password was encrypted via SHA-512.
Before: user1:9oTPronwCKT9w:14370::::::
After: user1:$6$At65DRDJ$e9MfDCRnMMyJp1OeaOlzgslSyaXmzmS1TgGdni8
SUqrYYPvGSZXZNh/Ov0O5RdMgCe3Vap5DApx0zpr6XB190.:14370::::::
This functionality only works on systems that store passwords in /etc/shadow rather than
/etc/passwd.

Module 3
NIS and NIS+ are incompatible with this feature, as are some third party applications that
directly parse encrypted passwords.
Enabling Long Passwords in /etc/shadow
On 11i v3 systems, you can also enable long passwords up to 255 characters in length by
adding this line to /etc/default/security:
CRYPT_DEFAULT=6
CRYPT_ALGORITHMS_DEPRECATE=__unix__
LONG_PASSWORD=1
This functionality only works on systems that store passwords in /etc/shadow, and that
have the SHA512 password functionality enabled.
See the HP-UX Password Hashing Infrastructure Release Notes on http://docs.hp.com

for more information, the HP-UX LongPassword page on http://software.hp.com, and
HP HP-UX Security (H3541S) on http://www.hp.com/education course to learn more
about these features.

Module 3
3–5. SLIDE: The /etc/group File
The /etc/group File
y/etc/passwd determines a user’s primary group membership

y/etc/group determines a user’s secondary group memberships
other::1:root,daemon,uucp,sync
users::20:
accts::1001:user1,user2
sales::1002:user1,user2,user3,user4,user5,user6
Group GID Members
Use /usr/bin/vi to edit /etc/group
Use /usr/sbin/grpck to check the /etc/group file syntax
Student Notes
When a user logs in on HP-UX system, HP-UX checks the GID field in the user's
/etc/passwd entry to determine the user’s primary group membership. The /etc/group
file determines a user’s secondary group memberships.
Users will be granted group access rights to any file associated with either their primary or
secondary groups.
New files and directories that the user creates will, by default, be assigned to the user’s
primary group. Users who prefer to associate new files and directories with a secondary
group can use the newgrp command to temporarily change their GID.
# newgrp sales

Module 3
To return to the primary group, run newgrp without any options.
# newgrp
To determine which groups a user belongs to, use the groups command.
# groups user1
sales accts
/etc/group File Format

The colon delimited /etc/group file defines user groups.
group_name is the mnemonic name associated with the group. If you ll a file, you will see
this name printed in the group field.
In 11i v1 and v2, group names may only be 8 characters in length. In 11i v3,
the lugadmin command enables long group names up to 255 characters.
password may contain an encrypted group-level password in earlier versions, but is no

longer used.
group_id is the group ID (GID). This is the number that should be placed in the
/etc/passwd file in the group_id field.
GIDs 1-99 are reserved for other predefined groups required by the system.
SAM, SMH, and ugweb automatically assign GID numbers when creating
new groups.
Version 10.20 of HP-UX introduced support for GIDs as large as

2,147,483,646. Prior to HP-UX 10.20, GIDs greater than 60,000 were not
supported. To determine your system’s maximum UID, check the MAXUID
parameter in /usr/include/sys/param.h.
Using large GIDs may cause problems when sharing files with other systems
that don’t support large UIDs.
group_list is a list of usernames of users who are members of the group. A user's
primary group is defined in the fourth field of /etc/passwd, not in the
/etc/group file.
Each member can be a member of up to 20 secondary groups. This limit is

determined by the NGROUPS_MAX parameter in
/usr/include/limits.h. Also, each line in the /etc/group file can be
no more than 2048 characters, as defined by the LINE_MAX parameter in
/usr/include/limits.h.

Module 3
Required Entries in /etc/group

root::0:root
other::1:root,hpdb
bin::2:root,bin
sys::3:root,uucp
adm::4:root,adm
daemon::5:root,daemon
mail::6:root
lp::7:root,lp
tty::10:
nuucp::11:nuucp
nogroup:*:-2:
For more information on the /etc/group file, see group(4) in the HP-UX Reference
manual.
Checking the /etc/group File

The consistency of the /etc/group file can be checked with the /usr/sbin/grpck
command. It will check for the number of fields in each entry, and whether all login names
appear in the password file.
# grpck
users::20:root,user101
user101 - Logname not found in password file

Module 3
3–6. SLIDE: Creating User Accounts
Creating User Accounts

y Use useradd to create new user accounts
Create a user account:

# useradd –o \ # allow a duplicate UID
-u 101 \ # define the UID
-g users \ # define the primary group
-G class,training \ # define secondary groups
-c “student user” \ # define the comment field
–m –d /home/user1 \ # make a home directory for the user
–s /usr/bin/sh \ # define the default shell
-e 1/2/09 \ # define an account expiration date
-p fnnmD.DGyptLU \ # specify an encrypted password
-t /etc/default/useradd \ # specify a template
user1 # define the username
Interactively set a password for the new account:

# passwd user1 # interactively specify a password or…
# passwd –d user1 # set a null password
# passwd –f user1 # force a password change at first login
Student Notes
The useradd command provides a convenient mechanism for adding user accounts.
Without any options, useradd simply adds a user to the /etc/passwd file using all of the
user account defaults:
# useradd user1
# grep user1 /etc/passwd
user1:x:101:20::/home/user1:/sbin/sh
Most administrators choose to override one or more of these defaults via some combination
of the command line options listed below:
-o -u uid -u specifies the User ID (UID) for the new user. uid must be a non-
negative integer less than MAXUID as it is defined in the
/usr/include/sys/param.h header file. uid defaults to the next
available unique number above the maximum currently assigned number.
UIDs from 0-99 are reserved.

Module 3
The –o option allows the UID to be non-unique. This is most useful when
creating multiple user accounts with UID 0 administrator privileges.
-g group Specifies the integer group ID or character string name of an existing

group. This defines the primary group membership of the new login.
-G group Specifies a comma separated list of additional GIDs or group names. This
defines the supplemental group memberships of the new login. Multiple
groups may be specified as a comma separated list. Duplicates within the
-g and -G options are ignored.
-c comment Specifies the comment field in the /etc/passwd entry for this login. This
can be any text string. A short description of the new login is suggested for
this field. The field may be used to record users’ names, telephone
numbers, office locations, employee numbers, or other information. The
field isn’t referenced by the system.
-k skeldir Specifies the skeleton directory containing files that should be copied to
all new user accounts. Defaults to /etc/skel. See the /etc/skel
discussion later in this chapter for more information.
-m -d dir -d specifies the new user’s home directory path. The home directory path
defaults to /home/username. With the optional –m (make) option,
useradd also creates the home directory.
-s shell Specifies the full pathname of the new user’s login shell. By default, the
system uses /sbin/sh as the login shell. /sbin/sh is a POSIX shell, but
it’s a “statically linked” executable that consumes more system resources
than the dynamically linked /usr/bin/sh shell. /sbin/sh is required
for the root account, but other accounts should use /usr/bin/sh.
-e expire Specifies the date after which this login can no longer be used. After
expire, no user will be able to access this login. Use this option to create
temporary logins. expire, which is a date, may be typed in a variety of
formats, including mm/dd/yy. See the man page for other supported
formats. This option only works on systems configured to use the
/etc/shadow file.
-f inactive Specifies the maximum number of days of continuous inactivity of the login
before the login is declared invalid. This option is only supported on
trusted systems. To learn more about HP’s trusted system functionality,
attend HP Customer Education’s H3541S course.
-p password Specifies an encrypted password for the account. The argument passed to
–p must be a valid encrypted password, created via the crypt perl/C
function. The example below uses command substitution to execute a
perl command that encrypts password “hp” for user1. Although this
solution is convenient, beware that the command (which includes the
user’s cleartext password) will appear in the process table and in
~/.sh_history.

Module 3
useradd -p $(perl -e "print crypt('hp','xx')") user1
For a description of the perl function, type perlfunc –f crypt.

For a description of the equivalent C function, type man 2 crypt.
If –p isn’t specified, useradd creates the user account, but doesn’t enable
it. Execute the passwd username command to interactively assign a
password to the new account.
-t template Specifies a template file, which establishes default options for the
command. See the user template discussion below.
/etc/default/useradd is the default template file.
username Specifies the new user’s username. The username should be between one
and eight characters in length. The first character should be alphabetic. If
the name contains more than eight characters, only the first eight are
significant.
The slide shows a complete example using many of these options.
Setting a User Password

The useradd command creates a user account, but unless the –p option was specified, the
passwd command must be used to define a password for the new account before the user
can login.
The administrator can either define a password for the user or set a null password:
# passwd user1 # interactively specify a password for the user or…

# passwd –d user1 # set a null password
In either case, most administrators force new users to choose a new, memorable password
the first time they login.
# passwd –f user1 # force a password change at first login
Creating useradd Templates in /etc/default/

Administrators who manage many user accounts often configure useradd template files in
the /etc/default/ directory. Template files establish default values for many of the
useradd options. The useradd command consults the /etc/default/useradd
template by default, but additional templates can be created as well with different default
parameters for different types of users. The example below creates a useradd template that
might be used when creating user accounts for C application developers who prefer to use
the C shell and need to belong to the developer group. The example only demonstrates a few
options. See the useradd(1m) man page for additional options.
# useradd –D \ # update defaults for a template

-t /etc/default/useradd.cusers \ # template file location
-b /home \ # base for home directories

Module 3
-c “C programmer” \ # comment
-g developer \ # primary group
-s /usr/bin/csh # default shell
To verify that the template was created, execute useradd with just the –D and –t options,
or simply cat the file.
# useradd -D -t /etc/default/useradd.cusers
GROUPID 20
BASEDIR /home
SKEL /etc/skel
SHELL /usr/bin/csh
INACTIVE -1
EXPIRE
COMMENT programmer
CHOWN_HOMEDIR no
CREAT_HOMEDIR no
ALLOW_DUP_UIDS no
The example below uses the new template to create a user account. Recall that –m creates a
home directory for the new user.
# useradd –m -t /etc/default/useradd.cusers user1

# tail -1 /etc/passwd
user1:*:101:20:programmer:/home/user1:/usr/bin/csh

Module 3
3–7. SLIDE: Modifying User Accounts
Modifying User Accounts

y The administrator can use usermod to modify user accounts
y Users can modify some attributes of their own accounts via passwd, chsh, and chfn
Modify a user account (Administrators):

# usermod –l user01 user1 # change the user’s username
# usermod –o -u 101 user1 # change the user’s UID
# usermod -g users user1 # change the user’s primary group
# usermod -G class,training user1 # change the user’s secondary group(s)
# usermod -c “student” user1 # change the user’s comment field
# usermod –m -d /users/user01 user1 # move the user’s home directory
# usermod –s /usr/bin/ksh user1 # change the user’s default shell
# usermod –e 1/3/09 user1 # change the user’s account expiration
# usermod -p fnnmD.DGyptLU user1 # non-interactively change a password
Modify a user password (Administrators):
# passwd user1 # interactively change a password
Modify a user account or password (Users):
$ passwd # change the user’s password
$ chsh user1 /usr/bin/ksh # change the user’s shell
$ chfn user1 # change the user’s comment field
Student Notes
User account settings may be modified by the administrator, or, to a lesser extent, by users.
Modifying a User Account (Administrators)

The system administrator can change any user’s account settings via the passwd and
usermod commands.
-l username Changes the user’s username. This option doesn’t, however, change the
user’s home directory name. See the –m and -d options below.
-o -u uid -u changes the user’s User ID (UID).
Changing a user’s UID via usermod automatically changes the ownership

of the files in the user’s home directory to match the new UID. If the user
owns files in other directories, though, be sure to use the chown command
to change the ownership of those files to match the new UID.

Module 3
The –o option allows the new UID to be non-unique (i.e.: allows duplicate
UIDs). This is most useful when creating multiple user accounts with UID
0 administrator privileges.
-g group Changes the user’s primary group membership.
-G group Replaces the user’s existing secondary group memberships in

/etc/group with a new list of secondary group memberships. Multiple
groups may be specified as a comma separated list.
-c comment Specifies the comment field in the /etc/passwd entry for this login. This
can be any text string. A short description of the new login is suggested for
this field. The field may be used to record users’ names, telephone
numbers, office locations, employee numbers, or other information. The
field isn’t referenced by the system.
-m -d dir -d Changes the user’s home directory path in /etc/passwd. The –m

option moves the user’s existing home directory to the new location
specified by –d. Without the –m option, the user’s home directory path is
changed in /etc/passwd, but no files are moved. If the –m option isn’t
specified, the directory following the –d must be an existing directory.
-p password Specifies an encrypted password for the account. The argument passed to
–p must be a valid encrypted password, created via crypt perl/C
function. The example below uses command substitution to execute a
perl command that encrypts password “hp” a new user1 account.
# useradd -p $(perl -e "print crypt('hp','xx')") user1
For a description of the crypt function, type perlfunc –f crypt.

For a description of the equivalent C function, type man 2 crypt.
-p is mostly used in scripts designed to modify multiple account

passwords in an automated fashion. To interactively modify a user’s
password, use the passwd command instead.
# passwd user1
Changing password for user1
New password: ******
Re-enter new password: ******
Passwd successfully changed
-s shell Specifies the full pathname of the new user’s login shell. By default, the
system uses /sbin/sh as the login shell. /sbin/sh is a POSIX shell, but
it’s a “statically linked” executable that consumes more system resources
than the dynamically linked /usr/bin/sh shell. /sbin/sh is required
for the root account, but other accounts should use /usr/bin/sh.
-e expire Specifies the date after which this login can no longer be used. After
expire, no user will be able to access this login. Use this option to create

Module 3
temporary logins. expire, which is a date, may be typed in a variety of

formats, including mm/dd/yy. See the man page for other supported
formats. This option only works on systems configured to use the
/etc/shadow file.
-f inactive Specifies the maximum number of days of continuous inactivity of the login
before the login is declared invalid. This option is only supported on
trusted systems. To learn more about HP’s trusted system functionality,
attend HP Customer Education’s H3541S course.
Modifying a User Password (Administrators)

Administrators can change any user’s password. The administrator isn’t prompted for the
user’s existing password.
$ passwd user1
Alternatively, use the –d option to set a null password. Users with null passwords aren’t
prompted to enter a password at login.
# passwd -d user1
In either case, consider using the –f option to force the user to personally select a new
password at next login.
# passwd -f user1
Modifying a User Account (Users)

Users can change their own passwords via the passwd command, but must know their
current password.
$ passwd
Old password: ******
Users can modify some of their other account attributes, too, via the chsh, and chfn
commands.
$ passwd # change the user’s password

$ chsh user1 /usr/bin/ksh # change the user’s shell
$ chfn user1 # change the user’s comment field interactively

Module 3
3–8. SLIDE: Deactivating User Accounts
Deactivating User Accounts
y Deactivating a user account prevents the user from logging in

y However, the user’s entry remains in the /etc/passwd file and can be reactivated
y The user’s files can be left as-is, removed, or transferred to another user
Deactivate a user account

# passwd –l user1
Reactivate a user account
# passwd user1
Remove a user’s home directory
# rm –rf /home/user1
Or… Remove the user’s files from every directory
# find / -user user1 –type f –exec rm –i +
# find / -user user1 –type d –exec rmdir +
Or… Transfer ownership to a different user
# find / -user user1 –exec chown user2 +
Student Notes
If a user is going on leave, or no longer needs access to the system, deactivate/lock their
account. Deactivating an account places an “*” in the user’s password field and prevents the
user from logging in.
# passwd –l user1
If the user returns, simply choose a new password for the user to reactivate their account.
# passwd user1
If a user’s account has been deactivated and the user’s files will never be used by another
user, reclaim the user’s disk space by removing their home directory.
# rm –rf /home/user1

Module 3
Some users may have files scattered across other directories as well. Use the find
command to find and remove the user’s files and directories. The –i option provides an
opportunity to review each file before removing it.

# find / -user user1 –type d –exec rmdir –i +
Alternatively, consider reassigning the user’s files to a different user. The example below
chowns all files owned by user1 to user2.
# find / -user user1 chown user2 +

Module 3
3–9. SLIDE: Removing User Accounts
Removing User Accounts
y Removing a user removes the user from /etc/passwd and /etc/group

y The user’s files can be left as-is, removed, or transferred to another user
Delete a user account, but leave the user’s files untouched

# userdel user1
Delete a user account and remove the user’s home directory
# userdel –r user1
Or… Remove the user’s files from every directory
# find / -user user1 –type d –exec rmdir +
Or… Transfer ownership to a different user
Find files owned by non-existent users or groups
# find / -nouser –exec ll –d +
# find / -nogroup –exec ll -d +
Student Notes
If you are certain that a user will never need access to your system again, you may prefer to
remove the user’s account from the /etc/passwd file entirely.
# userdel user1
If you want to remove the user’s home directory, too, include the –r (recursive remove)
option.
# userdel -r user1
Some users may have files scattered across other directories as well. You can use the find
command to find and remove the user’s other files and directories.

# find / -user user1 –type d –exec rmdir –i +

Module 3
Alternatively, consider reassigning the user’s files to a different user.
Or, perhaps simply leave the files on disk as-is. If you choose this approach, the ll
command will report the old user’s userid rather than username in the file owner field. Use
the find command to general a list of all such “orphaned” files.
# find / -nouser –exec ll –d +

# find / -nogroup –exec ll -d +

Module 3
3–10. SLIDE: Configuring Password Aging
Configuring Password Aging
Password aging forces users to change their passwords on a regular basis
# passwd -n 7 -x 70 –w 14 user1 # enable password aging for a user

# passwd -s user1 # check a user’s password status
# passwd –sa # check the status of all users
Password Password Password Password

Change Change Warning Change
Prohibited Allowed Appears Required!
t=0 days t=7 days t=56 days t=70 days

(requires
/etc/shadow)
Student Notes
Many administrators force users to change their passwords on a regular basis via password
aging. Thus, even if a hacker were to obtain a copy of the /etc/passwd file, passwords
gleaned from that file would only be useful for a short period of time.
Password aging may be enabled via the /usr/bin/passwd command:
# passwd -n 7 -x 70 –w 14 user1
<min> argument rounded up to nearest week
<max> argument rounded up to nearest week
<warn> argument rounded up to nearest week
The -x option defines the maximum number of days a user is allowed to retain a password.
In the example on the slide, user1 will be forced to change his or her password every 28 days.
The -n option defines the minimum number of days a user is required to retain a password
after a password change. This, too, is rounded to the nearest week. In the example on the
slide, user1 must retain each new password for a minimum of 7 days. This prevents a user

Module 3
from changing their password, then immediately reverting to their previously used password
each time their password expires.
-n Sets the minimum number of days between password changes. Although this
parameter must be specified in days, passwd rounds up to the nearest week. In the
example on the slide, user1 must retain each new password for a minimum of 7 days.
This prevents a user from changing their password, then immediately reverting to
their previous password.
-x Sets the maximum number of days allowed between password changes. Although
this parameter must be specified in days, passwd rounds up to the nearest week.
-w Sets the password expiration warning period. The –w option causes the system to
display a login warning message one or more weeks before a user’s password expires.
The number of days is configurable. The –w option is only available on systems
configured to use the /etc/shadow file. And must be specified in multiples of seven
days.
You can check the password status of a user's account with the -s option.
# passwd -s user1
user1 PS 03/21/05 7 70 14
This generates a one-line summary indicating when the minimum and maximum password
aging parameters, as well as the week when the password was last changed. To view the
aging status of all user accounts, execute:
# passwd -sa
user1 PS 03/21/05 7 70 14
user2 PS
user3 PS
Password Aging Fields in the /etc/passwd and /etc/shadow Files

On a non-shadowed system, password aging is put in effect for a particular user if the user's
encrypted password in the passwd file is followed by a comma and a non-null string of
characters. This string defines the age used to implement password aging. The characters
that are used to represent digits are as follows:
Characters Number of Weeks

. → 0
/ → 1
0-9 → 2-11
A-Z → 12-37
a-z → 38-63
The first character of the age, M, denotes the maximum number of weeks for which a
password is valid. A user who attempts to login after the password has expired is forced to
supply a new one. The next character, m, denotes the minimum period in weeks that must
expire before the password can be changed. The remaining characters define the week

Module 3
(counted from the beginning of 1970) when the password was last changed (a null string is
equivalent to zero).
If m = M = 0 the user is forced to change the password at the next log in (and the age
disappears from the password entry). If m > M (the string ./), only a superuser (not the user)
can change the password.
On a shadow password system, password aging information is recorded in the

/etc/shadow file rather than /etc/passwd. See the /etc/shadow slide elsewhere in the
chapter for more information.
Although these parameters may be set manually, it's much easier to use the
/usr/bin/passwd command!

Module 3
3–11. SLIDE: Configuring Password Policies
Configuring Password Policies
y Use /etc/default/security to establish default password & security policies
MIN_PASSWORD_LENGTH=
PASSWORD_MIN_UPPER_CASE_CHARS=
PASSWORD_MIN_LOWER_CASE_CHARS=
PASSWORD_MIN_DIGIT_CHARS=
PASSWORD_MIN_SPECIAL_CHARS=
PASSWORD_MAXDAYS=
PASSWORD_MINDAYS=
PASSWORD_WARNDAYS=
Student Notes
In order to ensure that users choose secure passwords, HP-UX supports a configuration file
called /etc/default/security that may be used to define a variety of security policies.
To use these policies in 11i v1, install the ShadowPassword patch bundle and PHCO_24606.
11i v3, and the SecurityExt software bundle in 11i v2, provide support for several
additional parameters not shown on the slide. See the security(4) man page for a
complete list of policies and parameters available on your system.
MIN_PASSWORD_LENGTH=N
New passwords must contain at least N characters.
PASSWORD_MIN_UPPER_CASE_CHARS=N
New passwords must contain a minimum of N upper-case characters. In 11i v1, this
only applies if PHCO_24606 is installed.

Module 3
PASSWORD_MIN_LOWER_CASE_CHARS=N
New passwords must contain a minimum of N lower-case character. This only applies
if PHCO_24606 is installed.
PASSWORD_MIN_DIGIT_CHARS=N
New passwords must contain a minimum of N digit characters are required in a

password when changed. This only applies if PHCO_24606 is installed on your
system.
PASSWORD_MIN_SPECIAL_CHARS=N
Specifies that a minimum of N special characters are required in a password when

changed.
PASSWORD_MAXDAYS=N
This parameter controls the default maximum number of days that passwords are
valid. This parameter applies only to local users and does not apply to trusted
systems. The passwd -x option can be used to override this value for a specific
user.
PASSWORD_MINDAYS=N
This parameter controls the default minimum number of days before a password can
be changed. This parameter applies only to local users and does not apply to trusted
systems. The passwd -n option can be used to override this value for a specific user.
PASSWORD_WARNDAYS=N
This parameter controls the default number of days before password expiration that a
user is to be warned that the password must be changed. This parameter applies only
to local users on Shadow Password systems. The passwd -w option can be used to
override this value for a specific user.

Module 3
3–12. SLIDE: Managing Groups
Managing Groups
y Each user can belong to one or more groups
y Groups can be managed via groupadd/groupmod/groupdel
y Group memberships can be managed via usermod and groups
Create a new group

# groupadd -g 200 accts
Change a group name
# groupmod -n accounts accts
Add, modify, or delete a list of users to or from a group
# groupmod –a –l user1,user2 accounts add a list of users to a group
# groupmod –m –l user3,user4 accounts replace the list of users in a group
# groupmod –a –l user3,user4 accounts delete a list of users from a group
Delete a group
# groupdel accounts
Change a specific user’s primary and secondary group membership
# usermod –g users user1
# usermod –G class,training user1
View a user’s group memberships
# groups user1
Student Notes
Each user on an HP-UX system may belong to one or more groups. Groups may be managed
via the groupadd/groupmod/groupdel command line utilities. Group membership may be
managed via the usermod and groups commands.
Create a new group:
# groupadd -g 200 accts
Change a group name:
# groupmod -n accounts accts
Add a list of users to a group:
# groupmod –a –l user1,user2 accounts
Replace the current list of users in a group with a new list of users:

Module 3
# groupmod –m –l user3,user4 accounts
Delete a list of users from a group:
# groupmod –a –l user3,user4 accounts
Delete a group:
# groupdel accounts

Module 3
Change a user’s primary and secondary group membership:
# usermod –g users user1

# usermod –G class,training user1
View a user’s group memberships:
# groups user1

Module 3
3–13. SLIDE: Managing /etc/skel
Managing /etc/skel
y ~/.profile and other hidden files establish a user’s environment at login

y /etc/skel/ contains template files to be copied to every new user account
─ Files can be added/modified/removed from /etc/skel as necessary
─ Changes in /etc/skel don’t affect existing user accounts
/etc/skel/ /home/user1/
.profile .profile
copied
to new
.shrc accounts .shrc
.exrc .exrc
Student Notes
When a user logs into a UNIX system, several scripts execute to establish the user’s shell
environment. The list below describes the scripts that execute during the POSIX and Korn
shell login process. Login processes for other shells may vary.
1. After the user enters a username and password, the /usr/bin/login script checks the
/etc/passwd file to verify that the user has a valid account. If the user's username and
password are correct, the login program launches a shell for the user.
2. Next, the newly launched shell executes a script called /etc/profile.

/etc/profile is a POSIX/Korn shell script that is maintained by the system
administrator to configure a default environment for all users. The script accesses the
/etc/PATH, /etc/MANPATH, and /etc/TIMEZONE files to set initial values for the
PATH, MANPATH, and TZ variables. The script attempts to define the TERM variable
automatically, too. Since /etc/profile executes every time any user logs in, the
administrator can modify this file to set global default environment variables for all users
at login time.

Module 3
3. Next, the user's personal ~/.profile script executes. Each user has a .profile
script that executes at login time to define additional environment variables, or to
override the default environment variable values that the administrator defined in
/etc/profile.
4. Finally, the shell looks for an environment variable called ENV. The ENV variable
identifies a personal shell startup program that users may optionally choose to configure.
POSIX shell users often create a ~/.shrc shell startup script, while Korn shell users
typically define a ~/.kshrc shell startup script. Unlike the ~/.profile script, which
only executes at login, the shell startup script executes every time the user logs in, runs a
shell script, opens a terminal emulator window, or launches a shell. The POSIX and Korn
shell startup scripts are typically used to define shell aliases.
Users can modify their personal ~/.profile and ~/.shrc scripts. The administrator can
create a template version of these in the /etc/skel directory. useradd automatically
copies the files found in this directory to each new user home directory.
Thus, if you wish to change the default configuration files that are copied to new users' home
directories, simply modify the files in /etc/skel. Note that changes made in /etc/skel
won't affect existing users' home directories. Updated files will only be copied to new user
accounts.
Additional files can be copied into /etc/skel as well, if your applications require
configuration files in users' home directories. The /etc/skel directory on the slide
includes a .exrc file which defines vi macros and keyboard shortcuts.
Administrators on very large systems may choose to create subdirectories under /etc/skel
for different user account types. Then, when creating a user account, use the useradd –k
skeldir option to specify which skeleton directory useradd should copy files from.
NOTE: There is no CDE .dtprofile script in /etc/skel. The first time a user
logs in via CDE, HP-UX attempts to copy either
/etc/dt/config/sys.dtprofile (if it exists) or
/usr/dt/config/sys.dtprofile to the user's ~/.dtprofile. Use the
following procedure to customize the default .dtprofile:
# cp –p /usr/dt/config/sys.dtprofile \
/etc/dt/config/sys.dtprofile
# vi /etc/dt/config/sys.dtprofile
Some Common Environment Variables

The .profile script establishes a user’s environment by setting environment variables. The
table below lists some of the most commonly modified environment variables.
TERM The TERM variable defines the user's terminal type. If the TERM variable is set
incorrectly, applications may not be able to write to the user's terminal properly.

Module 3
Valid terminal types are listed in the /usr/lib/terminfo/* directories. You

can explicitly set an appropriate TERM value using a command similar to the
following:
export TERM=vt100 # for a vt100 type terminal

export TERM=hp # for an HP ASCII terminal
export TERM=dtterm # for a dtterm terminal emulator window
More commonly, however, the TERM variable is set using the ttytype
command, which can usually automatically determine your terminal type. The
following portion of code can be included in one of the scripts that runs at login
to set your terminal type for you:
if [ "$TERM" = "" -o \
"$TERM" = "unknown" -o \
"$TERM" = "dialup" -o \
"$TERM" = "network" ]
then
eval `ttytype -s -a`
fi
export TERM
PS1 The PS1 variable defines your shell prompt string. This, too, can be changed by
the user. Some useful sample PS1 values are shown below:
export PS1='$ ' # Use a simple "$ " prompt

export PS1='$PWD $' # Include the user's pwd in the prompt
export PS1='$PWD ($LOGNAME) $' # Include the user's username ,too
LPDEST LPDEST defines the user's default printer. The printer named in LPDEST takes
precedence over the system-wide default printer configured by the system
administrator. Examples:
export LPDEST=laser # use "laser" as the default printer

export LPDEST=printera # use "printera" as the default printer
PATH Every time the user enters a command, the shell must find the executable
associated with the requested command. The PATH variable contains a ":"
separated list of directories that the shell should search for executables. If users
need access to new applications and utilities, you may need to modify their PATH
variables. You can append a new directory to the user's PATH using syntax
similar to the following syntax:
PATH=$PATH:/usr/local/bin # adds /usr/local/bin

# to the existing PATH
The initial PATH variable value usually taken from the /etc/PATH file.
Oftentimes installing an application automatically updates the /etc/PATH file
for you, so it may not be necessary to update individual users' PATHs.

Module 3
EDITOR Three variables must be defined if your users want to use command line editing:
export EDITOR=vi
export HISTFILE=~/.sh_history
export HISTSIZE=50
EDITOR defines the user's preferred command line editor. emacs and vi are the
only allowed values. HISTFILE determines the file that should be used to log
commands entered by the user. HISTSIZE determines the number of commands
retained in the shell's command buffer.
TZ Defines the user’s time zone. Internally, UNIX records timestamps as the number
of seconds since January 1, 1970 UTC. Commands that display timestamps
(date, who, ll, etc.) display dates and times relative to the timezone specified in
the user’s TZ variable. The administrator can establish a system-wide default
value in /etc/TIMEZONE, but individual users may wish to customize the
variable to match their local time zone. See the /usr/lib/tztab file for a list
of recognized time zones. The example below establishes a TZ value appropriate
for users in Chicago.
export TZ=CST6CDT
These are just some of the more commonly defined environment variables that you can
define for your users. Other environment variables are defined in the man page for the
POSIX shell (man 1 sh-posix), and still others may be required by your applications.
Environment variables can be set from the command line, but are more commonly defined in
the login configuration files, which will be covered later in this chapter. You can view a list
of currently defined environment variables by executing the env command:
# env

Module 3
3–14. LAB: Managing User Accounts
Directions
Perform the following tasks. Record the commands you use, and answer all questions. The
password for user accounts user1-24 is class1.
Part 1: Creating and Modifying Users and Groups

1. Use the useradd command to create a user account for user25 on your system.
Include the option to create a home directory for the user, and use /usr/bin/sh as the
user’s startup shell. Accept defaults for the other options.
2. Do you see an entry for the new user in the /etc/passwd file?
Do you see an entry for the new user in the /etc/group file? Explain.
3. Can the user login at this point?
4. Choose and set a password for the new user.
5. Force the user to choose a new password the first time they login.

Module 3
6. Login as user25 to verify that the new account works. What happens?
7. Return to the root account.
8. Oops! We forgot to define the comment field for user25. Set user25’s comment field
to “student account”.
9. user25 needs to collaborate with user24 on a project. Create a group called

project, and ensure that user24 and user25 both have access to the group.
10. Create a /home/project directory that user24 and user25 can use to store and
manage files associated with their project. Ensure that the administrator and members of
the project group are the only users who can access the shared directory.
# mkdir /home/project
# chown root:project /home/project
# chmod 770 /home/project
11. Verify that user24 and user25 have access to the group, and that other users don’t.
# su user23 –c “touch /home/project/f23” # should fail!

# su user24 –c “touch /home/project/f24” # should succeed!

Module 3
Part 2: Deactivating and Removing User Accounts

1. Deactivate user24's account.
2. Remove user25’s account without removing user25’s home directory.
3. What changed in the /etc/passwd file because of the commands in the previous two
questions?
4. What happens now when user24 and user25 attempt to log in? telnet to your local
host, and try to login using both usernames. What happens?
# telnet localhost
5. What happened to the users’ home directories? Do a long listing of /home. Can you
explain what you see?
# ll –d /home/user24 /home/user25
6. Re-enable user24's account. Choose a new password as you wish.

Module 3
Part 3: Implementing Shadow Passwords and Password Aging

1. Run pwconv to create the /etc/shadow file. You may see a warning noting that
shadow passwords are incompatible with NIS. Since we’re not using NIS, ignore the
message.
a. What is in the password field in /etc/passwd now?
b. What fields are populated in /etc/shadow?
c. What are the permissions on /etc/shadow? Why is this significant?
2. Enable shadow password aging on the user1 account.
a. Ensure that the password is changed at least twice per year.
b. Ensure that users wait at least one week between password changes.
c. Provide a one-week warning before the user’s password expires.
3. Apply the same password aging parameters to all users by modifying the appropriate
variables in /etc/default/security. Also require users to choose passwords that
are at least eight characters.
4. Before you continue on to the next part, revert to a non-shadowed password file.

Module 3
Part 4: (Optional) Automating User Account Creation

Pretend for a moment that you are a system administrator at a large university. Fifty
students have just enrolled to start classes, and you need to create user accounts for
them. Can you write a simple shell script to automatically create the user accounts?
Initially, you can assign the students null passwords, but force them to change their
passwords after their first successful login. Assign /usr/bin/sh as the users’ startup
shell.
Hint: Try running the sample shell script below. What must be changed in the shell script
to automatically create the desired accounts?
#!/usr/bin/sh
n=1
while ((n<=50))
do
echo stud$n
((n=n+1))
done

Module 3
Part 5: (Optional) Managing Users and Groups via the SMH

If time permits, explore the Accounts for Users and Groups functional area in the
SMH:
# smh -> Accounts for Users and Groups or...

# ugweb
A similar Accounts for Users and Groups functional area exists in sam in earlier
versions of HP-UX.

Module 3
3–15. LAB SOLUTIONS: Managing User Accounts

Perform the following tasks. Record the commands you use, and answer all questions. The
password for user accounts user1-24 is class1.
Part 1: Creating and Modifying Users and Groups

1. Use the useradd command to create a user account for user25 on your system.
Include the option to create a home directory for the user, and use /usr/bin/sh as the
user’s startup shell. Accept defaults for the other options.
Answer:
# useradd –m –s /usr/bin/sh user25
2. Do you see an entry for the new user in the /etc/passwd file?
Do you see an entry for the new user in the /etc/group file? Explain.
Answer:
There should be an entry in the /etc/passwd file for the new user. However, the user
isn’t listed in /etc/group. A user's primary group membership is recorded in the
/etc/passwd GID field; /etc/group only records secondary group memberships.
3. Can the user login at this point?
Answer:
The user can’t login at this point since the user’s password hasn’t been defined yet.
4. Choose and set a password for the new user.
Answer:
# passwd user25
5. Force the user to choose a new password the first time they login.
Answer:
# passwd –f user25
6. Login as user25 to verify that the new account works. What happens?
# login
Answer:
The system should have required a password change for user25.

Module 3
7. Return to the root account.
Answer:
$ exit
Log back in again as root.
8. Oops! We forgot to define the comment field for user25. Set user25’s comment field
to “student account”.
Answer:
# usermod –c “student account” user25
9. user25 needs to collaborate with user24 on a project. Create a group called

project, and ensure that user24 and user25 both have access to the group.
Answer:
# groupadd project
# usermod -G project user24
# usermod -G project user25
10. Create a /home/project directory that user24 and user25 can use to store and
manage files associated with their project. Ensure that the administrator and members of
the project group are the only users who can access the shared directory.
# mkdir /home/project
# chown root:project /home/project
# chmod 770 /home/project
11. Verify that user24 and user25 have access to the group, and that other users don’t.
# su user23 –c “touch /home/project/f23” # should fail!


Module 3
Part 2: Deactivating and Removing User Accounts

1. Deactivate user24's account.
Answer:
# passwd -l user24
Now try to log in as user user24. It should fail.
2. Remove user25’s account without removing user25’s home directory.
Answer:
# userdel user25
3. What changed in the /etc/passwd file because of the commands in the previous two
questions?
Answer:
user24's password field is set to "*" to indicate that the account is disabled.
user25's /etc/passwd entry disappeared entirely.
4. What happens now when user24 and user25 attempt to log in? telnet to your local
host, and try to login using both usernames. What happens?
# telnet localhost
Answer:
Both login attempts should fail.
5. What happened to the users’ home directories? Do a long listing of /home. Can you
explain what you see?
# ll –d /home/user24 /home/user25
Answer:
Both directories are still there, but the owner field for user25's directory lists a number
rather than user25's username. Internally, HP-UX identifies file ownership by UID
rather than username. ll attempts to resolve these UIDs into usernames. However,
since user25 is no longer listed in /etc/passwd, the ll command has no way of
determining which username is associated with the /home/user25 directory.

Module 3
6. Re-enable user24's account. Choose a new password as you wish.
Answer:
# passwd user24

Module 3
Part 3: Implementing Shadow Passwords and Password Aging

1. Run pwconv to create the /etc/shadow file. You may see a warning noting that
shadow passwords are incompatible with NIS. Since we’re not using NIS, ignore the
message.
a. What is in the password field in /etc/passwd now?
b. What fields are populated in /etc/shadow?
c. What are the permissions on /etc/shadow? Why is this significant?
Answer:
The password fields in /etc/passwd should contain x’s.
Each /etc/shadow entry should contain a user name, an encrypted password, and a
timestamp field that indicates when the password was last changed. The other fields
should be empty.
The permissions on /etc/shadow should be r--------, so hackers can’t view user

password information.
2. Enable shadow password aging on the user1 account.
a. Ensure that the password is changed at least twice per year.
b. Ensure that users wait at least one week between password changes.
c. Provide a one-week warning before the user’s password expires.
Answer:
# passwd –x 180 –n 7 –w 7 user1

Module 3
3. Apply the same password aging parameters to all users by modifying the appropriate
variables in /etc/default/security. Also require users to choose passwords that
are at least eight characters.
Answer:
MIN_PASSWORD_LENGTH=8
PASSWORD_MAXDAYS=180
PASSWORD_MINDAYS=7
PASSWORD_WARNDAYS=7
The file is read-only by default, so a :w! followed by :q is needed if vi(1m) editor is

used.
4. Before you continue on to the next part, revert to a non-shadowed password file.
Answer:
# pwunconv

Module 3
Part 4: (Optional) Automating User Account Creation

1. Pretend for a moment that you are a system administrator at a large university. Fifty
students have just enrolled to start classes, and you need to create user accounts for
them. Can you write a simple shell script to automatically create the user accounts?
Initially, you can assign the students null passwords, but force them to change their
passwords after their first successful login. Assign /usr/bin/sh as the users’ startup
shell.
Answer:
Create a Shell script useradd_stud_accts.sh
#!/usr/bin/sh
n=1
while ((n<=50))
do
echo stud$n
useradd –m –s /usr/bin/sh stud$n
passwd –d –f stud$n
((n=n+1))
done
Make script executable and run:

# chmod +x useradd_stud_accts.sh
# ./useradd_stud_accts.sh
To clean up the accounts, create script userdel_stud_accts.sh.

#!/usr/bin/sh
n=1
while ((n<=50))
do
echo stud$n
userdel stud$n
rm -rf /home/stud$n
((n=n+1))
done

Module 3
Part 5: (Optional) Managing Users and Groups via the SMH

If time permits, explore the Accounts for Users and Groups functional area in the
SMH.
From the Home Page, click "System Configuration." From the System Configuration Window,
click "Accounts for Users and Groups".
When this exercise is complete, Sign out of the SMH utility and close the browser window.
A similar Accounts for Users and Groups functional area exists in sam in earlier
versions of HP-UX.

Module 3

Module 4 ⎯ Navigating the HP-UX File System
Objectives
• Describe the reasons for separating dynamic and static file systems.
• Describe the key contents of /sbin, /usr, /stand, /etc, /dev, /var (OS-related
directories).
• Describe the key contents of /opt, /etc/opt, and /var/opt (application-related

directories).
• Use find, whereis, and which to find files in the HP-UX file system.

Module 4
Navigating the HP-UX File System
4–1. SLIDE: Introducing the File System Paradigm
Introducing the File System Paradigm
OS
Executables Application
OS
Static Files Libraries Application
System startup
OS
Configuration Application
Dynamic Files Temporary OS
Application
User
Student Notes
Many HP-UX system administration tasks require the administrator to find and manipulate
system and application configuration and log files. Understanding the philosophy behind the
organization of the file system will ensure that you can successfully find the resources you
need to perform administration tasks.
Files in the HP-UX file system are organized by various categories. Static files are separated
from dynamic files. Executable files are separated from configuration files. This philosophy
provides a logical structure for the file system and simplifies administration as well.
HP-UX Separates Static and Dynamic Portions of the File System

Files and directories in HP-UX may be categorized as static or dynamic. The contents of
static files and directories rarely change, except when patching or installing the operating
system or applications. Executable files, libraries, and system start-up utilities are all
considered to be static.
Dynamic files and directories change frequently. They are stored in a separate portion of the
file system. Configuration, temporary, and user files are all considered to be dynamic.

Module 4
Separating dynamic and static data offers the following advantages:

• System backups are easier.
• Disk space management is simplified.
HP-UX Separates Executable Files from Configuration Files

Configuration data is kept separate from the executable code that uses that data. Separating
executable files from configuration files offers the following advantages:
• Changes made to configuration data are not lost when updating the operating system.
• Executable files can be easily shared across the network, while host-specific
configuration data is stored locally on each host.
HP-UX Follows the AT&T SVR4 Standard File System Layout

Though there are minor differences from vendor to vendor, the file system layout used in
HP-UX is very similar to that used in other flavors of UNIX. This simplifies administration
tasks for administrators with responsibilities on multiple vendors' machines.

Module 4
4–2. SLIDE: System Directories
System Directories
/ (root) DYNAMIC FILES
/opt
/var
/dev /mnt
App2 /etc
App1 /tmp
/usr
/stand
STATIC FILES /sbin
/home
Student Notes
The shaded directories in the diagram on the slide contain static data, while unshaded
directories in the diagram contain dynamic data. The sharable portion of the operating
system is located beneath /usr and /sbin. Only the operating system can install files into
these directories. Applications are located beneath /opt.
The directories /usr, /sbin, and the application subdirectories below /opt can be shared
among networked hosts. Therefore, they must not contain host-specific information. The
host-specific information is located in directories in the dynamic area of the file system.
General definitions for these directories are:
Directory Definition
/usr Sharable operating system commands, libraries, and documentation.
/sbin Minimum commands needed to boot the system and mount other file systems.

Module 4
/opt Applications.
/etc System configuration files. No longer contains executable files
/dev Device files
/var Dynamic information such as logs and spooler files (previously in /usr).
/mnt Local mounts
/tmp Operating system temporary files
/stand Kernel and boot loader
/home User directories
A Closer Look at /usr

The /usr directory contains the bulk of the operating system, including commands, libraries
and documentation. The /usr file system contains operating system files, such as executable
files and ASCII documentation.
The allowed subdirectories in /usr are defined below; no additional subdirectories should
be created.
Examples of files that live here are
/usr/bin Operating system user commands.
/usr/conf Kernel configuration.
/usr/contrib Unsupported contributed software.
/usr/lbin Back-ends to other commands
/usr/local User-contributed software.
/usr/newconfig Default operating system configuration data files.
/usr/sbin System administration commands.
/usr/share Architecture independent sharable files.
/usr/share/man Operating system man pages.
/usr/share/doc Release notes.

Module 4
A Closer Look at /var

The /var directory is for multipurpose log, temporary, transient, variable sized, and spool
files. The /var directory is extremely variable in size, hence the name. In general, any files
that an application or command creates at runtime, and that are not critical to the operation
of the system, should be placed in a directory that resides under /var. For example,
/var/adm will contain log files and other runtime-created files related to system
administration. /var will also contain variable size files like crontabs, and print and mail
spooling areas.
In general, files beneath /var are somewhat temporary. System administrators that wish to
free up disk space are likely to search the /var hierarchy for files that can be purged. Some
sites may choose not to make automatic backups of the /var directories.
Examples of files that reside here are
/var/adm Common administrative files and log files.
/var/adm/crash Kernel crash dumps.
/var/mail Incoming mail.
/var/opt/ Application-specific runtime files (e.g. logs, temporary files). Each

application will have its own directory.
/var/spool Spooled files used by subsystems such as lp, cron, software

distributor.
/var/tmp Temporary files generated by commands in the /usr hierarchy
A Closer Look at /var/adm

This directory hierarchy is used for common administrative files, logs, and databases. For
example, files generated by syslog(3C), files used by cron(1M), and kernel crash dumps will
be kept here and in subdirectories.
Examples of files that reside here are
/var/adm/crash Kernel crash dumps will be located in this directory.
/var/adm/cron Used for log files maintained by cron. cron is a subsystem that
allows you to schedule processes to run at a specific time or at
regular intervals.
/var/adm/sw Used for log files maintained by the Software Distributor.

Module 4
/var/adm/syslog System log files. Applications as well as the kernel can log
messages here. The syslogd daemon is responsible for writing
the log messages. The behavior of the syslogd daemon can be
customized with the/etc/syslog.conf file. The name of the
default log file is /var/adm/syslog/syslog.log. At boot
time this file is copied to OLDsyslog.log, and a new
syslog.log is started. The syslog.log file is an ASCII file.
/var/adm/sulog This file contains a history of all invocations of the switch user
command. sulog is an ASCII log file.
/var/adm/wtmp On an 11i v1 system, this file contains a history of successful

logins. This file is not ASCII. The last command is used to
display this information. The wtmp file will continue to grow and
should be trimmed by the administrator from time to time.
/var/adm/btmp On an 11i v1 system, this file contains a history of unsuccessful

logins. This file is not ASCII. The lastb command is used to
display this information. The btmp file will continue to grow and
/etc/utmp On an 11i v1 system, this file contains a record of all users logged
onto the system. This file is used by commands such as write
and who. This file is not an ASCII file and can not be directly
viewed.
/var/adm/wtmps On an 11i v2 system, this file contains a history of successful

logins. This file is not ASCII. The last command is used to
display this information. The wtmps file will continue to grow and
/var/adm/btmps On an 11i v2 system, this file contains a history of unsuccessful

logins. This file is not ASCII. The lastb command is used to
display this information. The btmps file will continue to grow and
/etc/utmps On an 11i v2 system, this file contains a record of all users logged
onto the system. This file is used by commands such as write
and who. This file is not an ASCII file and can not be directly
viewed.

Module 4
4–3. SLIDE: Application Directories
Application Directories
Static Dynamic
/opt/<application>/ /etc/opt/<appl>
bin lbin lib share newconfig /var/opt/<appl>
(Looks like /usr)
Student Notes
Each application will have its own subdirectory under /opt, /etc/opt, and /var/opt.
The sharable, or static, part of the application is self-contained in its own
/opt/application directory, which has the same hierarchy as the operating system
layout:
/opt/application/bin User commands.
/opt/application/share/man man pages.
/opt/application/lib Libraries.
/opt/application/lbin Back end commands.
/opt/application/newconfig Master copies of configuration files.
The application's host-specific log files are located under /var/opt/application, and
host-specific configuration files are located under /etc/opt/application.

Module 4
4–4. SLIDE: Commands to Help You Navigate
Commands to Help You Navigate
find Searches the file hierarchy

whereis Locates source, binaries, and man pages
which Locates an executable in your PATH
file Determines file type
strings Displays ASCII characters in binary files
Student Notes
As a system administrator, you will need to reference files in directories all over the HP-UX
file system. HP-UX offers several tools for finding the files and executable files you need to
perform administration tasks.
The find Command

The find command is a powerful tool for system administrators. It searches the file
hierarchy starting at a specified point and finds files that match the criteria you select. You
can search for files by name, owner, size, modification time, and so on. find also allows you
to execute a command with the files found used as an argument.
Examples
• Find all files belonging to the user greg:

# find / -user greg
• Find files in /tmp that have not been accessed in 7 days:

Module 4
# find /tmp -type f -atime +7

• Remove core files:
# find / -name core -exec rm –i {} \;
The whereis Command

The whereis command is useful when you receive "not found" error messages. It searches a
predefined list of directories. By default, whereis looks for source, binaries, and man pages.
You can limit the search to binary files by using the -b option.
Example
# whereis -b sam
sam: /usr/sbin/sam
The which Command

The which command is useful for determining which version of a command will be used.
Some commands have multiple homes. Which version you execute is determined by the
order of the directories in your PATH variable.
The file Command

The file command performs a series of tests on a file and attempts to classify it. It can be
useful for determining if a command is a shell script or a binary executable.
Examples
# file /sbin/shutdown
/sbin/shutdown: s800 shared executable
# file /etc/passwd
/etc/passwd: ascii text
The strings Command

The strings command is useful when trying to find information in a binary file. It will print
any printable characters in the file.

Module 4
4–5. LAB: HP-UX File System Hierarchy
Directions
Answer all the questions below.
1. Which of the following directories are dynamic?
/etc
/usr
/sbin
/dev
/tmp
2. Viewing a report on your disk space usage, you note that /usr, /var, and /opt are all
nearing 90% capacity. Which of these directories should you be most concerned about?
Why?
3. Match the directory with its contents:
1. /usr/share/man A. kernel, boot loader

2. /stand B. system configuration files
3. /var/adm C. shareable operating system commands
4. /etc D. man pages
5. /usr E. application directories
6. /opt F. common admin files and logs
4. Where would you expect to find the cp and rm OS user executables? See if you are
correct.
5. Where would you expect to find the smh, useradd, and userdel executables? See if
you are correct.

Module 4
6. The pre_init_rc utility executes in the early stages of the system start-up procedure to
check for file system corruption. Where would you expect to find this executable? See if
you are correct.
7. There is a system log file that maintains a record of system shutdowns. Where would you
expect to find the shutdown log file? See if you are correct.
8. In which directory would you expect to find the "hosts" configuration file, which contains
network host names and addresses? See if you are correct.
9. Though many utilities and daemons maintain independent log files, many daemons and
services write their errors and other messages to a log file called syslog.log. See if
you can find the path for this file, then check to see if any messages have been written to
the file in the last day.
10. Find all of the directories (if any) under /home that are owned by root.
11. (Optional) Find all the files under /tmp that haven't been accessed within the last day.
12. (Optional) Find all the files on your system that are greater than 10000 bytes in size. If
you needed to make some disk space available on your system, would it be safe to simply
remove these large files?

Module 4
4–6. LAB SOLUTIONS: HP-UX File System Hierarchy
Directions
Answer all the questions below.
1. Which of the following directories are dynamic?
/etc
/usr
/sbin
/dev
/tmp
Answer:
/etc
/dev
/tmp
2. Viewing a report on your disk space usage, you note that /usr, /var, and /opt are all
nearing 90% capacity. Which of these directories should you be most concerned about?
Why?
Answer:
/var deserves the most attention here because it is a dynamic file system that could
grow quite quickly in case of an error condition that creates entries in the system log files.
/usr and /opt are static file systems that are less likely to cause problems.
3. Match the directory with its contents:
1. /usr/share/man A. kernel, boot loader

2. /stand B. system configuration files
3. /var/adm C. shareable operating system commands
4. /etc D. man pages
5. /usr E. application directories
6. /opt F. common admin files and logs

Module 4
Answer:
1. /usr/share/man D. man pages

2. /stand A. kernel, boot loader
3. /var/adm F. common admin files and logs
4. /etc B. system configuration files
5. /usr C. shareable operating system commands
6. /opt E. application directories
4. Where would you expect to find the cp and rm OS user executables? See if you are
correct.
Answer:
Both are in /usr/bin, along with all the other user executables.
5. Where would you expect to find the smh, useradd, and userdel executables? See if
you are correct.
Answer:
All three are in /usr/sbin along with many other administrative utilities.
6. The pre_init_rc utility executes in the early stages of the system start-up procedure to
check for file system corruption. Where would you expect to find this executable? See if
you are correct.
Answer:
pre_init_rc is in the /sbin directory, along with other files used during the boot
process.
7. There is a system log file that maintains a record of system shutdowns. Where would you
expect to find the shutdown log file? See if you are correct.
Answer:
The full path name is /etc/shutdownlog (/var/adm/shutdownlog is a symbolic

link).
Most OS log files are kept in /var/adm.
8. In which directory would you expect to find the "hosts" configuration file, which contains
network host names and addresses? See if you are correct.
Answer:
The path name for the hosts file is /etc/hosts.

Module 4
9. Though many utilities and daemons maintain independent log files, many daemons and
services write their errors and other messages to a log file called syslog.log. See if
you can find the path for this file, then check to see if any messages have been written to
the file in the last day.
Answer:
# more /var/adm/syslog/syslog.log
10. Find all of the directories (if any) under /home that are owned by root.
Answer:
# find /home -user root
11. (Optional) Find all the files under /tmp that haven't been accessed within the last day.
Answer:
# find /tmp -atime +1 –type f
12. (Optional) Find all the files on your system that are greater than 10000 bytes in size. If
you needed to make some disk space available on your system, would it be safe to simply
remove these large files?
Answer:
# find / -size +10000c –type f
Before removing these files, be sure to investigate the files’ purpose.

Module 4

Module 5 — Configuring Hardware
Objectives
• Describe the major hardware components of an HP-UX system
• Describe the high-level features of HP’s current Integrity server products
• Describe the components of HP-UX legacy and Agile View hardware paths
• Describe the features of HP’s nPar, vPar, VM, and Secure Resource Partitions
• View a system’s hardware model and configuration with machinfo and model
• View a system’s peripheral devices and buses with ioscan and scsimgr
• View slots and interface cards with rad and olrad
• Add and replace interface cards with and without HP OL* functionality
• Add and remove pluggable and non-hot-pluggable devices

Module 5
Configuring Hardware
5–1. SLIDE: Hardware Components
Hardware Components
HP-UX systems have several hardware components:

• One or more Itanium single-, dual-, or quad-core CPUs for processing data
• One or more Cell Boards or Blades hosting CPU and memory
• One or more System/Local Bus Adapters that provide connectivity to expansion buses
• One or more PCI I/O expansion buses with slots for add-on Host Bus Adapters
• One or more Host Bus Adapter cards for connecting peripheral devices
• One or more Core I/O cards with built-in LAN, console, and boot disk connectivity
• An iLO / Management Processor to provide console access and system management
LAN
Blade Link / Crossbar
iLO / MP Serial
LBA PCI-X Bus SCSI Disk
Core I/O LAN DVD
CPUs Serial
SBA
Memory LBA PCI-X Bus FC HBA LUN
SAN LUN
Cell Boards
or Blades LBA PCI-X Bus FC HBA LUN
Student Notes
Every recent HP-UX system has several hardware components:
• One or more PA-RISC or Itanium single-, dual-, or quad-core CPUs for processing data.
• One or more Cell Boards or Blades hosting CPU and memory.
• One or more System/Local Bus Adapters that provide connectivity to expansion buses.
• One or more PCI I/O expansion buses with slots for add-on Host Bus Adapters.
• One or more Host Bus Adapter cards for connecting peripheral devices.
• One or more Core I/O cards with built-in LAN, console, and boot disk connectivity.
• An Integrated Lights Out / Management Processor (iLO/MP) card to provide local and
remote console access and system management functionality.
The slides that follow describe these components in detail.

Module 5
5–2. SLIDE: CPUs
CPUs
• HP’s current “Integrity” servers use Intel’s 64-bit EPIC architecture Itanium 2 processors
• HP’s older “hp9000” servers used HP’s proprietary 64-bit PARISC processors
• HP provides binary compatibility across processor types and generations
Current Itanium 2 Processors Clock Speeds

Intel® Itanium® Quad-Core 9300 Series “Tukwila” Processor 1.3GHz, 1.6GHz, 1.7
GHz
Intel® Itanium® Dual-Core 9200 Series “Montvale” Processor 1.4GHz or 1.6GHz
Intel® Itanium® Dual-Core 9100 Series “Montecito” Processor 1.4GHz or 1.6GHz
LAN
iLO / MP Serial
Core I/O LAN
CPUs Serial DVD
SBA
Cell Boards SAN LUN
LBA PCI-X Bus FC HBA LUN
or Blades
Student Notes
HP’s HP-UX systems utilize two different processor families.
The Itanium Processor Family (IPF®)

All of HP’s current HP-UX servers utilize Intel Itanium Processor Family (IPF) processors
developed by Intel. All HP servers that utilize the IPF processors carry the “HP Integrity”
brand name.
The Itanium 2 architecture uses a variety of techniques to increase parallelism — the ability
to execute multiple instructions during each machine cycle. Parallelism improves
performance because it allows multiple instructions to be executed simultaneously. The
Itanium 2 architecture is designed to make certain the processor can execute as many
instructions per cycle as possible.
A key to the high performance of the IPF processors is the design philosophy at the heart of
the processor, Explicitly Parallel Instruction Computing (EPIC). The
®
IPF is a registered trademark of the Intel Corporation

Module 5
EPIC philosophy is a major reason why Itanium 2 processors are different from other 64-bit
processors, providing much higher instruction-level parallelism without unacceptable
increases in hardware complexity. EPIC achieves such performance by placing the burden of
finding parallelism squarely on the compiler. Although processor hardware can extract a
limited sort of parallelism, the best approach is to let the compiler, which can see the whole
code stream, find the parallelism and make global optimizations. The compiler
communicates this parallelism explicitly to the processor hardware by creating a three-
instruction bundle with directions on how the instructions should be executed. The hardware
focuses almost entirely on executing the code as quickly as possible.
The EPIC architecture, together with several other architecture innovations, gives the IPF
processors a significant advantage over both IA32 and 64-bit RISC systems. As co-developer
of the Itanium 2 architecture, HP has been able to take the lead in bringing production-ready
Itanium 2 based servers to market.
As shown on the slide, Intel has already released several generations of Itanium 2 processors.
The latest generation of Itanium processors, the 9300 series “Tukwila” processor series
features four processor cores on a single chip die, which increases computing density and
delivers significant performance gains over earlier single- and dual-core processors. HP’s
newest systems utilize the 9300 series processor chips. Older models utilize the dual-core
9100 and 9200 series Itanium processors.
These multi-core processors are further enhanced by increasing the on-chip cache sizes in
each successive processor generation.
The PA-RISC Processor Family

Earlier model HP-UX systems utilized HP’s proprietary Precision Architecture RISC (PA-
RISC) processors. All recent HP servers that utilized PA-RISC carried the “HP 9000” brand
name.
PA-RISC used Reduced Instruction Set Computing (RISC) principles to provide high
performance, and high reliability. HP offered several iterations of its PA-RISC technology
over the years. The early PA7000 series of chips used a 32-bit architecture, while the newer
PA8000 series chips used a 64-bit architecture.
HP’s PA8800 and PA8900 processors are dual-core processors. A single PA8800 or PA8900
processor may contain one or two PARISC processor “cores”, thus allowing twice as many
processors in a single system as was previously possible. The hp9000 Superdome supported
up to 64 processor modules, a total of up to 128 PA8900 processor cores.
The PA8900 processor was the last processor in the PA-RISC family. HP stopped selling PA-
RISC servers at the end of 2008, but will support PA-RISC at least through 2013.
PA-RISC / Integrity Application Compatibility

Compatibility is an important feature that HP has always recognized and that HP customers
have come to expect.
For user space applications that utilize published APIs, HP:
• Maintains forward data, source, build environment, and binary compatibility across
all hardware platforms of the same architecture family (e.g. Intel ® Itanium ® or PA-

Module 5
RISC) which are supported by the same version of HP-UX;
• Provides forward data, source, build environment, and binary compatibility across
HP-UX release versions and updates on HP 9000 servers and Integrity servers on their
respective architectures. This is true for 32-bit or 64-bit applications on either
architecture family;
• Delivers new features and improved performance with each new HP-UX release.
Binary compatibility across operating system releases applies to legacy features
(features that were present in the earlier release). There are some instances, however,
where applications may be required to recompile in order to use or leverage a new
feature.
See the HP-UX release notes for information on new features that may require changes to
applications.
NOTE: This binary compatibility does not apply to kernel-intrusive

applications or applications that rely on proprietary data structures
inside HP-UX.
Although most “well-behaved” PA-RISC binaries execute successfully on an Integrity system,

the performance of a PA-RISC application running in compatibility mode may be less than
that of the same application recompiled and running in native mode. PA-RISC applications
that are largely interactive or I/O intensive should experience little to no noticeable
degradation in performance, while those that perform heavy computation may run noticeably
slower on an Integrity system than on a recent PA-RISC system. HP recommends
recompilation for all applications and libraries where performance is a concern.
Additionally, there is complete data compatibility between the HP-UX 11i releases for PA-
RISC and Itanium-based systems. No data conversion is required when transferring data
between releases of HP-UX 11i on PA-RISC and Integrity servers.
For a more complete discussion of HP-UX compatibility, see the “HP-UX 11i compatibility for
HP Integrity and HP 9000 servers” white paper at
http://www.hp.com/go/hpux11icompatibility.
HP Integrity servers with Intel Itanium 2 processors offer the best HP-UX performance,
scalability, and investment protection available. HP encourages current PA-RISC customers
to consider upgrading their systems to Itanium. Consult your sales representative for details.
Determining your Processor Type

On 11i v1 and v2 systems, you can determine your processor type via the SAM system
properties screen.
# sam -> Performance Monitors -> System Properties -> Processor
On Integrity systems, you can determine your processor type and configuration via the
machinfo command.
# machinfo
CPU info:

Module 5
2 Intel(R) Itanium(R) Processor 9340s (1.6 GHz, 20 MB)

4.79 GT/s QPI, CPU version E0
8 logical processors (4 per socket)
Memory: 32670 MB (31.9 GB)
Firmware info:
Firmware revision: 01.02
FP SWA driver revision: 1.18
IPMI is supported on this system.
BMC firmware revision: 1.00
Platform info:
Model: "ia64 hp Integrity BL860c i2"
Machine ID number: 669ab3af-3d4c-11df-abc1-1a4b5386cd07
Machine serial number: USE008XX06
OS info:
Nodename: bl860-1
Release: HP-UX B.11.31
Version: U (unlimited-user license)
Machine: ia64
ID Number: 1721414575
vmunix _release_version:
@(#) $Revision: vmunix: B.11.31_LR FLAVOR=perf
For More Information

For more information on HP’s Itanium strategy, visit our IPF home page at
http://www.hp.com/go/itanium/.
To learn more about HP’s PA-RISC to Integrity migration program, visit

http://www.hp.com/go/hp9000.

Module 5
5–3. SLIDE: Cell Boards, Blades, Crossbars, and Blade

Links
Cell Boards, Blades, Crossbars, and Blade Links
On HP’s mid-range and high-end servers, and on newer blade servers …

• Each system is comprised of one or more cell boards or blades
• Each cell board or blade contains a portion of the system’s memory and CPU resources
• All cell boards or blades are interconnected via a low latency crossbar or blade link
• Result: Any processor core can access resources on any blade or cell board
LAN
iLO / MP
Serial
Core I/O LAN DVD
CPUs Serial
SBA
Cell Boards SAN LUN
Student Notes
On HP’s mid-range and high-end servers, and on newer blade servers, each system is
comprised of one or more cell boards or blades. Each cell board or blade contains a portion
of the system’s memory and CPU resources.
All of the system’s cell boards or blades are interconnected via a low latency “crossbar” (on
mid-range and high end servers) or blade link (on the blade servers).
HP’s crossbar and blade link technologies ensure that any processor core on a system can
access resources on any other blade or cell board on that same system.

Module 5
The diagram below shows the blade link used to interconnect foundation blades in HP’s
newer Integrity blade servers:
The diagram below shows the HP sx2000 crossbar technology used to interconnect cell
boards in HP’s cell-based midrange and high-end Superdome servers:

Module 5
The diagram below shows the HP sx3000 crossbar technology used to interconnect
Superdome 2 blades on the new Superdome 2 server:

Module 5
5–4. SLIDE: SBAs, LBAs, and PCI Expansion Buses
SBAs, LBAs, and I/O Expansion Buses
• System and Local Bus Adapters provide connectivity to I/O expansion buses
• I/O expansion buses provide one or more slots for device adapter cards
• HP supports PCI, PCI-X, and PCI-E bus types, and slot speeds up to ~2GB/sec
• HP OL* functionality on some servers facilitates adding/removing cards online
• Dedicated buses minimize downtime and maximize performance
LAN
iLO / MP
Serial
Core I/O LAN DVD
CPUs Serial
SBA
Cell Boards SAN LUN
Student Notes
Every cell, system board, or blade has a System Bus Adapter (SBA) that provides
connectivity between the system’s processors and the I/O expansion buses.
The SBA connects to one or more Local Bus Adapters (LBAs) on the system’s I/O backplane
via a high-speed communications channel known as a “rope”. Some LBAs have a single rope
connection to the SBA. Other LBAs utilize two ropes to the SBA for greater bandwidth.
Each LBA provides an I/O bus to support one or more interface adapters or Host Bus
Adapters (HBAs).
PCI, PCI-X, and PCI-Express Expansion Buses

HP’s current servers utilize Peripheral Component Interconnect (PCI)-based I/O buses. PCI
is a bus architecture that provides high-speed connectivity to and between interface adapters.
PCI was developed by Intel, but has become an industry standard that is used on many
platforms.

Module 5
Since it was first introduced, the PCI standard has been enhanced several times to
accommodate the greater bandwidth and shorter response times demanded from the
input/output (I/O) subsystems of enterprise computers. The table below lists the PCI bus
types available on recent Integrity servers.
Slot Type Bus Width Bus Frequency Bandwidth

PCI 32 bits 33.3 MHz 133 MB/s
PCI 2x / Turbo 64 bits 33.3 MHz 266 MB/s
PCI-X 66 64 bits 66.6 MHz 0.5 GB/s
PCI-X 133 64 bits 133 MHz 1.1 GB/s
PCI-X 266 64 bits 266 MHz 2.1 GB/s
PCI-Express 64 bits 266 MHz 2.6 GB/s
The architecture diagram below shows the bus types provided on an Integrity rx6600 entry-
class server. Model-specific technical white papers on HP’s
http://www.hp.com/go/servers website provide similar technical details for other
server models, too.
Expansion Slots, I/O Chassis, I/O Expansion Enclosures, and Mezzanine

Cards
Rackmount entry-class and mid-range servers have card slots on the backplane of the server
which host the expansion cards.

Module 5
Superdome servers host expansion cards in one or more I/O chassis accessible from the front
and rear of the server.
Superdome 2 servers have no internal expansion card slots. Rather, Superdome 2 servers
host expansion cards in one or more external I/O expansion enclosures.
HP Integrity blade server administrators can add additional interfaces via the “mezzanine”
expansion card slots located directly on the server blades.
Slides later in the module describe each of these expansion solutions in greater detail.
Learning More about Your Server’s Expansion Buses

To learn more about the expansion slots and cards available for your server, review your
model’s QuickSpecs on http://www.hp.com/go/servers.

Module 5
5–5. SLIDE: iLO / MP Cards
iLO / MP Cards
• All current HP servers support an Integrated Lights Out Management Processor
• The iLO / MP provides:
− Local console access via a local serial port
− Remote console access via modem or via telnet, HTTPS*, or SSH* network services
− Hardware monitoring and logging
− Power management and control
* Not supported on all models
LAN
iLO / MP Serial
Core I/O LAN DVD
CPUs Serial
SBA
Cell Boards SAN LUN
Student Notes
The next few slides discuss some of the cards and adapters that occupy PCI, PCI-X, and PCI-
Express buses.
All of HP’s recent server models support an Integrated Lights Out / Management Processor
(iLO/MP). The iLO/MP provides several important features:
• Local console access via a local serial port: Attach an ASCII terminal to the MP Serial port
to install, update, boot, and reboot.
• Remote console access via modem or via telnet, HTTPS, or SSH network services:
Remote administrators can use these iLO/MP features to remotely install, update, boot,
reboot, and perform other administration tasks.
• Hardware monitoring and logging: The iLO/MP captures system hardware level
diagnostics and system messages.
• Power management and control: Use the iLO/MP to view power status and power on/off
system components.

Module 5
• And much more... The iLO/MP chapter elsewhere in this course describes these and
many other iLO/MP features in detail.

Module 5
5–6. SLIDE: Core I/O Cards
Core I/O Cards

• All HP servers include at least one Core I/O card or equivalent built-in interfaces
Common Core I/O Functions Typical Usage

Parallel SCSI Boot disk, tape, and DVD connectivity
Serial Attach SCSI Boot disk connectivity
10/100/1000BaseT adapter LAN connectivity
Serial Serial terminal/modem connectivity
USB Keyboard & mouse
Graphics/VGA VGA monitor
Audio Speakers & Headphones
LAN
iLO / MP Serial
Core I/O LAN DVD
CPUs Serial
SBA
SAN LUN
Cell Boards
or Blades
Student Notes
All Integrity servers include a Core I/O card or equivalent built-in interfaces that provide
basic server connectivity. Cell-based servers may have multiple Core I/O cards to support
node partitioning. Core I/O configurations vary, but typically include some combination of
the following:
• One or more Parallel Small Computer System Interface (SCSI) interfaces for connecting
the internal disk(s), tape drive, and optional DVD.
• A Serial Attach SCSI (SAS) interface, for connecting the internal disk(s). SAS provides
greater expandability and better performance than parallel SCSI technology. Newer
systems include SAS rather than parallel SCSI interfaces.
• One or two 10/100/1000BaseT interfaces, for connecting the system to a Local Area
Network. Newer blade servers include standard, built-in “LAN on Motherboard” (LOM)
dual-port 10Gb Ethernet interfaces.
• One or more serial ports, for connecting a terminal, modem, or serial printer.

Module 5
• One or more USB ports, for connecting a local keyboard and/or mouse.
• A graphics/VGA adapter for connecting a local VGA monitor. This feature is only
available on some entry-class servers.
• Audio ports, for connecting a headphone, microphone, and/or speakers. This feature is
only available on some entry-class servers.
To learn more about your server’s Core I/O features, review your model’s QuickSpecs on
http://www.hp.com/go/servers.

Module 5
5–7. SLIDE: Internal Disks, Tapes, and DVDs
Internal Disks, Tapes, and DVDs

• Blade and rackmount servers support two or more internal hot-plug SCSI or SAS disks
• Rackmount servers also support one or more internal hot-plug DVD or DDS drives
• Most server models support an optional SmartArray controller
– SmartArray controller provides RAID 1, 5, and 6 functionality
LAN
iLO / MP Serial
Core I/O LAN DVD
CPUs Serial
SBA
SAN LUN
Cell Boards
or Blades
Student Notes
The Core I/O / integrated parallel SCSI and SAS interfaces are commonly used to connect
internal mass storage devices.
Entry-class, mid-range, and Integrity blade server models support at least two internal SAS or
SCSI disks. Entry-class servers support at least one internal DVD drive; some support one or
more optional internal DDS tape drives, too.
HP’s high-end Superdome and Superdome 2 servers do not include any internal disk or tape
drives; they rely on external devices or devices installed in an adjacent I/O expansion cabinet
On all current systems, the internal disk and tape devices are “hot-pluggable”, enabling the
administrator to service the devices while the server remains running in most cases. See
your server’s user service manual for details.
Many models now support HP’s SmartArray controller cards. The SCSI and SAS SmartArray
cards provide hardware-based mirroring functionality using the server’s internal disks. This
useful feature ensures that the system continues running even if an internal disk fails.
To learn more about your server’s internal mass storage options, review your model’s
QuickSpecs on http://www.hp.com/go/servers.

Module 5
5–8. SLIDE: Interface Adapter Cards
Interface Adapter Cards

Interface Adapters provide connectivity to additional devices
Interface Adapter Type Typical Usage

Parallel SCSI Host Bus Adapters Disks, tapes, CDROMs, DVDs
Serial Attached SCSI Host Bus Adapters Disks, tapes, CDROMs, DVDs
Smart Array Adapter Disks
1Gb, 2Gb, 4Gb Fiber Channel Host Bus Adapters Disk arrays, tape libraries
10Mb, 1Gb, 10Gb, and FLEX10 Ethernet Adapters LAN connectivity
ATM, X.25 Adapters WAN connectivity
Multi-function Adapters Fiber Channel + Ethernet
Graphics/VGA Adapters VGA monitors
Audio Adapters Headphone/Microphone/Speakers
LAN
iLO / MP Serial
Core I/O LAN DVD
CPUs Serial
SBA
Cell Boards SAN LUN
Student Notes
The Core I/O card provides basic LAN and storage connectivity. Adding additional interface
adapter cards makes it possible to connect to additional LANs, SANs, and external devices.
The slide lists some of the common interface adapter card types commonly found on HP-UX
systems today.
Supported cards vary by server model and OS type and version; see your model’s QuickSpecs
on http://www.hp.com/go/servers for details. If you plan to use the interface card to
boot from a SAN device or a network-based Ignite-UX install server, check the QuickSpecs to
verify that your interface card provides boot support for your OS version.
Online Replacement, Addition, Deletion (Interface Card OL*)

Some of the entry-class servers, and all of the current mid-range and high-end servers, now
support HP’s Interface Card OL* functionality, which makes it possible to add and replace
(11i v1, v2, and v3), or remove (11i v3 only) interface cards without shutting down the
system. If a card needs to be replaced, and the card isn’t currently in use, the administrator
can power down the card slot and replace the card while the OS and other slots remain
functional.

Module 5
To determine if your server supports OL*, execute rad –q (11i v1) or olrad –q (11i v2 and
v3). If the command yields an error message, your server doesn’t support OL*. The olrad
output below suggests that three card slots on this server are unoccupied. Five slots are
occupied and support OL* functionality.
# olrad -q
Driver(s) Capable
Slot Path Bus Max Spd Pwr Occu Susp OLAR OLD Max Mode
Num Spd Mode
0-0-1-1 1/0/8/1 396 133 133 Off No N/A N/A N/A PCI-X PCI-X
0-0-1-4 1/0/14/1 483 266 66 On Yes No Yes Yes PCI-X PCI
0-0-1-6 1/0/4/1 340 266 266 On Yes No Yes Yes PCI-X PCI-X
In order to add/replace a card online, both the server’s card slot and that interface card’s
driver must support OL*. To determine if an interface card’s driver supports OL*, check the
documentation accompanying the card.

Module 5
5–9. SLIDE: Disk Arrays and LUNs
Disk Arrays and LUNs

• Most HP-UX servers today store application and user data on external disk arrays
• Storage in an array is subdivided into Logical Units (LUNs)
− Each LUN represents a virtual partition of disk space
− The array assigns each LUN a globally unique WW Identifier (WWID)
− From the operating system’s perspective, a LUN is just another disk
− LUNs provide performance and high availability via RAID technology

SAN LUN
CPUs LUN
SBA LBA PCI-X Bus FC HBA
Memory
LAN
Cell Boards LBA Core I/O Serial
SCSI Disk
or Blades PCI-X Bus
DVD
iLO / MP LAN
Serial
Student Notes
Disk Arrays
A disk array is a storage system consisting of multiple disk drive mechanisms managed by an
array controller that makes the resulting disk space available to one or more hosts. As the
volume of data managed on HP-UX systems has increased from megabytes, to gigabytes, to
terabytes, disk arrays have become increasingly popular. Though many administrators still
choose to configure internal disks as boot disks, most application and user data today is
stored on external disk arrays.
LUNs
Disk arrays often have dozens, or even hundreds, of disk devices. Management software
running on the array enables the array administrator to subdivide the array’s disk space into
one, two, or even hundreds of “Logical Units” (LUNs), or virtual disks.

Module 5
LUNs and WWIDs

The disk array automatically assigns every LUN a globally unique, 64-bit WW Identifier
(WWID) that is typically displayed in hexadecimal form. Array administrators also assign
each LUN an easier to remember LUN ID number. When troubleshooting issues with array
administrators, you may be asked to provide a LUN’s WWID or LUN ID. In 11i v3,
administrators can easily view both numbers via the scsimgr command. A later slide in the
chapter discusses the scsimgr command in detail.
# scsimgr get_attr -a wwid -H 64000/0xfa00/0x4

name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =
# scsimgr get_attr \
-a lunid \
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
name = lunid
current =0x4001000000000000 (LUN # 1, Flat Space Addressing)
default =
saved =
11i v1 and v2 administrators must use utilities supplied by the array vendor to obtain a LUN’s
WWID and LUN ID. 11i v1 and v2 servers accessing HP disk arrays via HP’s SecurePath
software product can view WWIDs and other LUN attributes via the spmgr command. 11i v1
and v2 servers accessing HP disk arrays via HP’s AutoPath software product can view
WWIDs and other LUN attributes via the autopath command.
LUNs and HP-UX

HP-UX sees each LUN as a disk device. The same commands used to configure and manage a
simple internal SCSI disk can also be used to manage a disk array LUN. Note, however, that
HP-UX has no visibility to the underlying disks within the array that comprise the LUN.
LUN RAID Levels

The array administrator assigns each LUN a RAID level. This “RAID Level” determines the
level of performance and reliability offered by the LUN.
RAID (Redundant Arrays of Independent Disks or Redundant Arrays of Inexpensive Disks) is

a technology used to efficiently and redundantly manage data spread across multiple
independent disks. By distributing across multiple disks, I/O operations can overlap in a
balanced way, improving performance. In most cases, RAID solutions also maintain
redundant data on multiple disks to increase fault tolerance.
Many different RAID technologies have been proposed over the years. Each level specifies a
different disk array configuration and data protection method, and each provides a different
level of reliability and performance. Only a few of these configurations are typically
implemented in today’s arrays:

Module 5
• RAID 0: Striping
• RAID 1: Mirroring
• RAID 1+0: Mirroring+Striping
• RAID 3: Striping with parity
• RAID 5DP: Striping with distributed parity
• RAID 5DP: Striping with redundant distributed parity
Array Benefits
Disk arrays offer several advantages over traditional disk storage:
• Improved scalability: Many disk arrays provide hundreds of terabytes of disk
space.
• Improved data availability: Disk arrays have multiple redundant components to

ensure that data remains available even when a disk,
controller, or power supply fails. When disks do fail,
the array management software makes it very easy to
replace the failed component without causing
downtime.
• Improved performance: Disk arrays provide a variety of striping options to

ensure load balancing across multiple disks. Most disk
arrays include very large caches, too, so I/O requests
can be serviced with very low latency.
• Improved flexibility: Disk arrays make it very easy to make additional space
available when necessary, and re-allocate space that is
underutilized.
• Improved manageability Today’s arrays include sophisticated management

software to simplify monitoring, performance tuning,
and troubleshooting.
For Further Study

To learn more about RAID technology, attend HP Education’s Accelerated SAN Essentials
(UC434S), Managing HP StorageWorks Enterprise Virtual Array (UC420S), or HP
StorageWorks XP Disk Array (H6773S) courses.

Module 5
5–10. SLIDE: SANs and Multipathing
SANs and Multipathing

• A Storage Area Network (SAN) is a special purpose network of servers, arrays, tape
libraries, and SAN switches that allow administrators to more flexibly configure and
manage disk and tape resources
• Most servers and arrays connect to the SAN via multiple HBAs to provide redundancy
and high availability
− Result: Each LUN may be accessed by multiple paths through the SAN
− 11i v1 and v2 rely on the volume managers to manage multi-pathing
− 11i v3 implements a new mass storage stack with “native” OS multi-pathing
LUN x 4 paths
LUN x 4 paths
LUN x 4 paths
LUN
SAN LUN
server w/ SAN array w/ LUN
2 HBAs switches 2 controllers
Student Notes
SANs
For even greater flexibility, arrays are oftentimes connected to multiple hosts via a Storage
Area Network (SAN). A Storage Area Network (SAN) is a special purpose network of servers
and storage devices that allows administrators to more flexibly configure and manage disk
and tape resources. Array administrators can control which LUNs are presented to each host
on the SAN.
Multipathing
In high-availability environments, administrators often configure multiple physical paths to a
disk array. Each path utilizes a unique path from the server’s Host Bus Adapter (HBA),
through the SAN, to an array controller. Depending on the complexity of your SAN, you may
have two, four, eight, or even more paths to each LUN.
Redundant links ensure that if an HBA or array controller fails the server can maintain
connectivity to the array LUNs via the remaining link(s). Utilizing multiple paths to an array

Module 5
concurrently may provide performance benefits, too: if any single path to a LUN becomes
overloaded, I/O can be redirected down one of the other paths.
In 11i v1 and v2, the kernel isn’t multi-path aware. It views each path to a multi-pathed LUN
as an independent device, and relies on LVM Physical Volume Links (PV Links), VxVM
Dynamic Multipathing (DMP), or path management software from the array vendor to
determine which paths are redundant and how those paths should be used.
Many disk array vendors offer additional software that can be added to the 11i v1 or v2 kernel
to provide array-specific multi-pathing capabilities independent of LVM or VxVM. HP’s
Storageworks Secure Path product provides this functionality for HP’s XP, EVA, and VA disk
arrays. The Power Path product from EMC provides similar functionality for EMC disk
arrays. To learn more about HP Storageworks Secure Path, visit http://www.hp.com.
11i v3 implements a new mass storage stack that provides “native” OS multi-pathing. In the
new mass storage stack, the kernel automatically recognizes, configures, and manages
redundant LUN paths. LVM PV Links and third party path management software are no
longer required.

Module 5
5–11. SLIDE: Partitioning Overview
Partitioning Overview
HP partitioning technologies allow multiple applications to run on a single server with
dedicated CPU/memory/IO resources that can be flexibly reallocated as necessary
Without Partitioning: With Partitioning:

• Each app runs on a separate server • Apps run in separate partitions on a shared server
• No resource sharing • Resources can be reallocated as necessary
Partition #1
Partition #1 Transaction
Transaction Processing
Processing
CPU/memory/IO
Partition #2
Batch Partition #2
Processing Batch
Processing
Student Notes
In the past, most organizations deployed a dedicated server for each application. Allocating a
dedicated server for each application guaranteed that the application didn’t compete for
resources with other applications, and ensured that hardware, software, or security issues on
the server would only impact one application.
Unfortunately, this approach generally resulted in over-provisioning. Most applications

experience peak usage periods and low usage periods. Administrators purchase systems to
accommodate the peaks, but find that system resources are underutilized during low usage
periods. If every application runs on a separate server, the only way to reallocate CPU,
memory, and other resources from an under-utilized system to an overtaxed system is to
shutdown both machines and physically move components between the system chassis.
HP partitioning technologies allow multiple applications to run on a single server with

dedicated CPU/memory/IO resources that can be flexibly reallocated as necessary.
Partitioning also provides fault isolation, ensuring that application/OS/hardware errors in one
partition don’t impact workloads running in other partitions on the same server1.
1
The level of fault isolation provided varies, depending on the partitioning technology selected.

Module 5
5–12. SLIDE: nPar, vPar, VM, and Secure Resource Partition

Overview
nPar, vPar, VM, & Secure Resource Partition Overview

HP offers a variety of flexible partitioning technologies
Feature nPars vPars VMs SRPs
CPU Granularity Cell/Blade CPU Sub-CPU CPU %age
I/O Granularity I/O chassis LBA Sub-LBA Bandwidth %age
HW Fault Isolation? Yes No No No
OS Fault Isolation? Yes Yes Yes No
Resource Isolation? Yes Yes Yes Yes
Cell-Based, Cell-Based,
Superdome, & Superdome, &
All IA All IA/PA
HW Support Superdome 2 Superdome 2
Servers Servers
IA/PA IA/PA
Servers Servers
HPUX, HPUX,
Windows, Windows,
OS Support HPUX HPUX
Linux, Linux,
OpenVMS OpenVMS
Student Notes
HP offers a variety of partitioning solutions.
Node Partitions (nPars)

Mid-range, Superdome, and Superdome 2 server administrators can improve both utilization
and flexibility by configuring multiple electrically isolated hardware-based nPar partitions on
a server, each containing one or more cell boards and the cell boards’ associated CPU,
memory, and I/O resources.
nPar Advantages: nPars allow the administrator to run multiple OS instances on a server, and
move cell boards between nPars to balance utilization, while still guaranteeing hardware and
OS fault isolation. Applications running in one nPar can’t access resources in another nPar.
An OS panic, hardware failure, or security breach in one nPar has no impact on the other
nPars.
nPar Disadvantages: In comparison to some of the other partitioning solutions below, nPars
provide a bit less flexibility since they only allow blade- / cell-level partition granularity.

Module 5
nPar Support: nPars are only supported on midrange, Superdome, and Superdome 2 servers.
On Integrity servers, nPars support HP-UX, Windows, Linux, and OpenVMS operating
systems. Servers with multiple nPars can run a different OS in each nPar.
Virtual Partitions (vPars)

Virtual Partitions (vPars) enable administrators to carve a server or nPar into one or more
vPar partitions, each running a separate instance of the operating system.
vPar Advantages: vPars provide greater flexibility than nPars, since each vPar can be
assigned individual processors, individual LBAs, and a percentage of physical memory.
Applications running in one vPar can’t access resources in another vPar, and an OS panic in
one vPar has no impact on other vPars. Since individual hardware components are assigned
to each vPar, vPars have little impact on an application’s performance. vPars allow the
administrator to move CPUs between vPars very easily. The latest version of vPars also
supports dynamic memory migration between vPars.
vPar Disadvantages: Unlike nPars, vPars don’t provide hardware fault isolation. When a cell
board fails, multiple vPars on the cell board may panic as a result.
vPar Support: vPars are supported on all current midrange, Superdome, and Superdome 2
servers. However, not all models support the latest version of the vPars software, and not all
interface cards provide vPar support. See the vPars documentation for details. vPars only
support HP-UX.
Integrity Virtual Machines (VMs)

Integrity VMs enable administrators to carve a server or nPar into one or more Virtual
Machine “guests”, each running a separate instance of the operating system.
VM Advantages: VM guests provide fully virtualized hardware, allowing the administrator to

allocate resources at the sub-CPU level and share interface cards between VMs. VMs provide
software fault isolation. OS problems on one VM should have no impact on other VM guests.
VM CPU and memory entitlements guarantee each VM a minimum amount of memory and
CPU resources; remaining resources may be shared by multiple VMs, potentially improving
utilization. VM guests can also be moved between physical servers, often without modifying
the applications inside the VM! Moving a VM does require stopping and restarting the OS
running inside the VM.
VM Disadvantages: VMs provide software, but not hardware fault isolation. Also, VMs incur
greater performance penalties than vPars, particularly for I/O bound applications.
Support: VMs are supported on all Integrity servers – including entry class systems and
Integrity blades. At the time this book went to press, Integrity VMs supported HP-UX,
Windows, and Linux. OpenVMS will eventually be supported as a guest OS. Check the
current QuickSpecs for the latest support list. vPars and VMs are mutually incompatible
within an nPar, though a server with multiple nPars can run vPars in one nPar and VMs in the
other.

Module 5
Secure Resource Partitions

Secure Resource Partitions enable the administrator to run multiple applications within a
single nPar or vPar OS instance, while still providing each application guaranteed CPU,
memory, and I/O resources. Secure Resource Partitions utilize several HP-UX products:
• Process Resource Manager (PRM) enforces minimum and maximum CPU, memory, and
disk I/O bandwidth entitlements for each application. The administrator controls what
percentage of system resources each Secure Resource Partition can utilize.
• Processor Sets (PSETS) enable the administrator to assign one or more dedicated
processors to an application, and reallocate PSET assignments when necessary.
• Security Containment, a product introduced in 11i v2, facilitates the creation of security
“compartments” that limit the network interfaces, sockets, files, directories, and kernel
functions available to an application. Configuring each application in a separate security
compartment ensures that applications can not intentionally or unintentionally interfere
with other applications’ resources.
• IPFilter, an open source firewall solution, restricts network traffic flowing in and out of
the SRP’s network interfaces.
• IPSec, a standards-based HP product that can optionally encrypt and authenticate

network traffic flowing in and out of the SRP’s network interfaces.
• Secure Resource Partitions, an intuitive CLI / menu interface that automatically integrates
and manages the components described above.
Secure Resource Partition Advantages: Secure Resource Partitions enforce minimum and
maximum CPU, memory, and disk I/O bandwidth entitlements for each application, and
ensure that each application can only access its own files, directories, network interfaces and
other resources.
Secure Resource Partition Disadvantages: Secure Resource Partitions guarantee resource

entitlements, but don’t provide hardware or OS fault isolation. An OS panic or hardware
failure causes all Secure Resource Partitions in the OS instance to fail.
Secure Resource Partition Support: PRM and PSETS are supported on all HP-UX 11i v1, v2,
and v3 servers. Security containment is only supported on 11i v2 and v3. The Secure
Resource Partitions CLI/TUI interface is only supported on 11i v3.

Module 5
5–13. SLIDE: Part 2: System Types
Configuring
Hardware:
Part 2: System Types
Student Notes

Module 5
5–14. SLIDE: Integrity Server Overview
Integrity Server Overview

• HP currently offers a wide variety of Itanium-based “Integrity” servers
− Traditionally, Integrity servers were rackmount / cell-based systems
− Most newer Integrity servers are blade-based servers
• The table below provides an overview of the current Integrity server models
• The following slides describe these architectures in greater detail
Rackmount & Cell-Based Integrity Servers Blade-Based Integrity Servers
High-End Cell-Based Server: High-End Server:

HP Integrity Superdome (64p/128c) HP Integrity Superdome 2 (32p/128c) New!
Mid-Range Cell-Based Servers: Blade Servers:

HP Integrity rx8640 (16p/32c) Integrity BL890c i2 Blades (8p/32c) New!
HP Integrity rx7640 (8p/16c) Integrity BL870c i2 Blades (4p/16c) New!
Integrity BL860c i2 Blades (2p/8c) New!
Entry-Class rackmount Servers: Integrity BL870c Blades (4p/8c)
HP Integrity rx2800 i2 (2p/8c) New! Integrity BL860c Blades (2p/4c)
HP Integrity rx6600 (4p/8c)
NOTE: HP regularly introduces new system models and configurations.

For the latest information, and more details, see http://www.hp.com/go/integrity.
Student Notes
HP offers a wide variety of Integrity servers, from dual processor entry-class servers, to high-
end servers with that can accommodate several thousand concurrent users.
Rack-Mount and Cell-Based Integrity Servers
HP’s entry-class servers are self-contained, rackmounted servers. Each server chassis
includes processors and memory, as well as power, cooling, management components. HP’s
largest entry-class servers support up to eight cores.
HP’s mid-range servers are self-contained, rackmounted servers that utilize a cell-based
architecture. Each server chassis contains one or more cell boards, as well as power,
cooling, and management components. HP’s largest mid-range, rack-mounted server
supports up to 32 cores.
HP’s entry-class and mid-range rackmount servers all have model names that begin with HP
Integrity rx____, in which the “rx” is followed by a four digit number. In general, servers with

Module 5
higher model numbers (e.g.: rx7640) offer greater power and expandability than servers with
lower model numbers (e.g.: rx2660).
HP’s high-end Integrity Superdome server also utilizes a cell-based architecture. The current
cell-based Superdome model supports up to 128 cores.
Blade-Based Integrity Servers
Many organizations today deploy HP’s blade server solutions rather than rackmounted
servers.
A blade server is a compact, high-density server that has its own CPU and memory, but that
shares networking cables, switches, power, and storage with other blade servers in a
specially designed HP BladeSystem enclosure.
All of the components in the enclosure connect to a common midplane, eliminating the need
for power, LAN, and SAN cables to individual server blades.
Blade solutions often provide greater flexibility, faster server deployments, better
manageability, less downtime, less power consumption, and lower costs than similar rack-
mounted solutions.
The slide notes that HP currently offers a variety of Integrity blade servers with as many as 32
processor cores.
HP’s new high-end HP Integrity Superdome 2 server leverages HP BladeSystem technology,

too. The HP Integrity Superdome 2 supports up to 128 cores.
hp9000 Servers
In the past, HP offered a variety of PA-RISC based HP-UX server solutions. HP no longer
sells new PA-RISC servers, but does continue to support existing PA-RISC servers.
Upgrade Paths
Customers often find that as their business grows, their transaction volumes demand greater
capacity and performance. Hewlett-Packard provides a comprehensive upgrade program
that protects customers' investments in hardware, software and training. The upgrade
program includes simple board upgrades, system swaps with aggressive trade-in credits, and
100 percent return credit on most software upgrades.
Utility Pricing Solutions

HP offers a number of practical, cost-effective pricing solutions to meet the needs of
customers with growing or fluctuating demand. To learn more about our “Instant Capacity”
and “Pay Per Use” solutions, visit http://www.hp.com/go/icap.
Determining your System Model Type

You can determine your system’s model type and number via the
model command.

Module 5
# model
ia64 hp server rx2660
OS Version Support
Each HP-UX release only supports certain server models. To determine which hardware
models support each operating system release, see
http://www.hp.com/go/hpuxservermatrix.
For Further Information

This slide is just an overview. Upcoming slides provide a bit more detail about the server
categories.
Hardware products change frequently. For the most current information on HP’s hardware
products, visit HP’s product website at http://www.hp.com/go/integrity, or contact
your local HP sales representative.

Module 5
5–15. SLIDE: Entry-Class Rackmount Server Overview
Entry-Class Rackmount Server Overview

HP’s entry-class rackmount Integrity servers are ideal for customers who require flexibility, high-
availability, and scalability up to eight processor cores in a traditional rackmount form factor;
administrators often deploy entry-class rackmount servers in smaller branch office locations
Common Features:
• Integrated LAN interface
• Integrated Management Processor
• Redundant hot-swap power supplies
• Redundant hot-swap cooling
HP Integrity rx2800 i2 HP Integrity rx2660 HP Integrity rx3600 HP Integrity rx6600

• 2 rack units • 2 rack units • 4 rack units • 7 rack units
• 2 processors • 2 processors • 4 processors • 4 processors
• 8 cores • 4 cores • 8 cores • 8 cores
• Other features TBA • 8 DIMMS • 24 DIMMs • 48 DIMMs
• 8 internal disks • 8 internal disks • 16 internal disks
• 3 PCIe/PCI-X slots • 8 PCIe/PCI-X slots • 8 PCIe/PCI-X slots
Student Notes
HP’s entry-class Integrity servers are ideal for customers who require flexibility, high-
availability, and scalability up to eight processor cores in a traditional rackmount form factor.
Most are also available in a pedestal mount for deskside use. Administrators often deploy
entry-class servers in smaller branch office locations.
The entry-class servers offer one to four processor sockets. Most models support dual-core
Itanium processors. The rx2800 i2 supports a quad-core Itanium processor.
PCI-X and PCI Express expansion slots allow the administrator to easily add additional LAN
and mass storage interface cards to connect additional peripheral devices.
All of the entry class servers include internal disks. Older servers used SCSI
controllers/disks. Newer servers use Serial Attach SCSI (SAS) controllers/disks. Some
servers also support HP’s SmartArray controllers, which provide hardware mirroring. All
internal disks on current server models are hot-pluggable, so failed disks can usually be
replaced without shutting down the operating system.

Module 5
All of the entry class servers offer a slimline DVD drive. The DVD is included standard on
some servers, and as an option on others. Some models accommodate a tape drive in place
of the DVD if desired.
All of the entry class servers support an Integrated Lights Out (iLO) Management Processor
card (though the card is an add-on option on some models). The iLO/MP enables the
administrator to remotely access the system console, view system hardware status messages,
reset the system, and power the system on and off. All iLO/MP cards provide remote access
via telnet and HTTPS. The iLO web interface is very similar to the web interface provided
by HP’s ProLiant servers. Some models offer an SSH access option, too, for enhanced
security.
All of the current entry class servers include redundant, hot-plug power supplies, fans, and
disks to minimize downtime.
For detailed specifications of the entry-class servers, go to


Module 5
5–16. SLIDE: Entry-Class Rackmount Server Example: HP

Integrity rx2660 (front)
Entry-Class Rackmount Server Example:

HP Integrity rx2660 (front)
• The next couple slides show the layout of an Integrity rx2660 entry-class rackmount server
• For descriptions of other entry-class servers visit http://www.hp.com/go/servers
1 2 3 4 5 6 7 8
1. DVD 5. System Reset Button

2. Redundant Fans 6. Indicator Lights
3. VGA 7. Power Button
4. USB 8. SAS Disks
Student Notes
The slide above shows the major components visible from the front of an rx2660 entry-class
rackmount server.
To learn more about the rx2660 and other entry class servers, go to

Module 5
5–17. SLIDE: Entry-Class Rackmount Server Example: HP

Integrity rx2660 (rear)
Entry-Class Rackmount Server Example:

HP Integrity rx2660 (rear)
11
1 2 3 4 5 6 7 8 9 10
1. PCI-x/PCI-e expansion slots 7. MP serial port

a. Dual 1Gb Ethernet HBA 8. MP LAN port
b. Audio Adapter 9. MP status LEDs
c. Dual U320 SCSI HBA 10. MP reset button
2. Core I/O Dual LAN ports 11. Redundant Hot-Swap Power Supplies
3. Smart Array Controller slot (empty)
4. Core I/O serial port
5. Core I/O VGA port
6. Core I/O USB port
Student Notes
The photo on the slide above shows a rear view of the rx2660 entry-class rackmount server.
To learn more about the rx2660 and other entry-class servers, go to

Module 5
5–18. SLIDE: Mid-Range Cell-Based Server Overview
Mid-Range Cell-Based Server Overview

HP’s mid-range, rackmount cell-based servers are ideal for mission-critical, consolidation, and
scale-up deployments that require up to 32 processor cores in a rackmount form factor.
Common Features:
• Integrated LAN interfaces
• Integrated SCSI interface
• Integrated Management Processor
HP Integrity rx7640 HP Integrity rx8640

• 10 rack units • 17 rack units
• 2 cell boards • 4 cell boards
• 8 processors • 16 processors
• 16 cores • 32 cores
• 32 DIMMs • 64 DIMMs
• 4 internal disks • 8 internal disks
• 15 PCIe / PCI-X slots • 32 PCIe/PCI-X slots
Student Notes
HP’s mid-range rackmount servers utilize HP’s cell-based server technology, in which each
server contains one or more cell boards. Each cell board may be connected to an optional
I/O chassis which contains eight expansion slots. A low-latency crossbar backplane provides
connectivity between the cell boards.
The cell-based architecture provides tremendous expandability. As the need for processing
power, expansion slots, and memory increases, additional cell boards may be added to the
system.
The rx7640 cell-based server supports up to two cell boards and 16 cores. The rx8640 cell-
based server supports up to four cell boards and 32 cores.
The mid-range, rackmount cell-based servers are ideal for mission-critical, consolidation, and
scale-up deployments that require up to 32 processor cores in a rackmount form factor.
For detailed specifications of this and other mid-range servers visit


Module 5
5–19. SLIDE: Mid-Range Cell-Based Server Example: HP Integrity

rx8640 (front)
Midrange Cell-Based Server Example:

HP Integrity rx8640 (front)
• The graphic below shows the physical layout of an Integrity rx8640 server
• For descriptions of other mid-range servers visit http://www.hp.com/go/servers
Two DDS or DVD drives
I/O power supplies Four hot-pluggable disks
Redundant hot-swap fans Four cell boards
Redundant hot-swap power supplies
Student Notes
The graphic on the slide shows the physical layout of a rack-mounted, mid-range rx8640
server. The rx8640 supports four cell boards, two 8-slot I/O chassis in the rear, two DDS/DVD
bays, and four internal disks. Customers who require additional interface cards can purchase
a System Expansion Unit (SEU) that provides two additional 8-slot I/O chassis, four
additional internal disks, and two additional DDS/DVD bays.
The rx7640 is similar, but supports two rather than four cellboards.


Module 5
5–20. SLIDE: Mid-Range Cell-Based Server Example: HP Integrity

rx8640 (rear)
Midrange Cell-Based Server Example:

HP Integrity rx8640 (rear)
I/O bay with two 8-slot I/O chassis
MP/Core I/O
Redundant hot-swap fans
Crossbar backplane
Power inputs
Student Notes
The photo on the slide above shows a rear view of the rx8640 mid-range server.

Module 5
5–21. SLIDE: High-End Cell-Based Server Overview
High-End Cell-Based Server Overview

For over a decade, enterprise customers have trusted HP’s mission-critical cell-based Integrity
Superdome server to provide maximum performance, scalability, and flexibility.
Integrity Superdome:
• Up to two compute cabinets
• Up to two I/O Expansion Cabinets
• Up to 16 cell boards
• Up to 64 dual-core processors
• Up to 128 cores
• Up to 512 DIMMs
• Up to 192 PCIe/PCI-X slots
• Integrated iLO / MP
Student Notes
For over a decade, enterprise customers have trusted HP’s mission-critical cell-based
Integrity Superdome server to provide maximum performance, scalability, and flexibility.
HP’s high-end Superdome servers support up to 16 cell boards, with 128 processor cores and
192 expansion slots.
The cell-based architecture provides a great deal of expandability. As the need for
processing power, expansion slots, and memory increases, additional cell boards may be
added to the system. Node partitioning enables the administrator to assign (and re-assign!)
cell boards to one or more functionally isolated nPar partitions for even greater flexibility.
For detailed specifications of this and other Superdome server configurations, visit

Module 5
5–22. SLIDE: High-End Cell-Based Server Example: HP Integrity

Superdome (front)
High-End Cell-Based Server Example:

HP Integrity Superdome (front)
• The graphic on the right shows the

Blowers 0-1
front view physical layout of an
8-cell Integrity Superdome server
compute cabinet
• For descriptions of other high-end
Superdome servers visit
http://www.hp.com/go/servers Cell Slots 0-7
I/O Bay 0
I/O Fans 0-4
I/O Chassis 1 and 3
each with 12 expansion
slots
Power Supplies
Leveling Feet
Front
Student Notes
The graphic on the slide shows the physical layout of an 8-cell Superdome server. Each
Superdome “compute” cabinet contains up to eight cell boards with four dual-core Montecito
processors per cell, and two I/O bays, each containing two 12-slot I/O chassis.
Customers who require larger configurations can purchase two side-by-side compute
cabinets to support up to 16 cell boards and 96 I/O expansion slots, as shown below.
Optional I/O expansion units provide additional I/O expandability.

Module 5
Cabinet 0 Cabinet 1 IOX Cabinet 8 IOX Cabinet 9

• 8 Cells • 8 Cells • peripherals • peripherals
• 2 I/O bays • 2 I/O bays • 3 I/O bays • 3 I/O bays
• 4 I/O chassis • 4 I/O chassis • 6 I/O chassis • 6 I/O chassis
• 48 slots • 48 slots • 72 slots • 72 slots
For detailed specifications of this and other Superdome server configurations, visit

Module 5
5–23. SLIDE: High-End Cell-Based Server Example: HP Integrity

Superdome (rear)
High-End Cell-Based Server Example:

HP Integrity Superdome (rear)
Blowers 2-3
Crossbar Backplane
MP
I/O Bay 1
I/O Chassis 1 and 3
each with 12 expansion slots
Cable Groomer
Rear
Student Notes
The photo on the slide above shows a rear view of the Integrity Superdome server computer
cabinet.

Module 5
5–24. SLIDE: HP BladeSystem Overview
HP BladeSystem Overview
• For maximum flexibility, consider HP’s HP BladeSystem solution
• A blade server is a compact, high-density server that has its own CPU and memory
resources, but that shares network, power, cooling, and storage resources with other blade
servers in an HP BladeSystem enclosure.
HP BladeSystem advantages:
• Manageability
Sophisticated integrated management and monitoring tools simplify
administration of the blade enclosure, and of the blades within the enclosure
• Availability
Redundant power, cooling, and interconnects eliminate single points of
failure
• Flexibility
The HP BladeSystem supports Integrity, ProLiant, and storage blades in a
single enclosure. HP’s Virtual Connect technology allows you to quickly
deploy (and redeploy) without rewiring!
• Serviceability
Simple tool-less replacement for most components; powerful, intuitive,
proactive diagnostic tools
• Scalability
Consolidated power and cooling and the BladeSystem’s dense form factor,
enable you to deploy more servers, more quickly and more cost effectively
Student Notes
For maximum flexibility, consider the HP BladeSystem Integrity blade server solutions.
A blade server is a compact, high-density server that has its own CPU and memory, but that
shares power, cooling, and an intuitive management interface in a specially designed HP
BladeSystem enclosure.
All of the components in the enclosure connect to a common midplane, eliminating the need
for power, LAN, and SAN cables to individual server blades.
The servers and all the components of the enclosure work together as a seamless unit,
increasing efficiency and reducing costs by eliminating many of the overlapping resources
required to support stacks of individual rack servers.
The list below describes some of the most important features of HP’s latest BladeSystems.
• Manageability:

Module 5
HP’s c-Class BladeSystem’s Onboard Administrator provides a consolidated web-based

interface for the administrator to manage BladeSystem components. This intuitive
interface may be used to configure server, storage, network, and power settings locally
through an interactive LCD panel or remotely through an easy-to-use web interface. It
also facilitates blade infrastructure firmware updates and consolidates access to all of the
iLO management processors. Detailed visual renderings of HP BladeSystem hardware as
well as pre-programmed field-replaceable-unit (FRU) information help expedite
identification and replacement of faulty components.
For IT organizations that need to manage large numbers of HP BladeSystem enclosures,

the Onboard Administrator command-line interface facilitates scripted operation of key
management operations, and multiple Onboard Administrator modules can be discovered
and launched from within HP’s Systems Insight Manager.
Also, thermalLogic Monitoring software in the HP BladeSystem enclosure can

automatically monitor and manage an enclosure’s power, cooling, and other resources,
enabling and disabling power supplies and fans as necessary based on the blades’
requirements.
• Availability: All power supplies, fans, and other critical enclosure components are
redundant and hot-pluggable to ensure maximum uptime.
• Flexibility: Enclosures may contain a mix of ProLiant, Integrity, and storage blades,
allowing the administrator to easily match the blade mix in the enclosure to the needs of
the organization. BladeSystem “mezzanine” expansion cards are interchangeable: many
of the fibre channel and Ethernet cards used on HP’s c-Class ProLiant blades are
supported on c-Class Integrity server blades.
HP’s c-Class BladeSystem’s Virtual Connect technology can drastically reduce and
simplify cabling requirements, too.

Module 5
Densely stacked rack-mounted servers with many Ethernet and Fibre Channel (FC)
connections can result in hundreds of cables coming out of a rack. Installing and
maintaining multitudes of cables is time-consuming and costly. When you add, move, or
replace a traditional server, you must typically add new power and cooling units, and
modify the LAN and SAN, which may require assistance from your LAN, SAN, and facility
administrators. This may delay server changes and deployments.
Virtual Connect is an industry standard-based implementation of server-edge I/O

virtualization. It puts an abstraction layer between the servers and the external networks
so that the LAN and SAN see a pool of servers rather than individual servers. Once the
LAN and SAN connections are made to the pool of servers, the server administrator uses
a Virtual Connect Manager Interface to create an I/O connection profile for each server.
Instead of using the default media access control (MAC) addresses for all network
interface controllers (NICs) and default World Wide Names (WWNs) for all host bus
adapters (HBAs), the Virtual Connect Manager creates bay-specific I/O profiles, assigns
unique MAC addresses and WWNs to these profiles, and administers them locally.
Virtual Connect technology provides a simple, easy-to-use tool for managing the
connections between HP BladeSystem c-Class servers and external networks. It cleanly
separates server enclosure administration from LAN and SAN administration, relieving
LAN and SAN administrators from server maintenance and makes HP BladeSystem c-
Class server blades change-ready, so that blade enclosure administrators can rapidly add,
move, and replace server blades with minimal assistance from LAN/SAN administrators.
• Serviceability: HP’s BladeSystem enclosures support tool-less removal of most

components without removing the enclosure from rack or blades from the enclosure.
Powerful, intuitive diagnostic tools simplify troubleshooting, too.
• Scalability: HP’s BladeSystem provides more efficient power and cooling than rack-
mounted server solutions, since consolidated power supplies and zone-based cooling
components in the enclosure provide power and cooling for multiple server blades. As a
result, BladeSystem solutions may enable organizations to deploy more servers, much
more quickly and affordably, in a smaller datacenter footprint than would otherwise be
possible with rack-mounted servers.
The graphic on the slide above is an HP BladeSystem c7000 blade enclosure with eight half-
height ProLiant blades and four full-height Integrity BL860c blades in the slots on the right.

Module 5
5–25. SLIDE: HP BladeSystem Enclosure Overview
HP BladeSystem Enclosure Overview

HP currently offers two HP BladeSystem enclosures: the HP BladeSystem c7000 and c3000
• Both enclosures utilize the same blades, interconnects, power, cooling, and other
components
• Both enclosures enable you to mix and match a variety of Integrity and ProLiant server blades
c7000 Blade Enclosure

•10 rack units
• Up to 8 full height blades
• As shown:
− 8 half-height ProLiant blades
− 4 Integrity BL860c blades
c3000 Blade Enclosure

• Rack and tower configurations
• 6 rack units
• Up to 4 full height blades
• As shown:
− 4 Integrity BL860c blades
Student Notes
HP currently offers two HP BladeSystem enclosures: the HP BladeSystem c7000 and c3000.
Both enclosures utilize the same blades, interconnects, power, cooling, and other
components, and both allow you to mix and match a variety of Integrity and ProLiant server
blades in the enclosure.
The c7000 is a 10 rack unit enclosure that can accommodate up to eight full height blades or
sixteen half-height blades. The enclosure on the slide has eight half-height ProLiant blades
on the left, and four full-height HP Integrity BL860C blades on the right.
The c3000 is a 6 rack unit enclosure that can accommodate up to four full height blades or
eight half-height blades. The c3000 is also available in a tower configuration for small office
deployments. The c3000 on the slide has four full-height HP Integrity BL860C blades on the
right.
HP’s HC590S Integrity Blade Server Administration course discusses the c-class blade
enclosures and Integrity blade models and management tools in much greater detail.

Module 5
For detailed product specifications, see the enclosure datasheets on

http://www.hp.com/go/blades.
These two white papers on http://www.hp.com provide additional information about the
C-class BladeSystem enclosures:
• Technologies in the HP BladeSystem c7000 Enclosure technology brief

• HP BladeSystem c-Class architecture technology brief

Module 5
5–26. SLIDE: HP BladeSystem Enclosure Example: HP

BladeSystem c7000 Enclosure
HP BladeSystem Enclosure Example:

HP BladeSystem c7000 Enclosure
The graphic below highlights some of the important components of the HP BladeSystem c7000
blade enclosure
Blade Enclosure Front Blade Enclosure Back

One or more Interconnects
server blades, provide flexible
with independent LAN/SAN
CPU, memory, connectivity
and disks between blades
(no cabling
Insight display required!),
provides an and to external
intuitive interface LANs & SANs,
to manage the too!
enclosure (a
Redundant power supplies, Redundant cooling fans,
web interface
managed and monitored managed and monitored
is available, too!)
by the enclosure efficiently by the enclosure efficiently
provides power for the provide cooling for the blades
blades in the enclosure in the enclosure
Student Notes
The slide above highlights some of the critical components of the c7000 BladeSystem
enclosure.

Module 5
5–27. SLIDE: HP Integrity Blade Server Model Overview
HP Integrity Blade Server Model Overview

• HP offers a complete line of Integrity server blades, from 2- to 32-cores
• All are compatible with the HP BladeSystem c3000 and c7000 enclosures
• All leverage HP BladeSystem’s manageability, availability, flexibility, and serviceability
features
BL860C BL870C BL860C i2 BL870C i2 BL890C i2

• 1 blade slot • 2 blade slots • 1 blade slots • 2 blade slots • 4 blade slots
• 2 processors • 4 processors • 2 processors • 4 processors • 8 processors
• 4 cores • 8 cores • 8 cores • 16 cores • 32 cores
• 24 DIMMs • 48 DIMMs • 24 DIMMs • 48 DIMMs • 96 DIMMs
Student Notes
HP offers a complete line of Integrity server blades, from 2- to 32-cores. All are compatible
with the HP BladeSystem c3000 and c7000 enclosures, and all leverage the HP BladeSystem
manageability, availability, flexibility, and serviceability features described previously.

Module 5
5–28. SLIDE: HP Integrity Server Blade Example: HP Integrity

BL890c i2
HP Integrity Server Blade Example:

HP Integrity BL890c i2
• HP’s BL860C i2, BL870C i2, and BL890C i2 blades all utilize a common “foundation blade”
• The Integrity Blade Link, using Intel’s QPI fabric technology, conjoins 1, 2, or 4 foundation
blades
• Each blade in the QPI fabric has full access to resources on the other blades via the QPI fabric
+ + + + =
4 x Foundation Blades, each providing: Integrity Blade Link BL890c i2

• Up to 2 processors / 8 cores
• Up to 24 DIMMs
• Two internal SAS disks
• Two dual-port 10Gb Flex-10 LAN interfaces
• Three mezzanine expansion card slots
Student Notes
The graphic on the slide shows an Integrity BL890C i2.
HP’s BL860C i2, BL870C i2, and BL890C i2 blades all utilize a common “foundation blade”.
Each foundation blade hosts:
• Up to 2 dual- or quad-core processors

• Up to 24 DIMMs
• Two internal SAS disks
• Two dual-port 10Gb Flex-10 LAN interfaces
• Three internal mezzanine expansion card slots
The graphic below shows the foundation blade’s internal architecture:

Module 5
The Integrity Blade Link, using Intel’s QuickPath Interconnect (QPI) fabric technology, may
be used to conjoin one to four foundation blades. Each blade in the QPI fabric has full
access to resources on the other blades via the QPI fabric. This approach allows HP’s
Integrity blades to easily scale from 2 to 32 processor cores.
• The BL860C i2 utilizes one foundation blade

• The BL870C i2 conjoins two foundation blades
• The BL890C i2 conjoins four foundation blades
The graphic below shows the architecture of the QPI fabric in a BL890C i2:

Module 5
HP’s HC590S Integrity Blade Server Administration course discusses the c-class blade
enclosures and Integrity blade models and management tools in much greater detail.
For detailed product specifications, see the datasheets on

http://www.hp.com/go/integrityblades.
Also read the following white paper’s on http://docs.hp.com to learn more about the
Integrity blade architecture:
• Why Scalable Blades: HP Integrity Server Blades (BL860c i2, BL870c i2, and BL890c
i2)
• Technologies in HP Integrity server blades (BL860c i2, BL870c i2, and BL890c i2)

Module 5
5–29. SLIDE: HP Integrity Superdome 2 Overview
HP Integrity Superdome 2 Overview

For maximum scalability, availability, and flexibility, consider HP’s Superdome 2
• Superdome 2 leverages its lower mid-plane, power, cooling, interconnects, and other
modular components from the HP BladeSystem c7000 enclosure
• … But adds a fault tolerant, low latency crossbar fabric that facilitates the creation of nPars
with up to 128 cores
• … And an upper midplane, unique to the Superdome 2, to connect external I/O expansion
enclosures, with up to 96 external PCIe I/O expansion cards
Superdome 2 Superdome 2
8-socket 16-socket
Superdome 2
32-socket
Student Notes
For maximum scalability, availability, and flexibility, consider the HP Superdome 2 server.
Superdome 2 leverages its lower mid-plane, power, cooling, interconnects, and other modular
components from the HP BladeSystem c7000 enclosure. It adds a fault tolerant, low latency
crossbar fabric that facilitates the creation of nPars with up to 128 cores, and a Superdome 2
specific upper midplane that supports to connect external I/O expansion enclosures, each
with up to 12 PCIe I/O expansion cards.
HP offers three versions of the Superdome 2 server:
• The 8-socket / 32-core Superdome 2 has four Superdome 2 blades in a single Superdome 2
enclosure.
• The 16-socket / 64-core Superdome 2 has eight Superdome 2 blades in a single Superdome
2 enclosure.
• The 32-socket / 128-core Superdome 2 has sixteen Superdome 2 blades in two Superdome
2 enclosures connected via a single Superdome 2 enclosure.

Module 5
5–30. SLIDE: HP Integrity Superdome 2 Example: HP Integrity

Superdome 2
HP Integrity Superdome 2 Example:

HP Integrity Superdome 2
Superdome 2 Compute Enclosure Superdome 2 I/O Expansion Enclosure
(up to 2 per complex, each with up to 8 blades) (each enclosure provides 12 additional
PCIe expansion slots)
Lower Midplane Upper Midplane

Front
Front Rear Rear
• The Superdome 2 compute enclosure contains up to eight 2-socket Superdome 2 blades

• Lower midplane is highly leveraged from the c7000; same power, cooling, interconnects
• Upper midplane provides a fault tolerant crossbar, and connectivity to I/O expansion enclosures
• External I/O expansion enclosures house additional PCIe expansion cards
Student Notes
The graphic on the slide shows a close-up view of an 8-socket / 32-core Superdome 2.
The Superdome 2 compute enclosure contains up to eight 2-socket Superdome 2 blades.

Each Superdome 2 blade houses two quad-core Itanium processors, 32 DIMMs, two dual port
10Gb LAN interfaces, and up to three PCIe mezzanine expansion cards.
The lower midplane is highly leveraged from the c7000, using many of the same power,
cooling, and LAN/SAN interconnect modules.
The upper midplane, designed specifically for the Superdome 2, provides a fault tolerant
crossbar, and connectivity to external I/O expansion enclosures.
Eight external I/O expansion enclosures each house up to twelve additional PCIe expansion
cards.

Module 5
The diagram below shows the Superdome 2’s internal architecture.
To learn more about Superdome 2, attend HP Education’s HK713S Superdome 2

Administration course.
For detailed product specifications, see the datasheet on

http://www.hp.com/go/superdome.
Or, read more about Superdome 2 architecture in the HP Superdome 2: the Ultimate
Mission-critical Platform white paper on http://www.hp.com.

Module 5
5–31. SLIDE: Viewing the System Configuration
Viewing the System Configuration
HP-UX provides several commands for viewing your system

configuration
View the system model string
# model
# uname –a
View processor, memory, and firmware configuration information

# machinfo
View cell boards, interface cards, peripheral devices, and other components
# ioscan all components
# ioscan –C cell cell board class components
# ioscan –C lan LAN interface class components
# ioscan –C disk disk class devices
# ioscan –C fc fibre channel interfaces
# ioscan –C ext_bus SCSI buses
# ioscan –C processor processors
# ioscan –C tty serial (teletype) class components
SAM and the SMH can also provide detailed hardware information
Student Notes
HP-UX provides several commands for viewing your system configuration.
Execute the model command to determine your system’s hardware model string.
# model
ia64 hp server rx2600
In 11i v2 and 11i v3, the machinfo command reports detailed processor, memory, firmware,
model, and operating system information.
# machinfo
CPU info:
1 Intel(R) Itanium 2 processor (1.4 GHz, 1.5 MB)
400 MT/s bus, CPU version B1
Memory: 4084 MB (3.99 GB)

Module 5
Firmware info:
Firmware revision: 02.31
FP SWA driver revision: 1.18
IPMI is supported on this system.
BMC firmware revision: 1.53
Platform info:
Model: "ia64 hp server rx2600"
Machine ID number: e85c91a3-7141-11d8-b1ce-0f6d684be9ae
Machine serial number: US40676377
OS info:
Nodename: myhost
Release: HP-UX B.11.31
Version: U (unlimited-user license)
Machine: ia64
ID Number: 3898380707
vmunix _release_version:
@(#) $Revision: vmunix: B.11.31_LR FLAVOR=perf
The ioscan command presents a hierarchical list of cell boards, interface cards, peripheral
devices, and other components on your system. By default, ioscan reports each
component’s hardware path, class, and description. Add the –C option to view a specific
device class such as cell, disk, lan, or processor. Slides later in the chapter describe
HP-UX hardware paths and other ioscan options in detail.
# ioscan
H/W Path Class Description
==============================================================
root
1 cell
1/0 ioa System Bus Adapter (804)
1/0/0 ba Local PCI Bus Adapter (782)
1/0/2/0/0 ext_bus SCSI C1010 Ultra160
1/0/2/0/0.8 target
1/0/2/0/0.8.0 disk HP 36.4GST336607LC
1/0/2/0/0.10 target
1/0/2/0/0.10.0 disk HP 36.4GST336607LC
1/0/14/0/0 lan HP A5230A 10/100Base-TX
1/5 memory Memory
1/10 processor Processor
The SMH (11i v2 and v3) can also provide detailed hardware information. Click the
“Processors”, “Memory”, and other links on the SMH Home tab.

Module 5

Module 5
5–32. SLIDE: Viewing nPar, vPar, and VM Hardware
Viewing nPar, vPar, and VM Hardware
• Hardware resources allocated to one partition aren’t visible to other partitions

• HP-UX commands only display devices & resources in the current partition
Q: Why do I only see half of my interface cards

and cell boards?
A: ioscan only reports the devices available in

my current partition!
Student Notes
Viewing system hardware resources becomes more complicated on partitioned systems.
Hardware resources allocated to one nPar, vPar, or Integrity VM are not visible to other
partitions. The peripheral device and interface card management commands discussed in the
remaining slides of the chapter -- such as ioscan, scsimgr, rad, olrad, pdweb, and sam --
only display devices in the current partition.
To determine which resources have been assigned to other nPars partitions on the system,
run the parstatus command. Similarly, vparstatus reports which resources have been
allocated to other virtual partitions, and hpvmstatus reports which resources have been
allocated to Integrity virtual machine guests.

Module 5
5–33. SLIDE: Part 3: HP-UX Hardware Addressing
Configuring
Hardware:
Part 3: HP-UX Hardware Addressing
Student Notes

Module 5
5–34. SLIDE: Hardware Addresses
Hardware Addresses
In order to successfully configure and manage devices on an HP-UX
system, administrators must understand the addressing mechanism used
to identify devices
syslog.log tells me that one of my interface

cards has failed – but how can I tell which one I
need to replace?
Student Notes
During the HP-UX startup process, the kernel automatically scans the system hardware and
assigns a unique HP-UX hardware address to every bus adapter, interface card, and device.
In order to configure new devices on your system, you need to be able to read and
understand these hardware addresses. The next few slides discuss HP-UX hardware
addressing in detail.

Module 5
5–35. SLIDE: Legacy vs. Agile View Hardware Addresses
Legacy vs. Agile View Hardware Addresses
• 11i v1 and v2 implement a “legacy” mass storage stack and addressing scheme
• 11i v3 implements a new mass storage stack, with many new enhancements
• 11i v3 uses new “agile view” addresses, but still supports legacy addresses, too
11i v3’s mass storage stack enhancements include:

• increased scalability
• enhanced adaptability
• native multipathing
• better management tools
• improved performance
Student Notes
11i v1 and v2 implement a “legacy” mass storage stack and hardware addressing scheme. 11i
v3 implements a new mass storage stack, with many enhancements and a new hardware
addressing scheme to better support the SAN-based storage used on most HP-UX servers
today. To ensure backward compatibility, 11i v3 still supports legacy hardware addresses,
but HP encourages administrators to begin using the new “Agile View” hardware addresses.
The notes below highlight some of the most important new features provided by the new
mass storage stack and hardware addressing scheme.
Increased Scalability
The new mass storage stack significantly increases the operating system’s mass storage
capacity as shown in the table below.
Feature HP-UX 11i v2 HP-UX 11i v3

Max I/O buses per server 256 No Limit
Max LUNs per server 8192 16384 (architectural limit 16m)
Max LUN size 2TB >2TB
Max I/O paths to a single LUN 8 32

Module 5
In addition, the mass storage stack has been enhanced to take advantage of large multi-CPU
server configurations for greater parallelism. Adding more mass storage to a server does not
appreciably slow down the boot process or the ioscan command that administrators use to
view available hardware.
See the HP-UX 11i v3 Mass Storage I/O Scalability white paper for details.
Enhanced Adaptability
The new mass storage stack enhances a server’s ability to adapt dynamically to hardware
changes, without shutting down the server or reconfiguring software.
11i v3 servers automatically detect the creation or modification of LUNs. If new LUNs are
added, the new mass storage stack recognizes and configures them automatically. If an
existing LUN’s addressing, size, or I/O block size changes, the mass storage stack detects this
without user intervention.
When such changes occur, the mass storage stack notifies the relevant subsystems. For
example, if a LUN expands, its associated disk driver, volume manager, and file system are
notified. The volume manager volume or file system can then automatically expand
accordingly.
The new mass storage stack can also remove PCI host bus adapters (HBAs) without shutting
down the server. Coupled with existing online addition and replacement features, online
deletion enables you to replace a PCI card with a different PCI card, as long as the HBA slot
permits it and no system critical devices are affected. You can also change the driver
associated with a LUN; if the software drivers don’t support rebinding online, the system
remembers the changes and defers them until the next server reboot.
Native Multipathing
11i v3 “agile addressing” creates a single virtualized hardware address for each disk or LUN
regardless of the number of hardware paths to the device. The administrator can use the
single virtualized hardware path, rather than the underlying hardware paths, when
configuring the disk or LUN. When a volume manager, file system, or application accesses
the device, the new mass storage stack transparently distributes I/O requests across all
available hardware paths to the LUN using a choice of load balancing algorithms.
If a path fails, the mass storage stack automatically disables the failed path and redistributes
I/O requests across the remaining paths. The kernel monitors failed or non-responsive paths,
so that when a failed path recovers it is automatically and transparently reincorporated into
any load balancing. The mass storage stack automatically discovers and incorporates new
paths, too.
11i v1 and v2 administrators typically rely on add-on multi-pathing products from array
vendors to provide multi-pathing functionality.
The new mass storage stack simplifies management of LUN Device Special Files (DSFs), too.
The next chapter discusses these DSF enhancements in detail.

Module 5
Better Management Tools

The new mass storage stack includes several new tools for monitoring and managing devices.
The improved ioscan command allows the administrator to easily correlate paths and
LUNs. Another new ioscan option reports the health of each LUN and the underlying
hardware paths.
A new utility called scsimgr allows the administrator to easily view LUN attributes and
usage statistics, and modify the load balancing algorithm used when accessing the LUN.
The new tools and features are integrated with other systems and storage management
utilities such as Systems Management Homepage (SMH) and Systems Insight Manager (SIM)
and Storage Essentials.
Improved Performance
The new mass storage stack achieves better performance by using high levels of concurrent
I/O operations and parallel processing, processor allegiance algorithms, and unique HP server
hardware features such as Cell Local Memory. The operating system provides a choice of
load balancing algorithms, too, so administrators can tune performance to meet each server’s
requirements.
Compatibility
11i v3 supports both legacy addressing and Agile View addressing. HP encourages customers
to begin using the new addressing scheme, though legacy hardware addresses are still
available.
HP-UX includes two commands to ease the migration to the new mass storage stack. The
iofind command automatically identifies configuration files that reference legacy
addresses, and optionally replaces them with equivalent Agile View addresses. The ioscan
–m hwpath command may be used to list Agile View LUN hardware paths and their
equivalent legacy addresses.

Module 5
5–36. SLIDE: Legacy HBA Hardware Addresses
Legacy HBA Hardware Addresses

HBAs are identified by hardware addresses that encode the HBA’s
cell/SBA/LBA/device/function location in the kernel’s I/O tree structure
1/0/0/2/0
Cell SBA LBA device/function
HBA hardware address

SAN
Crossbar
LUN
CPUs LUN
Memory
LAN
LBA Core I/O Serial
Cell Boards SCSI Disk
PCI-X Bus
DVD
MP LAN
Serial
Student Notes
The next few slides discuss the legacy hardware addressing scheme used in 11i v1 and v2.
Later slides discuss the addressing scheme used in 11i v3’s new mass storage stack.
All current systems based on PCI/PCI-X/PCI-Express expansion buses use a fairly consistent
hardware addressing scheme, which we will focus on here.
Every LAN, LUN, disk, or tape drive hardware address begins with an HBA hardware address.
An HBA hardware address encodes the HBA’s location in the kernel’s I/O tree structure:
Cell/SBA/LBA/device/function
The notes below describe each hardware path component in detail.
Cell On cell-based servers, the first component of the HP-UX hardware

path identifies the global cell number of the cell board to which the
device is attached. On Superdome systems, cells are numbered 0-
15. rx/rp7xxx servers have two cell boards numbered 0-1.
rx/rp8xxx servers have four cell boards numbered 0-3. Non-cell-
based systems don’t include cell numbers in the hardware paths.

Module 5
SBA The next portion of the HP-UX hardware address identifies the
address of the System Bus Adapter (SBA). This portion of the
address will always be 0 in HBA and peripheral device hardware
paths. Hardware paths for processors and memory modules
typically display a non-zero number in this component of the
hardware path.
LBA The SBA connects to one or more Local Bus Adapters (LBAs) via
high-speed communication channels known as “ropes”. Some
LBAs have just one rope to the SBA. Other LBAs have two ropes to
the LBA to provide enhanced throughput.
The LBA component in the HP-UX hardware path identifies the

rope number that connects the LBA to the SBA. When an LBA has
two ropes to the SBA, the lower rope number is used in the
hardware path.
Because some LBAs utilize two ropes and others utilize just one, an
HBA’s rope/LBA number typically isn’t the same as its physical slot
number.
Device/Function Each LBA typically provides connectivity to one or two PCI, PCI-X,
PCI-E expansion slots, each accommodating an interface card with
one or more functions. The Device/Function numbers together
uniquely identify a specific function on a specific PCI or PCI-X
card. If a card isn’t a multi-function card, a device/function
combination 0/0 indicates that it is a PCI card, and 1/0 indicates
that it is PCI-X.
Slides later in the chapter describe the ioscan command, which lists a system’s hardware
paths, and the rad and olrad commands, which translate hardware paths into physical slot
locations. Service manuals, which often include system-specific hardware addressing
information, are available at http://docs.hp.com/en/hw.html.

Module 5
5–37. SLIDE: Legacy Parallel SCSI Hardware Addresses
Legacy Parallel SCSI Hardware Addresses

• Some servers use a parallel SCSI bus to connect internal disks, DVDs, and tapes
• Each SCSI bus supports multiple devices, each identified by a unique target address
• Each device on a SCSI bus may support multiple LUNs, identified by unique LUN IDs
• Legacy SCSI hardware addresses encode a SCSI device’s HBA, target, and LUN ID
1/0/0/2/0.1.0
HBA hardware address Target LUN ID
Example: the following hardware addresses represent three distinct devices on a SCSI bus
•1/0/0/2/0.2.0
•1/0/0/2/0.6.0
•1/0/0/2/0.10.0 target 2 target 6 target 10
Student Notes
Some servers use a parallel SCSI bus to connect internal disks, DVDs, and tapes. Some Core
I/O cards provide an external SCSI port, too, which may be used to connect additional SCSI
devices. The server in the graphic on the slide has a SCSI HBA connected to three external
SCSI devices.
As shown in the graphic on the slide, legacy SCSI hardware addresses encode a SCSI device’s
HBA address, target address, and LUN ID.
HBA Addresses
The first part of a legacy SCSI hardware address identifies the address of the SCSI HBA to
which the device is attached. In the example on the slide, all three SCSI devices are
connected to the SCSI HBA at address 1/0/0/2/0. Thus, the hardware addresses for all three
devices begin with 1/0/0/2/0.
1/0/0/2/0.2.0
1/0/0/2/0.6.0
1/0/0/2/0.10.0

Module 5
SCSI Target Addresses

Each SCSI bus supports multiple devices, each identified by a unique target address. Legacy
addressing supports up to 16 targets, numbered 0-15, per SCSI bus. The next part of a SCSI
device’s legacy hardware address identifies the device’s SCSI target address.
The graphic on the slide shows a SCSI bus with three external devices identified by target
addresses 2, 6, and 10.
1/0/0/2/0.2.0
1/0/0/2/0.6.0
1/0/0/2/0.10.0
When attaching an external SCSI device, it may be necessary to manually assign a target
address. Some devices use a series of binary DIP switches to set the address. Other devices
use a series of jumper pins. Consult your device documentation to determine how to set your
device’s SCSI target address.
LUN IDs
Some SCSI devices may have a single SCSI target address, with multiple addressable units
within the device.
For example, tape autochangers often provide access to the autochanger’s tape drive via one
LUN ID, and access to the robotic mechanism via second LUN ID.
A SCSI disk array may present multiple virtual disks, each identified by a unique LUN ID.
HPUX uses the last component in the legacy SCSI hardware address to identify the LUN ID.
Most autochangers and disk arrays today are often connected via SAS or Fibre channel
interfaces rather than parallel SCSI, so the LUN ID portion of most SCSI device hardware
paths is typically 0.
1/0/0/2/0.2.0
1/0/0/2/0.6.0
1/0/0/2/0.10.0

Module 5
5–38. SLIDE: Legacy FC Hardware Addresses (1 of 2)
Legacy FC Hardware Addresses (1 of 2)

• Disk array LUNs are often accessible via multiple paths through a SAN
• HP-UX assigns each path a legacy hardware path that encodes:
− the legacy hardware address of the server HBA used to access the LUN
− the SAN domain/area/port used to access the array
− the LUN ID of the target LUN within the array
• The 11i v1 and v2 kernels provide no automated path correlation or management
1/0/2/1/0.6.1.0.0.0.1
HBA hardware address SAN domain/area/port Array LUN ID
Example: The array below has three LUNs, each accessible via four SAN paths
The next slide lists all legacy hardware paths to the first LUN
LUN 1 LUN 1 LUN 1 LUN 1

Student Notes
Fibre channel disk array LUNs are often accessible via multiple paths through a SAN. The
graphic on the slide shows a disk array with three LUNs, each accessible via four different
paths. It isn’t uncommon today to have four, eight, or even more different paths to a LUN.
The next slide lists the legacy hardware paths that would be used to represent LUN 1 in the
graphic.
Each legacy hardware address encodes:
• The legacy hardware address of the server HBA used to access the LUN. See the HBA
addressing discussion earlier in the chapter.
• The SAN domain/area/port used to access the array. Administrators may use the legacy
hardware address’s 8-bit domain, 8-bit area, and 8-bit port addresses to associate a
hardware address with a specific path through the SAN from the server HBA to the target
array controller. Different SAN switch vendors use the domain/area/port fields
differently. HP Customer Education’s Accelerated SAN Essentials class (UC434S)
discusses these differences in detail.

Module 5
• The LUN ID of the target LUN within the array. When presenting LUNs to a server, the
array administrator assigns each LUN a LUN ID.
The legacy addressing scheme was designed to accommodate SCSI-2 bus addresses, in
which each device on a bus was uniquely identified by a 7-bit “controller” number
(ranging from 0 to 128), a 4-bit “target” number (ranging from 0 to 15), and a 3-bit “LUN”
number (ranging from 0 to 7).
Since today’s arrays routinely present more than eight LUNs, the original 3-bit
representation of the LUN ID is insufficient. Thus, legacy addresses now use all 14
controller/target/LUN bits at the end of an FC hardware path to represent the LUN ID.
Thus, the last three components of the legacy hardware addresses for LUN IDs 0-16 would be
represented as follows:
LUN ID LUN ID LUN ID, as represented in a legacy HP-UX

(in decimal) (in binary) controller/target/LUN address
0 0000000 0000 000 x/x/x/x/x.x.x.x.0.0.0
1 0000000 0000 001 x/x/x/x/x.x.x.x.0.0.1
2 0000000 0000 010 x/x/x/x/x.x.x.x.0.0.2
3 0000000 0000 011 x/x/x/x/x.x.x.x.0.0.3
4 0000000 0000 100 x/x/x/x/x.x.x.x.0.0.4
5 0000000 0000 101 x/x/x/x/x.x.x.x.0.0.5
6 0000000 0000 110 x/x/x/x/x.x.x.x.0.0.6
7 0000000 0000 111 x/x/x/x/x.x.x.x.0.0.7
8 0000000 0001 000 x/x/x/x/x.x.x.x.0.1.0
9 0000000 0001 001 x/x/x/x/x.x.x.x.0.1.1
10 0000000 0001 010 x/x/x/x/x.x.x.x.0.1.2
11 0000000 0001 011 x/x/x/x/x.x.x.x.0.1.3
12 0000000 0001 100 x/x/x/x/x.x.x.x.0.1.4
13 0000000 0001 101 x/x/x/x/x.x.x.x.0.1.5
14 0000000 0001 110 x/x/x/x/x.x.x.x.0.1.6
15 0000000 0001 111 x/x/x/x/x.x.x.x.0.1.7
16 0000000 0010 000 x/x/x/x/x.x.x.x.0.2.0
The 11i v1 and v2 kernels provide no automated path correlation or management; they treat
each path as if it were an independent device. 11i v1 and v2 rely on the LVM and VxVM
volume managers or add-on path management solutions such as HP’s SecurePath product or
EMC’s PowerPath product to correlate redundant paths, ensure path failover when an HBA
fails, and provide load balancing across paths to a LUN.

Module 5
5–39. SLIDE: Legacy FC Hardware Addresses (2 of 2)
Legacy FC Hardware Addresses (2 of 2)

1/0/2/1/0.6.1.0.0.0.1
HBA hardware address SAN domain/area/port Array LUN ID
HBA: 1/0/2/1/0
SAN domain/area/port: 6.1.0
LUN ID: 0.0.1
HW Path: 1/0/2/1/0 . 6.1.0 . 0.0.1
HBA: 1/0/2/1/0
LUN ID: 0.0.1
HW Path: 1/0/2/1/0 . 6.2.0 . 0.0.1
HBA: 1/0/2/1/1
LUN ID: 0.0.1
HW Path: 1/0/2/1/1 . 6.1.0 . 0.0.1
HBA: 1/0/2/1/1
LUN ID: 0.0.1
HW Path: 1/0/2/1/1 . 6.2.0 . 0.0.1
Student Notes
The example on the slide shows four different SAN paths to LUN ID 1, and each path’s
corresponding legacy hardware path. The heavy black lines represent the physical path
through the SAN for each address. Note that the LUN ID is the same in all four paths; each
path is simply a different path to the same LUN.

Module 5
5–40. SLIDE: Viewing Legacy HP-UX Hardware Addresses
Viewing Legacy HP-UX Hardware Addresses

Use ioscan to view devices’ legacy HP-UX hardware addresses, properties, and states
# ioscan short listing of all devices

# ioscan -f full listing of all devices
# ioscan –kf full listing, using cached information
# ioscan -kfH 0/0/0/3/0 full listing of all devices below 0/0/0/3/0
# ioscan -kfC disk full listing of "disk" class devices
# ioscan –f
Class I H/W Path Driver S/W State H/W Type Description
================================================================
root 0 root CLAIMED BUS_NEXUS
cell 0 1 cell CLAIMED BUS_NEXUS
ioa 0 1/0 sba CLAIMED BUS_NEXUS SBA
ba 0 1/0/0 lba CLAIMED BUS_NEXUS LBA
slot 0 1/0/0/3 pci_slot CLAIMED SLOT PCI Slot
ext_bus 0 1/0/0/3/0 mpt CLAIMED INTERFACE U320 SCSI
target 0 1/0/0/3/0.6 tgt CLAIMED DEVICE
disk 0 1/0/0/3/0.6.0 sdisk CLAIMED DEVICE HP Disk
Student Notes
You can view a list of the device on your system and their legacy HP-UX hardware addresses
via the ioscan command. ioscan supports a number of useful options.
# ioscan Scans hardware and lists all devices and other hardware
devices found. Shows the hardware path, class, and a brief
description of each component.
# ioscan –f Scans and lists the system hardware as before, but displays
a "full" listing including several additional columns of
information. See the ioscan field output descriptions
below for more information.
# ioscan –kf Lists the system hardware as before, but uses cached
information. On a large system with dozens of disks and
interface cards, ioscan –kf is much faster than ioscan
–f.

Module 5
# ioscan -kfH 0/0/0/3/0 Shows a full listing of the component at the specified
hardware address, and all nodes in the I/O tree below that
node. The example shown here would display a full listing
of both the HBA at address 0/0/0/3/0 and the targets and
devices attached to that HBA (if any). -H is very useful on
a large system if you just need to view information about a
single device or bus.
# ioscan -kfC disk Lists devices of the specified class only. Two other
common classes are "tape" and "lan". The optional –k
option displays cached information.
# ioscan –kfn Lists device file names associated with each device. Device
files are discussed at length in the next chapter. The
optional –k option displays cached information.
Fields in the ioscan Output

Class The device “class” associated with the device or card. For
example, all LAN cards, from Ethernet cards to Token Ring
cards, belong to the lan class. All tape devices belong to
the tape class. A device’s class is determined by the
device’s kernel driver.
Instance The instance number associated with the device or card. It
is a unique number assigned by the kernel to each card or
device within a class. If no driver is available for the
hardware component, or if an error occurs binding the
driver, the kernel will not assign an instance number and a
-1 will be listed. Instance numbers are used when creating
device files, and will be discussed in more detail in the next
chapter.
H/W Path A string of numbers, separated by “/”’s and “.”s that

uniquely identifies each hardware component on the
system. Each number in the string represents the location
of a hardware component on the path to the device. Some
administrative tasks require the administrator to identify
devices by hardware path.
Driver The name of the kernel driver that controls the hardware
component. If no driver is available to control the
hardware component, a question mark (?) is displayed in
the output.

Module 5
S/W state The result of software binding.
CLAIMED means that a kernel driver successfully bound to

the device.
UNCLAIMED means that no driver was found to bind to the

device. Add the device’s driver to the kernel, then re-run
ioscan.
UNUSABLE means that the hardware at this address is no

longer usable due to some irrecoverable error condition; a
system reboot may clear this condition
SUSPENDED means that the associated software and

hardware are in suspended state. See the OL* discussion
later in this chapter.
DIFF_HW means that the hardware found does not match

the associated software.
NO_HW means that the hardware at this address is no longer

responding.
ERROR means that the hardware at this address is

responding but is in an error state.
SCAN means that a scan operation is in progress for this

node in the I/O tree.
Hardware Type Entity identifier for the hardware component. Common

examples include INTERFACE (for interface cards),
DEVICE (for peripheral devices), BUS_NEXUS (for bus
adapters), or PROCESSOR (for processors).
Description Describes the device or interface card, and in some cases,

identifies the device’s manufacturer and model number.
Troubleshooting with ioscan -f

After adding an interface card or SCSI device to your system, you should execute ioscan to
see if your system recognizes the device.
First, simply check to see that your new device appears in the ioscan output. If not,
shutdown your machine and check to ensure that all the cables are connected properly. In
the case of an interface card, ensure that the card is firmly inserted in the interface card slot
in the backplane of your machine.
Next, ensure that the hardware path is correct. Did you set the correct SCSI address? Add
the device and its hardware path and description to the hardware diagram in your system log
book.

Module 5
Assuming the hardware path is correct, check the S/W state column in the ioscan -f
output. In order to communicate with your new device or interface card, your kernel must
have the proper device drivers configured. If the proper driver already exists in your kernel,
the S/W State column should say CLAIMED. If this isn't the case, you will have to add the
driver to the kernel. A later chapter discusses kernel configuration.
If your new device appears to be CLAIMED by the kernel, proceed to the next chapter and
learn how to create and use device files to access your new device.

Module 5
5–41. SLIDE: Agile View HBA Hardware Addresses
Agile View HBA Hardware Addresses

Like earlier versions of HP-UX, Agile View HBA hardware addresses encode the HBA’s
cell/SBA/LBA/device/function location in the kernel’s I/O tree structure
1/0/0/2/0
Cell SBA LBA device/function
HBA hardware address

SAN
Crossbar
LUN
CPUs LUN
Memory
LAN
LBA Core I/O Serial
Cell Boards SCSI Disk
PCI-X Bus
DVD
MP LAN
Serial
Student Notes
The last few slides described the legacy hardware addressing scheme used in 11i v1 and v2.
The next few slides discuss the agile view addressing scheme introduced by the new mass
storage stack in 11i v3.
Like the addressing scheme used in earlier versions of HP-UX, the new Agile View HBA
hardware addresses encode the HBA’s cell/SBA/LBA/device/function location in the kernel’s
I/O tree structure.
Cell/SBA/LBA/device/function
The notes below describe each hardware path component in detail.
Cell On cell-based servers, the first component of the HP-UX hardware

path identifies the global cell number of the cell board to which the
device is attached. On Superdome systems, cells are numbered 0-
15. rx/rp7xxx servers have two cell boards numbered 0-1.
rx/rp8xxx servers have four cell boards numbered 0-3. Non-cell-
based systems don’t include cell numbers in the hardware paths.

Module 5
SBA The next portion of the HP-UX hardware address identifies the
address of the System Bus Adapter (SBA). This portion of the
address will always be 0 in HBA and peripheral device hardware
paths. Hardware paths for processors and memory modules
typically display a non-zero number in this component of the
hardware path.
LBA The SBA connects to one or more Local Bus Adapters (LBAs) via
high-speed communication channels known as “ropes”. Some
LBAs have just one rope to the SBA. Other LBAs have two ropes to
the LBA to provide enhanced throughput.
The LBA component in the HP-UX hardware path identifies the

rope number that connects the LBA to the SBA. When an LBA has
two ropes to the SBA, the lower rope number is used in the
hardware path.
Because some LBAs utilize two ropes and others utilize just one, an
HBA’s rope/LBA number typically isn’t the same as its physically
slot number.
Device/Function Each LBA typically provides connectivity to one or two PCI, PCI-X,
PCI-E expansion slots, each accommodating an interface card with
one or more functions. The Device/Function numbers together
uniquely identify a specific function on a specific PCI or PCI-X
card. If a card isn’t a multi-function card, a device/function
combination 0/0 indicates that it is a PCI card, and 1/0 indicates
that it is PCI-X.
Slides later in the chapter describe the ioscan command, which lists a system’s hardware
paths, and the rad and olrad commands, which translate hardware paths into physical slot
locations. Service manuals, which often include system-specific hardware addressing
information, are available at http://docs.hp.com/en/hw.html.

Module 5
5–42. SLIDE: Agile View Parallel SCSI Hardware Addresses
Agile View Parallel SCSI Hardware Addresses

• Agile View SCSI hardware addresses are similar to legacy SCSI hardware addresses...
• But Agile View represents target and LUN numbers in hex rather than decimal form
1/0/0/2/0.0xa.0x0
HBA hardware address Target LUN ID
Example: the following hardware addresses represent three distinct devices on a SCSI bus
•1/0/0/2/0.0x2.0x0
•1/0/0/2/0.0x6.0x0
•1/0/0/2/0.0xa.0x0
target 2 target 6 target 10
Student Notes
Agile View hardware addresses for parallel SCSI devices are similar to legacy hardware
addresses for parallel SCSI devices, but Agile View represents target and LUN numbers in
hexadecimal rather than decimal form.
As shown in the graphic on the slide, the Agile View parallel SCSI hardware address encodes
the device’s HBA address, target address, and LUN ID.
HBA Addresses
The first part of a legacy SCSI hardware address identifies the address of the SCSI HBA to
which the device is attached. In the example on the slide, all three SCSI devices are
connected to the SCSI HBA at address 1/0/0/2/0. Thus, the hardware paths for all three
devices begin with 1/0/0/2/0.
1/0/0/2/0.2.0
1/0/0/2/0.6.0
1/0/0/2/0.10.0

Module 5
SCSI Target Addresses

Each SCSI bus supports multiple devices, each identified by a unique target address. The
next part of a SCSI device’s Agile View hardware address identifies the device’s SCSI target
address in hexadecimal form.
The graphic on the slide shows a SCSI bus with three external devices identified by target
addresses 2, 6, and 10.
1/0/0/2/0.0x2.0
1/0/0/2/0.0x6.0
1/0/0/2/0.0xa.0
When attaching an external SCSI device, it may be necessary to manually assign a target
address. Some devices use a series of binary DIP switches to set the address. Other devices
use a series of jumper pins. Consult your device documentation to determine how to set your
device’s SCSI target address.
LUN IDs
Some SCSI devices may have a single SCSI target address, with multiple addressable units
within the device. HPUX uses the last component in the Agile View SCSI hardware address
to identify the LUN ID in hexadecimal form.
For example, tape autochangers often provide access to the autochanger’s tape drive via one
LUN ID, and access to the robotic mechanism via second LUN ID.
A SCSI disk array may present multiple virtual disks, each identified by a unique LUN ID.
HPUX uses the last component in the legacy SCSI hardware address to identify the LUN ID.
Most autochangers and disk arrays today are often connected via SAS or Fibre channel
interfaces rather than parallel SCSI, so the LUN ID portion of most SCSI device hardware
paths is typically 0x0.
Most disk arrays today are connected via SAS or Fibre channel interfaces rather than parallel
SCSI, so the LUN ID portion of most SCSI device hardware paths is typically 0x0.
1/0/0/2/0.0x2.0x0
1/0/0/2/0.0x6.0x0
1/0/0/2/0.0xa.0x0

Module 5
5–43. SLIDE: Agile View FC Lunpath Hardware Addresses

(1 of 2)
Agile View FC Lunpath Hardware Addresses (1 of 2)
• Agile view provides a lunpath hardware address for each path to each LUN
• Lunpath hardware addresses encode:
− the hardware address of the server HBA used to access the LUN
− the WW Port Name of the array controller FC port used to access the LUN
− the LUN address of the target LUN
• The mass storage stack automatically recognizes and manages redundant paths
1/0/2/1/0.0x64bits.0x64bits
HBA hardware address WW Port Name LUN Address
Example: The array below has three LUNs, each accessible via four SAN paths
The next slide lists all Agile View lunpath addresses for the first LUN

Student Notes
Like the legacy mass storage stack, Agile View provides a hardware address for each path to
each LUN. Agile View calls these path-specific hardware addresses “lunpath addresses”. The
graphic on the slide shows a disk array with three LUNs, each accessible via four different
paths. The next slide lists the Agile View hardware paths that would be used to represent
LUN 1 in the graphic.
Each Agile View lunpath hardware address encodes:

• The legacy hardware address of the server HBA used to access the LUN. See the HBA
addressing discussion earlier in the chapter.
• The 64-bit WW Port Name of the array controller FC port used to access the LUN. Disk
arrays connect to a SAN via fibre channel ports on array controller cards. Arrays
typically have redundant controllers, and each controller may have multiple ports
connected to the SAN. Each array controller FC port is identified by a globally unique
WWPN, which is included in the Agile View lunpath address.

Module 5
• The target LUN’s LUN ID. The first two bits in this number identify the LUN’s LUN
addressing method, the next 14 bits represent the LUN ID number assigned to the LUN by
the array administrator, and the last 48 bits are reserved for future use. Fortunately, the
11i v3 scsimgr command may be used to automatically extract the decimal LUN ID from
the lunpath address.
-a lunid \
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
name = lunid
default =
saved =
Unlike the legacy mass storage stack, the new mass storage stack automatically recognizes
redundant paths and load balances I/O requests across lunpaths.

Module 5
5–44. SLIDE: Agile View FC Lunpath Hardware Addresses

(2 of 2)
Agile View FC Lunpath Hardware Addresses (2 of 2)
1/0/2/1/0.0x64bits.0x64bits
HBA hardware address WW Port Name LUN Address
HBA: 1/0/2/1/0
WW Port Name: 0x50001fe15003112c
LUN ID: 0x4001000000000000
HW Path: 1/0/2/1/0 . 0x50001fe15003112c . 0x4001000000000000
HBA: 1/0/2/1/0
WW Port Name: 0x50001fe150031128
LUN ID: 0x4001000000000000
HW Path: 1/0/2/1/0 . 0x50001fe150031128 . 0x4001000000000000
HBA: 1/0/2/1/1
WW Port Name: 0x50001fe15003112d
LUN ID: 0x4001000000000000
HW Path: 1/0/2/1/1 . 0x50001fe15003112d . 0x4001000000000000
HBA: 1/0/2/1/1
WW Port Name: 0x50001fe150031129
LUN ID: 0x4001000000000000
HW Path: 1/0/2/1/1 . 0x50001fe150031129 . 0x4001000000000000
Student Notes
The example on the slide shows four different SAN paths to LUN ID 1, and each path’s
corresponding legacy hardware path. The heavy black lines represent the physical path
through the SAN for each address. Note that the LUN ID is the same in all four paths, but the
HBA and WWPN portions of the lunpath address varies.

Module 5
5–45. SLIDE: Agile View FC LUN Hardware Path Addresses
Agile View FC LUN Hardware Path Addresses
• Agile View also provides a virtual LUN hardware address for disk/tape/LUN
• The LUN hardware address represents the device/LUN itself, not a path to the LUN
• Advantages:
− LUN hardware paths are unaffected by changes to the SAN topology
− The mass storage stack automatically correlates and manages redundant paths
64000/0xfa00/0x4
virtual root node virtual bus virtual LUN ID
Example: the following example shows a LUN hardware address and its associated lunpaths
• 64000/0xfa00/0x4
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000 LUN 1
LUN 2
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000 LUN 3
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
Student Notes
In addition to the lunpath hardware addresses discussed on the previous slide, Agile View
presents a virtualized LUN hardware path for each parallel SCSI device, SAS disk, and fibre
channel LUN. The LUN hardware path represents the device or LUN itself rather than a
single physical path to the device or LUN.
In the example on the slide, 64000/0xfa00/0x4 is a LUN hardware path representing a disk
array LUN. The four addresses below the LUN hardware path represent the four lunpaths
used to access the LUN.
64000/0xfa00/0x4
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
A LUN hardware path address has three components:

Module 5
• LUN hardware addresses always start with 64000, the virtual root node of all Agile View
LUN hardware addresses. This portion of the address should be consistent across all
LUN hardware paths.
• The second component in a LUN hardware address is always 0xfa00, the virtual bus
address used by all Agile View LUN hardware paths. This portion of the address should
be consistent across all LUN hardware paths, too.
• The last component in the LUN hardware path is a virtual LUN ID. The kernel
automatically assigns virtual LUN IDs, sequentially, as it identifies new LUNs. Note that
the virtual LUN ID is virtual; it is not related to the LUN ID that is encoded in lunpath
hardware addresses.
The kernel maintains a persistent WWID to Virtual LUN ID map to ensure that LUN
hardware paths remain consistent across reboots, even if the SAN topology changes.
Agile View LUN hardware paths offer several significant advantages over legacy path-based
addressing, particularly in SAN environments.
• On systems using the legacy mass storage stack, changes in the SAN topology change
device hardware paths, and may require administrator intervention to update the volume
manager and file system configuration. LUN hardware paths are unaffected by changes
to the SAN topology. Since the Agile View LUN hardware paths don’t change, changing
the SAN topology no longer requires manual changes to the volume manager or file
system configuration.
• On systems using the legacy mass storage stack, when configuring disks for use in Logical
Volume Manager, the administrator must manually add each lunpath to the LVM
configuration. The new mass storage stack automatically recognizes and manages
redundant paths.
HP encourages customers to begin using the new Agile View LUN hardware paths, although
legacy hardware paths and lunpath addresses are still supported.
The next few slides describe several 11i v3 commands for viewing the new hardware paths,
and for converting legacy addresses to their Agile View equivalents.

Module 5
5–46. SLIDE: Viewing LUN Hardware Paths via Agile View
Viewing LUN Hardware Paths via Agile View
• Question: Which disks/LUNs are available on the system?

• Answer: Execute ioscan –N to view agile view LUN hardware paths
• Standard ioscan options such as –k, -f, –C , and –H may be included, too
# ioscan –kfN [-C disk]|[-H 64000/0xfa00/0x4]

================================================================
disk 27 64000/0xfa00/0x0 esdisk CLAIMED DEVICE HP 73.4G
disk 28 64000/0xfa00/0x1 esdisk CLAIMED DEVICE DVD+-RW
disk 30 64000/0xfa00/0x4 esdisk CLAIMED DEVICE HP HSV101
Student Notes
When configuring additional disk space for applications, administrators frequently need to
know which disks are available on the system. Use the ioscan command to view legacy
device hardware addresses. Add the –N option to view Agile View LUN hardware paths and
lunpaths rather than legacy addresses. To view a kernel-cached, full listing, add –k and –f.
Adding the –C disk option limits the output to disk class devices.
Search and list all devices using legacy hardware addresses.
# ioscan
Search and list all devices using Agile View addresses.
# ioscan –N
Display a kernel-cached full list of devices using Agile View addressing.

Module 5
# ioscan –kfN
Display a kernel-cached listing of disk class devices using Agile View addressing.
# ioscan –kfNC disk

================================================================
disk 28 64000/0xfa00/0x1 esdisk CLAIMED DEVICE DVD+-RW
Display a kernel-cached listing of a device at a specific hardware path.
# ioscan –kfNH 64000/0xfa00/0x4

================================================================

Module 5
5–47. SLIDE: Viewing LUNs and their lunpaths via Agile View
Viewing LUNs and their lunpaths via Agile View

• Question: Which lunpaths are associated with each LUN hardware path?
• Answer: Execute ioscan –m lun
• Optionally provide a specific LUN hardware path via the –H option
• The command also reports the health status of each LUN
# ioscan –m lun [-H 64000/0xfa00/0x4]

disk 30 64000/0xfa00/0x4 esdisk CLAIMED DEVICE online HP HSV101
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
/dev/disk/disk30 /dev/rdisk/disk30
1/0/2/1/0.0x50001fe15003112c.0x4002000000000000
1/0/2/1/0.0x50001fe150031128.0x4002000000000000
1/0/2/1/1.0x50001fe15003112d.0x4002000000000000
1/0/2/1/1.0x50001fe150031129.0x4002000000000000
Student Notes
The new –m lun option is specifically designed to display LUNs and lunpaths. Like the
legacy ioscan command, ioscan –m lun reports each device’s class, instance, hardware
path, driver, software state, hardware state, and description.
Between the hardware type and description fields note that ioscan –m lun also reports
the disk’s health status. online indicates that the disk or LUN is fully functional. Limited,
unusable, disabled, or offline indicate that there may be a problem. See the ioscan(1m)
man page or the “Monitoring LUN Health” slide later in the module for details.
Below the LUN hardware path, the command reports all of the lunpath hardware addresses
available to access each LUN.
Below the lunpath hardware addresses, the command reports each device’s device special
files, too (eg: /dev/disk/disk30). The next module discusses device special files in
detail.

Module 5
# ioscan –m lun
Class I H/W Path Driver SW State H/W Type Health Description
====================================================================
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
1/0/2/1/0.0x50001fe15003112c.0x4002000000000000
1/0/2/1/0.0x50001fe150031128.0x4002000000000000
1/0/2/1/1.0x50001fe15003112d.0x4002000000000000
1/0/2/1/1.0x50001fe150031129.0x4002000000000000
By default, the command displays all disks and LUNs. Add the –H option to view a specific
disk or LUN.
# ioscan –m lun -H 64000/0xfa00/0x4

====================================================================
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000

Module 5
5–48. SLIDE: Viewing HBAs and their lunpaths via Agile View
Viewing HBAs and their lunpaths via Agile View

• Question: Which lunpaths are associated with each HBA?
• Answer: Execute ioscan –m hwpath
• Optionally provide a specific HBA address via the –H option
# ioscan –kfNH 1/0/2/1/0

===================================================================
fc 0 1/0/2/1/0 fcd CLAIMED INTERFACE 4Gb Dual Port FC
tgtpath 4 1/0/2/1/0.0x50001fe150031128
estp CLAIMED TGT_PATH fibre_channel target
lunpath 4 1/0/2/1/0.0x50001fe150031128.0x0
eslpt CLAIMED LUN_PATH LUN path for ctl8
lunpath 8 1/0/2/1/0.0x50001fe150031128.0x4001000000000000
eslpt CLAIMED LUN_PATH LUN path for disk30
lunpath 9 1/0/2/1/0.0x50001fe150031128.0x4002000000000000
lunpath 10 1/0/2/1/0.0x50001fe150031128.0x4003000000000000
(continues)
Student Notes
When troubleshooting SAN issues, it may also be helpful to know which lunpaths utilize a
given HBA. Use the ioscan –kfNH command, followed by the HBA hardware address, to
find out. The example below lists the lunpaths serviced by the 1/0/2/1/0 HBA. Following each
lunpath, the command reports the device special file name of the disk or LUN associated with
that lunpath. The next module discusses device special files in detail.
# ioscan -kfNH 1/0/2/1/0

===================================================================
fc 0 1/0/2/1/0 fcd CLAIMED INTERFACE HP AB379-60001
4Gb Dual Port PCI/PCI-X Fibre Channel Adapter (FC Port 1)
tgtpath 4 1/0/2/1/0.0x50001fe150031128 estp
CLAIMED TGT_PATH fibre_channel target served by fcd driver
lunpath 4 1/0/2/1/0.0x50001fe150031128.0x0 eslpt
CLAIMED LUN_PATH LUN path for ctl8
CLAIMED
LUN_PATH LUN path for disk30
CLAIMED LUN_PATH LUN path for disk31

Module 5

tgtpath 3 1/0/2/1/0.0x50001fe15003112c estp
CLAIMED TGT_PATH fibre_channel target served by fcd driver
lunpath 3 1/0/2/1/0.0x50001fe15003112c.0x0 eslpt
CLAIMED LUN_PATH LUN path for ctl8

Module 5
5–49. SLIDE: Viewing LUN Health via Agile View
Viewing LUN Health via Agile View

• Question: Are there any failed mass storage interface cards, paths, or devices?
• Answer: Execute ioscan –P health
• Optionally provide a specific LUN hardware path via –H or a specific class via -C
Check the health of disks and LUNs

# ioscan –P health [–C disk]|[-H 64000/0xfa00/0x4]
Class I H/W Path health
=====================================
disk 30 64000/0xfa00/0x4 online
Check the health of a fibre channel adapter and itr lunpaths

# ioscan -P health [-H 1/0/2/1/0]
====================================================================
fc 0 1/0/2/1/0 online
tgtpath 3 1/0/2/1/0.0x50001fe150031128 online
lunpath 1 1/0/2/1/0.0x50001fe150031128.0x0 online
lunpath 7 1/0/2/1/0.0x50001fe150031128.0x4002000000000000 standby
lunpath 9 1/0/2/1/0.0x50001fe150031128.0x4004000000000000 standby
(continues)
Student Notes
Identifying failed interfaces and devices is a critical system administration task. HP-UX
automatically displays messages in /var/adm/syslog/syslog.log, and sometimes on
the console, when the operating system encounters hardware problems. 11i v3
administrators can proactively check the state of the system’s HBAs, controllers, disks, and
LUNs any time via the ioscan –P health command. The command reports one of the
following health states for each HBA and mass storage component node in the I/O tree.
online node is online and functional
offline node has gone offline and is inaccessible
limited node is online but performance is degraded due to some links, paths, and
connections being offline
unusable an error condition occurred which requires manual intervention (for example,
authentication failure, hardware failure, and so on)

Module 5
testing node is being diagnosed
disabled node has been disabled or suspended
standby node is functional but not in use
The command may be executed several different ways.
Report the health status of all disks/LUNs.
# ioscan –P health –C disk
Report the health status of a specific disk/LUN, or fibre channel adapter.
# ioscan –P health –H 64000/0xfa00/0x4
Report the status of all fibre channel adapters.
# ioscan –P health –C fc
Report the health status of a specific fibre channel adapter and its lunpaths.
# ioscan –P health –H 1/0/2/1/0

Module 5
5–50. SLIDE: Viewing LUN Attributes via Agile View
Viewing LUN Attributes via Agile View

• Question: What is my LUN’s WWID and LUN ID?
• Answer: Use scsimgr
Use a LUN hardware path to determine a disk’s WWID

# scsimgr get_attr -a wwid [all_lun]|[-H 64000/0xfa00/0x4]
name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =
Use one of the LUN’s lunpath hardware addresses to determine a disk’s LUNID
-a lunid \
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
name = lunid
default =
saved =
Student Notes
HP-UX administrators identify devices by hardware address, but SAN administrators identify
LUNs by their globally unique WWID names and array administrator-assigned LUN IDs. To
translate Agile View addresses into WWIDs and LUN IDs, use the scsimgr command.
Obtaining WWIDs
The first example on the slide displays LUN WWID attributes. To view all LUN WWIDs,
specify the all_lun argument. Or, to view a specific LUN’s WWID, include the –H option
and a specific LUN hardware path.
# scsimgr get_attr -a wwid all_lun
SCSI ATTRIBUTES FOR LUN : /dev/rdisk/disk30
name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =

Module 5
name = wwid
current = 0x600508b400012fd20000900001900000
default =
saved =
name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =
Obtaining LUN IDs
The second example displays a LUN’s LUN ID attribute using the LUN’s Agile View lunpath
address. In order to view the LUN ID, you must provide a specific lunpath. Recall that you
can obtain a LUN’s lunpaths via the ioscan –m lun command.
-a lunid \
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
name = lunid
default =
saved =
These are just a few of the many attributes and statistics provided by the scsimgr
command. See the scsimgr(1m) man page for more options.

Module 5
5–51. SLIDE: Enabling and Disabling lunpaths via Agile View
Enabling and Disabling lunpaths via Agile View

• Goal: Disable a lunpath in preparation for removing an interface card
• Solution: Use scsimgr disable|enable
Disable a lunpath
# scsimgr -f disable
–H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
LUN path 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
disabled successfully
Determine lunpath status

# ioscan -P health -H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
===================================================================
lunpath 5 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000 disabled
Reenable a lunpath
# scsimgr enable
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
LUN path 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
enabled successfully
Student Notes
By default, the new mass storage stack interleaves access requests among lunpaths to a LUN.
When planning to remove an interface card, or when troubleshooting SAN connectivity
issues, the administrator may choose to temporarily or permanently disable one or more
lunpaths to a LUN. Use the scsimgr commands below. As long as at least one path to a
LUN remains functional, the LUN should remain accessible.
Disable a lunpath (-f = force):
# scsimgr -f disable \
–H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
LUN path 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
disabled successfully

Module 5
Determine the lunpath’s status:
# ioscan -P health \
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
===================================================================
lunpath 5 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000 disabled
Reenable a lunpath:
# scsimgr enable \
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
LUN path 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
enabled successfully

Module 5
5–52. SLIDE: Part 4: Slot Addressing
Configuring
Hardware:
Part 4: Slot Addressing
Student Notes

Module 5
5–53. SLIDE: Slot Address Overview
Student Notes
The section of the chapter discussed HP-UX hardware addresses. HP-UX hardware
addresses are useful for viewing and managing peripheral devices, LUNs, and disks.
However, the SBA/LBA/device/function components of an HP-UX hardware address don’t

provide sufficient information to determine where an interface card is physically located on
a server. When replacing a failed interface card on a Superdome server with 192 expansion
slots, identifying the right slot can be challenging!
Some entry-class servers and all mid-range and high-end HP-UX servers now enable
administrators to map an interface card’s HP-UX hardware address to a more meaningful
HP-UX slot address that identifies the card’s physical cabinet, bay, chassis, and slot address.

Module 5
5–54. SLIDE: Slot Address Components
Slot Address Components
Blowers Blowers
Backplane Power
Cell Boards
0 1 8 9 Utility Subsystem
Cabinets I/O Bay 0 I/O Bay 1
Fan0 Fan1 Fan2 Fan3 Fan4 Fan4 Fan3 Fan2 Fan1 Fan0
Chassis 1 Chassis 3 Chassis 1 Chassis 3

( slots 0-11) (slots 0-11) (slots 0-11) (slots 0-11)
Power Supplies Power and Cabling
Cabinet #0 Front Cabinet #0 Rear
Slot Address Format: Cabinet-Bay-Chassis-Slot

Slot Address Example: 0-1-3-4
Slot Address Explanation: Cabinet 0, Bay 1, Chassis 3, Slot 4
Student Notes
The slot address consists of four components, which identify an interface card’s exact
location on a system.
• The first portion of the slot address identifies a slot’s cabinet number. As shown on the
slide, a Superdome complex may have one or two system cabinets, and two additional I/O
expansion (IOX) cabinets. Superdome interface card slots in the first cabinet will have a
0 in cabinet portion of the slot address. Superdome interface card slots in the second
cabinet will have a 1 in the cabinet portion of the slot address. Interface cards in the
expansion cabinets will have an 8 or 9 in the first portion of the slot address. On non-
Superdome systems, the cabinet number will always be 0.
• The second component of the slot address identifies the slot’s I/O bay. Each Superdome
cabinet has two I/O bays. I/O bay 0 is located on the front of the cabinet, and I/O bay 1 is
located in the rear of the cabinet. Each Superdome IOX cabinet can have three vertically
stacked I/O bays, numbered 1 to 3 from bottom to top. Additional space in the IOX can
be used to install peripheral devices. On non-Superdome systems, the I/O bay number
will always be 0. The diagram below shows the location of the I/O bays on the front and
back of a Superdome cabinet.

Module 5
• The third component of the slot address identifies the slot’s I/O chassis number. Each I/O
bay contains up to two I/O chassis. On Superdome systems, the I/O chassis are physically
distinct components; the chassis on the left is I/O chassis 1 and the I/O chassis on the
right is I/O chassis 3. On the rp7xxx, rx7xxx, rp8xxx, and rx8xxx servers, there are two
logical I/O chassis are numbered 0 and 1, but they are located in a single physical card
cage.
• The fourth component of the slot address identifies the slot number. Each Superdome
I/O chassis has twelve slots, numbered 0- 11. On rp7xxx, rx7xxx, rp8xxx, and rx8xxx
servers, each I/O chassis has eight slots numbered 1-8.

Module 5
5–55. SLIDE: Viewing Slot Addresses
Viewing Slot Addresses

Use rad (11i v1) or olrad (11i v2 and v3) to view slot addresses and properties
# olrad -q
Driver(s) Capable
Num Spd Mode
# rad -q
Slot Path Bus Speed Power Occupied Suspended Capable
0-0-0-1 0/0/8/0 64 66 On Yes No Yes
0-0-0-2 0/0/10/0 80 66 On Yes No Yes
0-0-0-3 0/0/12/0 96 66 On Yes No Yes
Student Notes
You can view slot addresses and correlate those addresses to HP-UX hardware addresses via
the rad command (11i v1) or olrad command (11i v2 and v3). These commands are only
available on servers that support slot addressing.
For each slot, the commands report the following columns:
Slot The Slot column reports the slot’s slot address.
Path The Path column reports the slot’s corresponding HP-UX hardware path.
Bus Num The Bus Num column reports the slot’s bus number.
Max Spd The Max Spd column reports the maximum speed (MHz) supported by the
slot.
Spd The Spd column reports the maximum speed (MHz) supported by the card
currently in the slot.

Module 5
Pwr The Pwr column reports the power status of the slot. Slots can be powered
up/down to facilitate I/O card replacement. This functionality will be
described in detail later in the chapter.
Occu Is the slot currently occupied by an interface card?
Susp The Susp column identifies slots in the suspended state. A card must be
suspended before it can be replaced.
OLAR The OLAR column (olrad) or Capable column (rad) indicates if the slot
supports HP’s OL* online card addition and replacement functionality.
OLD The OLD column (olrad) indicates if the slot supports HP’s OL* online
card delete functionality. This feature is new in 11i v3.
Max Mode The Max Mode column distinguishes PCI-X slots from PCI slots.

Module 5
5–56. SLIDE: Part 6: Managing Cards and Devices
Configuring
Hardware:
Part 6: Managing Cards and Devices
Student Notes

Module 5
5–57. SLIDE: Installing Interface Cards w/out OL* (11i v1, v2, v3)
Installing Interface Cards w/out OL* (11i v1, v2, v3)
In order to add, replace, or remove non OL* interface cards,

shutdown and power-off the system, then add/replace/remove the card
Installing a new interface card without OL*:
Verify card compatibility

Verify that the required driver is configured in the kernel
Properly shutdown and power off the system
Install the interface card
Power up
Run ioscan to verify that the card is recognized
Student Notes
The procedures on this and the following two slides describe how to properly install
additional interface cards.
On some entry-class servers, you must shutdown and power-off your system as described
below in order to add, remove, or replace an interface card. On servers that support HP’s
Online Addition and Replacement (OL*) functionality, you can shutdown a single card slot
without shutting down your entire server. The OL* process is described over the next couple
slides.

Module 5
Installing a new interface card without OL* is a multi-step process:

1. Verify card compatibility. HP servers support a variety of I/O expansion buses. Make
sure your new interface card matches the card slot that you intend to use. See your
owner's manual or server QuickSpecs to determine which card types can be used in each
card slot.
2. Verify that the required driver is configured in the kernel. Check your interface card
documentation to determine what driver is required, then use sam or kcweb to determine
if the required driver is configured in your kernel. A later chapter in this course discusses
kernel configuration in detail.
3. Use the shutdown command to properly shut down the system. When you see a
message indicating that it is safe to power-off, either press the power button, or use the
Management Processor power control (pc) command to power-off your system.
# shutdown –hy 0
4. Install the interface card. Static discharge can easily damage interface cards. Be sure to
follow the anti-static guidelines that come with your interface card.
5. Power-up the system.
6. During the system boot process, the kernel should scan the system for new interface
cards and devices. Use ioscan -kfn to verify that the system recognized the new
interface card. Does your new device appear in the device list? Is the new device
CLAIMED? If not, it may be necessary to add a new driver to the kernel. See our kernel
configuration chapter later in the course!
WARNING: Always check your support agreement before opening the cabinet of
any HP system. Attempting to service hardware components without
the assistance of an HP engineer may invalidate your warranty or
support agreement.

Module 5
5–58. SLIDE: Installing Interface Cards with OL* (11i v1)
Installing Interface Cards with OL* (11i v1)
HP’s OL* technology make it possible to add and replace interface cards
without rebooting
Installing a new interface card with OL* in 11i v1:

Go to the SAM "Peripheral Devices -> Cards" screen
Select an empty slot from the object list
Select "Actions -> Light Slot LED" to identify the card slot
Select "Actions -> Add" to analyze the slot
Insert the card as directed
Wait for SAM to power on, bind, and configure the card
Check ioscan to verify that the card is recognized
Student Notes
Prior to HP-UX 11i, adding or removing an interface card always required a system reboot, as
described in the process on the preceding slide. HP-UX 11i v1 introduced a new technology
called "Interface Card Online Addition and Replacement" (OL*), which provides the ability to
add and replace PCI interface cards without a system reboot. HP-UX 11i v3 enables the
administrator to permanently remove interface cards without rebooting, too.
The OL* functionality is currently only supported by selected interface cards, on selected
servers running HP-UX 11i v1, v2, and v3. See your system hardware manual to determine if
your server supports this functionality. The notes below describe the OL* process on 11i v1.
The next slide describes the 11i v2 and v3 OL* process.
Installing a New Interface Card with OL*

Installing an interface card using the new OL* functionality is a multi-step process that may
be performed from the command line via the /usr/bin/rad command, or by using the SAM
GUI/TUI. HP strongly recommends using SAM for OL* administration. The procedure for
adding an OL* interface card via SAM is described below. If you prefer to work from the

Module 5
command line, see chapter 2 in HP's Configuring Peripherals for HP-UX manual on
http://docs.hp.com.
1. Verify card compatibility. Check the documentation accompanying your interface card to
verify that the card is OL* compatible. Check your system owner's manual for details.
2. Verify that the required driver is configured in the kernel. Without the proper driver
configured, you may be able to physically install the card, but the card will be unusable.
Check your interface card documentation to determine what driver is required, then use
the sam -> Kernel Configuration -> Drivers screen to determine if the
required driver is configured in your kernel. A later chapter will describe the process
required to add a new driver.
3. Go to the sam -> Peripheral Devices -> Cards screen. This screen lists all of
the interface cards installed on your system, and includes several items in the Actions
menu for managing OL* interface cards.
+------------------------- Cards ---------------------------------+
|File View Options Actions Help |
|I/O Cards 2 of 23 selected|
|-----------------------------------------------------------------|
| Hardware Slot |
| Slot Path Driver State Power Description |
|+--------------------------------------------------------------+ |
|| - 0/0/2/1 c720 not OLAR-able - SCSI C87x Fast Wid | |
|| - 0/0/4/0 func0 not OLAR-able - PCI BaseSystem (10 | |
|| - 0/0/4/1 asio0 not OLAR-able - Service Processor | |
|| 5 0/2/0 - - on empty slot | |
|| 6 0/5/0 - - on empty slot | |
|| 7 0/1/0 - - on empty slot | |
|| 8 0/3/0 - - on empty slot | |
|| 9 0/9/0/0 c8xx active on SCSI C1010 Ultra W | |
|+--------------------------------------------------------------+ |
+-----------------------------------------------------------------+
4. Select an empty slot from the object list. Slots that are available for use by new interface
cards should be marked either empty slot or unclaimed card in the Description
field. Select one of these slots.
+------------------------- Cards ---------------------------------+
|File View Options Actions Help |
|I/O Cards 2 of 23 selected|
|-----------------------------------------------------------------|
| Hardware Slot |
| Slot Path Driver State Power Description |
|+--------------------------------------------------------------+ |
|| - 0/0/2/1 c720 not OLAR-able - SCSI C87x Fast Wid | |
|| - 0/0/4/0 func0 not OLAR-able - PCI BaseSystem (10 | |
|| - 0/0/4/1 asio0 not OLAR-able - Service Processor | |
|| 5 0/2/0 - - on empty slot | |
|| 6 0/5/0 - - on empty slot | |
|| 7 0/1/0 - - on empty slot | |
|| 8 0/3/0 - - on empty slot | |

Module 5

|+--------------------------------------------------------------+ |
+-----------------------------------------------------------------+
5. Select Actions -> Light Slot LED to identify the card slot on the system
backplane. This should light an LED on the selected PCI slot to indicate which slot
should be used for the new interface card.
6. Select Actions -> Add to analyze the slot. In order to insert the new interface card,
the selected PCI slot must be powered down. On some servers, multiple slots may share
a common "power domain". Slots within a power domain are powered on or off as a unit.
Powering off the power domain containing the interface card for the system boot disk or
other critical system resources could be disastrous! SAM automatically analyzes the
selected slot's power domain to ensure that it is safe to temporarily disable the power
domain while the new card is being added.
7. Insert the card as directed by SAM.
8. SAM will power-on the card, identify and "bind" an appropriate kernel driver, and run a
post addition script to finish configuring the card, if necessary.
9. Check ioscan to verify that the card is recognized. Does the card appear in the
hardware list? Is it CLAIMED?
Other OL* Possibilities

OL* also makes it possible to replace interface cards without rebooting. Simply select the
Actions -> Replace menu item rather than Actions -> Add. There are some
restrictions, however. Generally speaking, the replacement card must be identical to the
original card.
For Further Study

See the Configuring Peripherals for HP-UX" manual on http://docs.hp.com for more
information regarding OL* procedures.
WARNING: Be sure to check your support agreement before opening the cabinet
of an HP system. Attempting to service hardware components without
the assistance of an HP engineer may invalidate your warranty or
support agreement.

Module 5
5–59. SLIDE: Installing Interface Cards with OL* (11i v2, v3)
Installing Interface Cards w/ OL* (11i v2, v3)
HP’s mid- and high-end servers’ OLAR technology make it possible to

add, replace, and remove interface cards without rebooting
Installing a new interface card with OLAR:

Go to the SMH "Peripheral Device Tool -> OLRAD Cards" screen
Select an empty slot
Click “Turn On/Off Slot LED”
Click “Add Card Online”
Click “Run Critical Resource Analysis”
Click “Power Off” to power-off the slot
Insert the new card
Click “Bring Card Online”
Check ioscan to verify that the card is recognized
Student Notes
Installing an OL* capable interface card in 11i v2 and v3 is a multi-step process that may be
performed from the command line via the /usr/bin/olrad CLI utility or the SMH GUI/TUI
interfaces. The procedure for adding an OL* interface card via the SMH is described below.
1. Verify card compatibility. Check the documentation accompanying your interface card to
verify that the card is OL* compatible. Check your system's hardware manual for details.
2. Verify that the required driver is configured in the kernel. Without the proper driver
configured, you may be able to physically install the card, but the card will be unusable.
Check your interface card documentation to determine what driver is required. A later
chapter will describe the process required to view and add drivers.
3. Launch the SMH and access the “OLRAD Cards” tab on the “Peripheral Device Tool”. To
learn more about enabling and launching the SMH see the SMH chapter elsewhere in this
course. Login using the root username and password.
# firefox http://server:2301/ Launch the GUI

# smh Launch the TUI

Module 5
Select an empty slot from the object list. Slots that are available for use by new interface
cards should report no in the Occupied column.
4. Click Turn On/Off Slot LED. Check the slot LEDs on the backplane of your system
to verify that you selected the right slot.
5. Click Add Card Online. This should display a dialog box similar to the following:
6. Click Run CRA (Critical Resource Analysis) to analyze the slot. In order to insert the
new interface card, the selected PCI slot must be powered down. On some servers,
multiple slots may share a common OL* "power domain". Slots within a power domain
are powered on or off as a unit. Powering off the power domain containing the interface
card for the system boot disk or other critical system resources could be disastrous!
pdweb automatically analyzes the selected slot's power domain to ensure that it is safe to
temporarily disable the power domain while the new card is being added. A CRA may
report several different outcomes:

Module 5
System Critical Impacts: Performing an OL* operation on the selected slot will likely
impact /, /stand, /usr, or /etc file systems, or a swap
device. Proceeding with the OL* operation may crash or
significantly degrade system performance.
Data Critical Impacts: Performing an OL* operation on the selected slot will likely
impact one or more locally mounted file systems, open device
files, or non-suspended network interface cards. Proceeding
with the OL* operation may cause data corruption. Loss of a
CDFS file system will not trigger a Data Critical CRA warning.
Other Impacts: Performing an OL* operation on the selected slot may impact
unused logical volumes, CDFS file systems, cards protected by
high-availability resources, networking cards that are
suspended, or one path to a multi-pathed logical volume.
Success: Performing an OLR operation on the selected slot won’t impact

any currently used resources.
Error: An internal olrad error occurred.

7. If the CRA succeeds, you should see a screen like this:
8. Insert the new card. Ensure that the card slot latch is closed firmly.
9. Click Bring Card Online

Module 5
10. Finally, check ioscan -f to verify that the card is recognized. Does the card appear in
the hardware list? Is it CLAIMED?
Replacing an Interface Card

OL* also makes it possible to replace interface cards without rebooting. Simply select an OL*
capable card from the SMH “OLRAD Cards” tab, and select the Replace Card Online link
on the main menu and follow the prompts in the dialog boxes that follow.
There are some restrictions, however.
When replacing an interface card online, you must use an identical replacement card. This is
referred to as like-for-like replacement. Using a similar but not identical card can cause
unpredictable results. For example, a newer version of the target card with identical
hardware may use a newer firmware version that may conflict with the current driver. If a
new card is not acceptable, the system will report that the card cannot be resumed, and
olrad/pdweb will return an error.
During the replacement process, the driver instance for each port on the target card runs in a
suspended state. I/O to the ports is either queued or failed while the drivers are suspended.
When the replacement card comes online, the driver instances resume normal operation.
Each driver instance must be capable of resuming and controlling the corresponding port on
the replacement card.
The PCI specification enables a single physical card to contain more than one port.
Attempting to replace a card with another card that has more ports can result in the
additional ports being claimed by other drivers if an ioscan occurs when slot power is on.
Removing a Card
In 11i v3, OL* also enables the administrator to permanently remove an interface card
without rebooting. Ensure that the card isn’t currently being used, then select the card in the
SMH interface and select the Delete Card Online link on the main menu.
During the deletion process, the driver instance for each port on the target card is suspended.
I/O to the ports are either queued or failed while the drivers are suspended. When the card is
removed, the driver instances are deleted.
For Further Study

See the Interface Card OL* Support Guide on http://docs.hp.com for more information
regarding OL* procedures.
WARNING: Be sure to check your support agreement before opening the cabinet
of any HP system. Attempting to service hardware components
without the assistance of an HP engineer may invalidate your warranty
or support agreement.

Module 5
5–60. SLIDE: Installing New Devices (11i v1, v2, v3)
Installing New Devices (11i v1, v2, v3)

• LUNs and “Hot-pluggable” devices can be added to a system without rebooting
• “Non-hot-pluggable” devices require a system reboot
Configuring a new LUN or hot-pluggable device

Verify device compatibility
Connect or configure the device
Run ioscan to add the device to the kernel I/O tree (not necessary in 11i v3)
Run insf to create device files (not necessary in 11i v3)
Run ioscan –kfn or ioscan –kfnN to verify the configuration
Configuring a new non-hot-pluggable device

Verify device compatibility
Shutdown and power off the system
Connect the device
Power-on and boot the system
Run ioscan –kfn or ioscan –kfnN to verify the configuration
Student Notes
After installing a new interface card, you may choose to attach new devices, too. The
procedures below explain the process to install both “hot-pluggable” and “non-hot-pluggable”
devices.
Configuring a New LUN or Hot-Pluggable Device

Many devices today, such as the media bays on most of the current servers, are “hot-
pluggable”. Hot pluggable devices can be installed or removed without shutting down the
system. If you create or remove LUNs on a Storage Area Network, this same procedure may
be used to force HP-UX to recognize the new configuration.
1. Verify device compatibility. Check HP’s website or call the response center to verify that
the device is supported on your system.
2. Verify that the required driver is configured in the kernel via sam (11i v1) or kcweb (11i
v2 and v3).
3. Connect or configure the device.

Module 5
4. Run ioscan to add the device to the kernel iotree. Don’t include the –u or –k options; in
order to recognize the new device, ioscan must scan the buses rather than simply report
the devices already recorded in the iotree.
5. Run insf to create device files. Device files allow users and applications to access
peripheral devices. Device files are discussed in detail in the next chapter.
NOTE: Even if a card is hot-pluggable, you must shutdown any daemons using the
device before you remove the device.
Configuring a New Non-Hot-Pluggable Device

In order to install some devices, a reboot may be required.
1. Verify device compatibility. Check HP’s website or call the response center to verify that
the device is supported on your system.
2. Verify that the required driver is configured in the kernel via sam (11i v1) or kcweb (11i
v2).
3. Shutdown and power off the system.
4. Connect the device.
5. Power-on and boot the system.
6. Run ioscan to verify auto-configuration. Verify that the device appears in the ioscan
output and is CLAIMED.
Additional Configuration
Some additional configuration may be required after physically connecting a new device.
Terminals and modems may require new device files. Disks may need to be partitioned
before they may be used. The next couple chapters will discuss these additional
configuration tasks in detail.

Module 5
5–61. LAB: Exploring the System Hardware
Directions
The ioscan command is a powerful tool for exploring your system's hardware
configuration.
Part 1: Exploring your System Configuration

You may do this part of the lab after your instructor completes lecture Part 2.
Your goal in this part of the lab is to explore your assigned lab system’s configuration.
Carefully record the commands you use to obtain the information requested below.
1. Login as root on your assigned server.
2. Execute the model command to determine your system’s model string. Consult the table
of HP server types earlier in the chapter to determine whether your system is an entry
class, blade, mid-range, or high-end server.
3. Execute machinfo to determine your system’s processor type and speed. Some older
PA-RISC systems do not support machinfo. If your system generates an error message,
skip this question.
4. Execute machinfo to determine the amount of physical memory on your system. Some
older PA-RISC systems do not support machinfo. If your system generates an error
message, you can determine the amount of physical memory by executing dmesg |grep
–i physical.

Module 5
5. Execute ioscan –C cell to determine how many (if any) cell boards you have on your
system.
6. Execute ioscan –C processor to determine how many processor cores you have on
your system.
7. Execute ioscan –C lan to determine how many LAN interfaces you have on your
system.
8. Execute ioscan –C disk to determine how many disk class devices you have on your
lab system.
9. DVDs and CDROMs are disk class devices, too. Execute ioscan –C disk and look in
the Description column for the string DVD or DV to determine if you have a DVD drive.
10. Are there any parallel SCSI buses on your system? Execute ioscan –C ext_bus to
view external bus type components. Look in the Description column for the string
“SCSI”.

Module 5
Part 2: Legacy and Agile View Hardware Addressing

1. Execute the ioscan command to view your system configuration. Try the command
with each of the options listed below. View the results and explain the significance of
each option. Check the man page if you need to.
# ioscan
# ioscan -f
# ioscan –N
# ioscan –k
# ioscan -kfN
2. Does your system have any SCSI ext_bus’es? If so, can you determine their hardware
paths?
# ioscan –kfNC ext_bus
3. Skip this question if your system does not have SCSI buses. If your system does have one
or more SCSI buses, how many devices are on the first bus? Execute the command
below to find out. Replace the hardware path below with the first SCSI bus hardware
path you discovered in the previous step.
# ioscan -kfNH n/n/n/n
4. Skip this question if your system does not have any SCSI buses. If you add a new device
to the SCSI bus you explored in the previous step, which SCSI target addresses have
already been claimed by existing devices on the bus?
5. 11i v3’s new mass storage stack introduced some helpful new tools for managing disks
and LUNs, particularly on systems with multi-pathed devices. Execute ioscan –m lun

Module 5
to determine which disks (if any) on your system are multi-pathed. If so, how many paths
lead to each disk/LUN?
# ioscan –m lun
6. Choose a disk or LUN from the ioscan –m lun output above and record its LUN
hardware path and one of its lunpath hardware addresses below. If your system has
multi-pathed LUNs, use one of the multi-pathed LUNs.
LUN hardware path: ___________________________________________
lunpath hardware path: ___________________________________________
Conceptually, what is the difference between a LUN hardware address and a lunpath
hardware address?
7. Recall that ioscan –m lun also reports each LUN’s health status. Are any of your
LUNs currently disabled?
# ioscan –m lun
8. When troubleshooting SAN problems, your storage administrators may ask you to
determine a LUN’s WWID. Execute the command below to determine the WWID of the
disk or LUN you selected in the previous question.
# scsimgr get_attr -a wwid -H 64000/0xfa00/0x___

Module 5
9. You may also be asked to determine a LUN’s LUN ID. Use the lunpath hardware address
that you selected previously to determine the LUN’s LUN ID.
# scsimgr get_attr -a lunid –H ________________________________________

Module 5
Part 3: HP-UX Slot Addressing

Since some lab systems may not support OL* functionality, use the sample olrad –q output
below to answer the OL* questions that follow. This abbreviated output came from a
Superdome server.
A message in the /var/adm/syslog/syslog.log file suggests the interface card at

hardware address 2/0/3/1 may need to be replaced. Your goal in the questions below is to
determine where the problem card is physically located in the Superdome complex
# olrad –q
1. Which slot address corresponds to hardware path 2/0/3/1?
2. If the complex has two cabinets, which cabinet is the card in?
3. Is the card’s I/O bay in the front or back of the cabinet?
4. Within the I/O bay, is the card’s I/O chassis on the left or right?
5. Which slot is the card in?

Module 5
6. Based on the output above, is it safe to remove the card from the chassis now?
7. Execute the olrad –q command. Does your lab system support OL* functionality?
# olrad –q

Module 5
Part 4: (Optional) Viewing Peripheral Devices via the SMH

If time permits, explore the Peripheral Devices functional area in the SMH.
In the HP Virtual Lab, use the SMH button that is available from the reservation window to
open an SMH browser.
click "Peripheral Devices"
A similar Peripheral Devices SAM SAM functional area exists in sam in earlier versions
of HP-UX.

Module 5
Part 6: (Optional) Exploring Quickspecs

External web sites are not available from within the HP virtual lab, and may not be accessible
from all classrooms. Skip this part of the lab if you do not have public Internet access.
1. If time permits, visit the http://www.hp.com/go/servers website.

Go to the Integrity servers page on the website.
See if you can find the QuickSpecs page for one or two server models.
If you need help finding the QuickSpecs, ask your instructor.
2. Also have a look at some of the hardware documentation available at

http://docs.hp.com/en/hw.html.

Module 5
5–62. LAB SOLUTIONS: Exploring the System Hardware
Directions
The ioscan command is a powerful tool for exploring your system's hardware
configuration.
Part 1: Exploring your System Configuration

Your goal in this part of the lab is to explore your assigned lab system’s configuration.
Carefully record the commands you use to obtain the information requested below.
1. Login as root on your assigned server.
2. Execute the model command to determine your system’s model string. Consult the table
of HP server types earlier in the chapter to determine whether your system is an entry
class, blade, mid-range, or high-end server.
Answer:
# model
3. Execute machinfo to determine your system’s processor type and speed. Some older
PA-RISC systems do not support machinfo. If your system generates an error message,
skip this question.
Answer:
# machinfo
4. Execute machinfo to determine the amount of physical memory on your system. Some
older PA-RISC systems do not support machinfo. If your system generates an error
message, you can determine the amount of physical memory by executing dmesg |grep
–i physical.
Answer:
# machinfo
5. Execute ioscan –C cell to determine how many (if any) cell boards you have on your
system.
Answer:
# ioscan –C cell
6. Execute ioscan –C processor to determine how many processor cores you have on
your system.

Module 5
Answer:
# ioscan –C processor
7. Execute ioscan –C lan to determine how many LAN interfaces you have on your
system.
Answer:
# ioscan –C lan
8. Execute ioscan –C disk to determine how many disk class devices you have on your
lab system.
Answer:
# ioscan –C disk
9. DVDs and CDROMs are disk class devices, too. Execute ioscan –C disk and look in
the Description column for the string DVD or DV to determine if you have a DVD drive.
Answer:
# ioscan –C disk
10. Are there any parallel SCSI buses on your system? Execute ioscan –C ext_bus to
view external bus type components. Look in the Description column for the string
“SCSI”.
Answer:
# ioscan –C ext_bus

Module 5
Part 2: Legacy and Agile View Hardware Addressing

1. Execute the ioscan command to view your system configuration. Try the command
with each of the options listed below. View the results and explain the significance of
each option. Check the man page if you need to.
# ioscan
# ioscan -f
# ioscan –N
# ioscan –k
# ioscan -kfN
Answer:
When executed without any options, ioscan scans the buses and reports each hardware
component’s legacy hardware path, class, and description.
The –f option adds several additional columns to the output, including the driver name,
instance number, SW State, and HW Type.
The –N option displays Agile View hardware addresses rather than legacy hardware
addresses.
The –k option displays cached information. On a large system, ioscan executes

significantly faster with the –k than it does without the –k option.
The last example combines the last three options to display a full listing of Agile View
hardware paths using kernel cached information. This is one of the most popular
permutations of the ioscan command.
2. Does your system have any SCSI ext_bus’es? If so, can you determine their hardware
paths?
# ioscan –kfNC ext_bus
Answer:
Answers will vary.
3. Skip this question if your system does not have SCSI buses. If your system does have one
or more SCSI buses, how many devices are on the first bus? Execute the command
below to find out. Replace the hardware path below with the first SCSI bus hardware
path you discovered in the previous step.
# ioscan -kfNH n/n/n/n
Answer:
Answers will vary.

Module 5
4. Skip this question if your system does not have any SCSI buses. If you add a new device
to the SCSI bus you explored in the previous step, which SCSI target addresses have
already been claimed by existing devices on the bus?
Answer:
Look at the second to last component in each SCSI device address to determine which
target addresses are already taken. There must not be duplicate SCSI target addresses on
a SCSI bus.
5. 11i v3’s new mass storage stack introduced some helpful new tools for managing disks
and LUNs, particularly on systems with multi-pathed devices. Execute ioscan –m lun
to determine which disks (if any) on your system are multi-pathed. If so, how many paths
lead to each disk/LUN?
# ioscan –m lun
Answer:
If ioscan lists multiple lunpaths below an Agile View LUN hardware path, the LUN is
multi-pathed.
6. Choose a disk or LUN from the ioscan –m lun output above and record its LUN
hardware path and one of its lunpath hardware addresses below. If your system has
multi-pathed LUNs, use one of the multi-pathed LUNs.
LUN hardware path: ___________________________________________
lunpath hardware path: ___________________________________________
Conceptually, what is the difference between a LUN hardware address and a lunpath
hardware address?
Answer:
A LUN hardware path represents a disk or LUN. A lunpath hardware address represents
a single path to a disk or LUN. Each LUN has one LUN hardware path, but may have
multiple lunpath hardware addresses.
7. Recall that ioscan –m lun also reports each LUN’s health status. Are any of your
LUNs currently disabled?
# ioscan –m lun
Answer:
All of the LUNs should be online.
8. When troubleshooting SAN problems, your storage administrators may ask you to
determine a LUN’s WWID. Execute the command below to determine the WWID of the
disk or LUN you selected in the previous question.

Module 5
# scsimgr get_attr -a wwid -H 64000/0xfa00/0x___
Answer:
Answers may vary.
9. You may also be asked to determine a LUN’s LUN ID. Use the lunpath hardware address
that you selected previously to determine the LUN’s LUN ID.
# scsimgr get_attr -a lunid –H ________________________________________
Answer:
Answers may vary.

Module 5
Part 3: HP-UX Slot Addressing

Since some lab systems may not support OL* functionality, use the sample olrad –q output
below to answer the OL* questions that follow. This abbreviated output came from a
Superdome server.
A message in the /var/adm/syslog/syslog.log file suggests the interface card at

hardware address 2/0/3/1 may need to be replaced. Your goal in the questions below is to
determine where the problem card is physically located in the Superdome complex
# olrad –q
1. Which slot address corresponds to hardware path 2/0/3/1?
Answer:
Slot address 0-1-3-2.
2. If the complex has two cabinets, which cabinet is the card in?
Answer:
Cabinet 0, which is usually on the left when facing the front of the complex.
3. Is the card’s I/O bay in the front or back of the cabinet?
Answer:
Bay 1, which is on the rear side of the cabinet.
4. Within the I/O bay, is the card’s I/O chassis on the left or right?
Answer:
Chassis 3, which is on the right side of the I/O bay.
5. Which slot is the card in?
Answer:
Slot 2.
6. Based on the output above, is it safe to remove the card from the chassis now?

Module 5
Answer:
Since the card is powered on and is not suspended, you should not remove the card.
7. Execute the olrad –q command. Does your lab system support OL* functionality?
# olrad –q
Answer:
If you get a message reporting “Capability not implemented; Could not obtain information
of all slots”, your server doesn’t support OL*. If you get a list of card slots, your server
does support OL*.

Module 5
Part 4: (Optional) Viewing Peripheral Devices via the SMH

If time permits, explore the Peripheral Devices functional area in the SMH.
In the HP Virtual Lab, use the SMH button that is available from the reservation window to
open an SMH browser.
click "Peripheral Devices"
A similar Peripheral Devices SAM SAM functional area exists in sam in earlier versions
of HP-UX.

Module 5
Part 6: (Optional) Exploring Quickspecs

External web sites are not available from within the HP virtual lab, and may not be accessible
from all classrooms. Skip this part of the lab if you do not have public Internet access.
1. If time permits, visit the http://www.hp.com/go/servers website.

Go to the Integrity servers page on the website.
See if you can find the QuickSpecs page for one or two server models.
If you need help finding the QuickSpecs, ask your instructor.
2. Also have a look at some of the hardware documentation available at

http://docs.hp.com/en/hw.html.

Module 5

Module 6 ⎯ Configuring Device Files
Objectives
• Explain the purpose of a Device Special File (DSF).
• Explain the significance of major and minor numbers, and block and character I/O.
• Compare and contrast legacy versus persistent DSFs.
• Describe the legacy DSF naming convention for disks, LUNs, DVDS, tapes, autochangers,
terminals, modems.
• Describe the persistent DSF naming convention for disks, LUNs, DVDS, tapes, and
autochangers.
• Use lsdev to list kernel driver major numbers.
• Use ll to determine a device file's major and minor numbers.
• Use ioscan to list legacy and persistent DSFs associated with devices.
• Use lssf to interpret the characteristics of legacy and persistent DSFs.
• Create DSFs via autoconfiguration, insf, mksf, and mknod.
• Remove DSFs via rmsf.

Module 6
Configuring Device Files
6–1. SLIDE: Device Special File Overview
Device Special File Overview

• Applications access peripheral devices via “Device Special Files” (DSFs)
• Advantages:
− Applications can access devices using standard file access system calls
− Applications can access devices with minimal knowledge of the system hardware
UNIX Commands Device

Files Kernel
Applications
reference /dev/rtape/tape0_BEST references

device special files physical devices
Student Notes
UNIX applications access peripheral devices such as tape drives, disk drives, printers,
terminals, and modems via special files in the /dev directory called Device Special Files
(DSFs). Every peripheral device typically has one or more DSFs.
The same read() and write() system calls used to read or write data to a disk-based file
can also be used to read or write data to a tape drive, terminal device, or any other device via
the device’s DSF. This allows application developers to easily access peripheral devices
using familiar system calls, with minimal knowledge of the system’s underlying hardware
architecture.
The following examples demonstrate the use of DSFs by HP-UX commands:
# tar -cf /dev/rtape/tape0_BEST /home
The tar application creates (-c) a backup archive on the file specified by the -f option.
Since device files allow applications to access devices using the same system calls that are

Module 6
used to access files, the –f option may be used to write a tar archive to either a tape drive
(e.g.: /dev/rtape/tape0_BEST) or a disk-based file (e.g.: /tmp/archive.tar).
This second example redirects standard output of the echo command to a terminal via the
terminal’s device file.
# echo hello > /dev/tty0p0
NOTE: The terms “Device Special File”, “DSF”, “Device File”, and “Special File” are
used interchangeably.

Module 6
6–2. SLIDE: DSF Attributes
DSF Attributes
DSF file attributes determine which device a DSF accesses, and how
• Type: Access the device in block or character mode?
• Permissions: Who can access the device?
• Major#: Which kernel driver does the DSF use?
• Minor#: Which device does the DSF use? And how?
• Name: What is the DSF name?
Use ll to view a device file’s attributes
# ll /dev/*disk/disk*
brw-r----- 1 bin sys 3 0x000004 Jun 23 00:34 /dev/disk/disk30
brw-r----- 1 bin sys 3 0x000005 Jun 23 00:34 /dev/disk/disk31
crw-r----- 1 bin sys 22 0x000004 Jun 23 00:34 /dev/rdisk/disk30
crw-r----- 1 bin sys 22 0x000005 Jun 23 00:34 /dev/rdisk/disk31
Type Permissions Major# Minor# Device File Names
Translate major#s to device # lsdev

driver names with lsdev Character Block Driver Class
22 3 esdisk disk
23 -1 estape tape
Student Notes
Every file on a UNIX system has an associated structure called an inode that records the file’s
owner, group, permissions, size, and other attributes. Every DSF also has an inode. Some
DSF file attributes are similar to regular file attributes; others are DSF-specific. The ll
command may be used to view the file attributes associated with both data files and DSFs.
The notes below highlight some of the significant DSF file attributes.
DSF File Types

The very first character in the ll output for a device file indicates the device file type. File
type “d” identifies directories. File type “-“ identifies regular files. File types “c” and “b” are
DSF-specific.
Character Device Files File type "c" identifies character mode DSFs. Character mode DSFs
transfer data to the device one character at a time. Devices such as
terminals, printers, plotters, modems, and tape drives are typically
accessed via character mode DSFs. Character mode DSFs are
sometimes called "raw" device files.

Module 6
Block Device Files File type "b" identifies a block mode DSFs. When accessing a
device via a block mode DSF, the system reads and writes data
through a buffer in memory, rather than transferring the data
directly to the physical disk. This can significantly improve I/O for
disks, LUNs, and CD-ROMs. Block device files are sometimes called
"cooked" device files.
Terminals, modems, printers, plotters, and tape drives typically only have character device
files. Disks, LUNs, and CD-ROMs may be accessed in either character or block mode, and
thus typically have both types of device files. Some applications and utilities prefer to access
disks directly via character mode DSFs. Other utilities require a block mode DSF. Read the
application or utility documentation to determine which device file is required.
DSF File Permissions

Just as file permissions determine which users can access regular files, file permissions also
determine which users can access DSFs. In the example below, world write privileges on the
/dev/console device file suggest that any user could write messages to the administrator’s
system console device.
# ll /dev/console
crw--w--w- 1 root sys 0 0x000000 Jun 27 13:17 /dev/tty0p0
Recall that the mesg n command prevents other users from sending message to the local
terminal device. mesg accomplishes this by changing the permissions on the user’s terminal
device file.
# mesg n
# ll /dev/console
crw------- 1 root sys 0 0x000000 Jun 27 13:17 /dev/console
Though administrators can change DSF file permissions, it’s generally best to retain the
permissions applied by the insf and mksf commands when they initially create DSFs.
Device File Major Numbers

Every device file has a "major number" that appears in the fifth field of the ll output. The
major number identifies the "kernel driver" used to access the device. A kernel driver is a
portion of code in the HP-UX kernel that manages I/O for a particular type of device.
The lsdev command lists the drivers configured in the kernel, and their associated major
numbers. The third column in the lsdev output reports driver names. The first column
reports each driver’s character major number. The second column reports each driver’s
block major number. Block major number -1 indicates that the driver doesn’t support block
mode access.

Module 6
Device File Minor Numbers

Every device file has a 24-bit hexadecimal minor number. Minor numbers are formulated
differently for different types of devices.
Some of the bits in the minor number identify which device the DSF is associated with.
Other bits in the minor number may represent device-specific access options. Tape drives,
for instance, have special access options that enable/disable hardware compression and
define the density format used when writing to the tape.
Fortunately, HP-UX auto-configures most device files, so administrators very rarely have to
manually assign minor numbers anymore. Also, the lssf command automatically translates
a DSF’s hexadecimal minor numbers into human-readable format.
Device File Names

Every DSF has a DSF file name. DSF file names follow a standard naming convention, which
will be described in detail later in this chapter.

Module 6
6–3. SLIDE: DSF Types: Legacy vs. Persistent
DSF Types: Legacy vs. Persistent
• 11i v1 and v2 only support “legacy” DSFs

• 11i v3 still supports legacy device files, but introduces new “persistent” DSFs
• Persistent device files provide many advantages in today’s SAN environments
11i v1 and v2 Legacy DSFs 11i v3 Persistent DSFs
DSFs are created for each LUN path DSFs are created for each WWID
DSFs change if SAN topology changes DSFs are unaffected by SAN topology changes
DSFs are only auto-configured at startup DSFs are auto-configured after LUN creation
DSFs support up to 8192 active LUNs DSFs support up to 16,777,216 LUNs
Student Notes
HP-UX 11i v3 supports two different types of DSFs.
“Legacy” DSFs are supported in HP-UX 11i v1, v2, and v3, but will be deprecated in a future
release. In the legacy addressing scheme, each device path is represented by a minor
number, a legacy DSF and a legacy hardware path. The legacy DSF’s minor number directly
encodes the corresponding device path’s bus, target, and LUN numbers, as well as device
access options.
“Persistent” DSFs are new in 11i v3. Persistent DSFs provide a persistent, path-independent
representation of a device bound to the device’s Agile View LUN hardware path and World
Wide Identifier (WWID).
The notes below highlight the significant differences between the two DSF types.

Module 6
Path-based versus WWID-based DSFs

Because Legacy DSFs are based on physical paths, a single multi-pathed LUN often yields
multiple legacy DSFs. The OS relies on volume managers and third party applications to
determine which legacy DSFs represent redundant paths to a LUN, and which DSFs
represent distinct devices.
The new mass storage stack creates a single Agile View LUN hardware path for each
disk/tape/LUN regardless of the number of underlying paths to the device. The new stack
also creates a block and raw persistent DSF for each Agile View LUN hardware path / WWID.
The persistent DSFs represent the LUN itself, rather than a specific path to the LUN. This
approach greatly simplifies volume and system management.
System/SAN Topology Changes

Because legacy DSFs are based on physical paths, changes in the system or SAN topology
may change legacy LUNs’ DSF names and minor numbers, which may then require manual
changes to the system’s volume and file system configurations.
Because the persistent DSF represents a LUN rather than a lunpath, persistent DSFs aren’t
affected when a device is moved to a different HBA or SAN switch.
Auto-configuration
11i v1 and v2 automatically create device files for new devices during system startup. When
adding LUNs or other devices to a running system, though, the administrator must execute
the insf command to auto-configure DSFs. 11i v3 recognizes new LUNs and creates DSFs
automatically.
Scalability
Minor numbers are 24-bit numbers. In legacy DSFs, 15 bits in the minor number represent
the device address, and 9 bits represent the DSF’s special access options. With just 15
address bits, legacy DSFs can represent 215 = 32,768 LUN paths. The legacy storage stack
further limits the number of concurrently active LUNs to 8192.
Persistent DSF minor numbers are also 24-bits. However, persistent DSFs use all 24 bits to
identify the device itself. As a result, persistent DSFs can represent 224 = 16,777,216 LUNs.

Module 6
6–4. SLIDE: DSF Directories
DSF Directories
DSFs are stored in a directory structure under /dev

• Disk, DVD, tape, and related DSFs are stored in subdirectories under /dev
• LAN, terminal, modem, Most other device files are stored directly under /dev
/dev
disk block disk dsk block disk ttyxpx terminal
rdisk raw disk rdsk raw disk ttydxpx modem
rtape tape drive rmt tape drive cuaxpx modem
rchgr auto changer rac auto changer culxpx modem
Persistent DSFs Legacy DSFs cxtx_lp printer
More Legacy DSFs
Student Notes
The next few slides introduce the structure of the /dev directory, and the naming standard
naming convention used to assign names to legacy and persistent DSFs. An understanding of
the device file naming convention will allow you to more easily manage and use DSFs on
your system.
The slide above describes the structure of the /dev directory. The next few slides describe
the contents of the /dev subdirectories in detail.

Module 6
6–5. SLIDE: Legacy DSF Names
Legacy DSF Names

• Legacy DSF names are based on a device path’s controller instance, target, and LUN
• Multi-pathed LUNs require separate legacy DSFs for each path
• Legacy DSFs change when the SAN or system topology changes
# ioscan –kf
Class I H/W Path Description
=====================================================
ext_bus 5 1/0/2/1/0.6.1.0.0 FCP Array Interface
disk 3 1/0/2/1/0.6.1.0.0.0.1 HP HSV101
disk 6 1/0/2/1/0.6.2.0.0.0.1 HP HSV101
disk 9 1/0/2/1/1.1.2.0.0.0.1 HP HSV101
disk 12 1/0/2/1/1.1.3.0.0.0.1 HP HSV101
LUN
Bus Instance Device dependent options
Target
/dev/dsk/c11t0d1options
Student Notes
Legacy disk, LUN, DVD, auto-changer, and tape DSF names follow the convention shown on
the slide, in which the DSF name and minor number encode the associated hardware path’s
bus or controller instance number, target number, and LUN number, plus the associated
device access options. Devices accessed via multiple paths have separate legacy DSFs
representing each path.
# ioscan –kf
Class I H/W Path Description
=====================================================
disk 3 1/0/2/1/0.6.1.0.0.0.1 HP HSV101 Å 1st path
disk 6 1/0/2/1/0.6.2.0.0.0.1 HP HSV101 Å 2nd path
disk 9 1/0/2/1/1.1.2.0.0.0.1 HP HSV101 Å 3rd path
disk 12 1/0/2/1/1.1.3.0.0.0.1 HP HSV101 Å 4th path

Module 6
The ioscan output on the slide represents four paths to a single LUN. The legacy DSF
scheme assigns independent DSFs to each path. The notes below describe each component
in the fourth hardware path, 1/0/2/1/1.1.3.0.0.0.1.
Bus Instance Numbers

The kernel automatically assigns an instance number to every bus, controller, device, and
interface card on an HP-UX system. Instance numbers are assigned sequentially within each
device class, as new devices are recognized by the kernel. Thus, the first three ext_bus
class hardware components would be assigned instance numbers 0, 1, and 2. The first three
disk class devices would also be assigned instance numbers 0, 1, and 2. The first three
tape class devices would also be assigned instance numbers 0, 1, and 2. The binary
/etc/ioconfig file ensures that these instance number assignments persist across
reboots.
To view assigned instance numbers, look in the I column in the ioscan -kf output. To
improve readability, the screenshot on the slide only shows selected columns and rows from
the ioscan -kf output.
The number following the "c" in a LUN, disk, tape, or DVD DSF name identifies the device
path’s SCSI bus or fiber channel array controller ext_bus instance number. The disk path
represented by legacy hardware path 1/0/2/1/1.1.3.0.0.0.1 on the slide would have device files
beginning with "c11", since the instance number of the ext_bus at legacy hardware path
1/0/2/1/1.1.3.0.0 is "11".

disk 12 1/0/2/1/1.1.3.0.0.0.1 HP HSV101
Note that each device also has an instance number. Legacy DSF names utilize the ext_bus
instance number rather than the device instance number. Legacy DSFs allocate 8 bits to
represent the bus/controller portion of the device address in the minor number. Thus, legacy
DSFs support up to 256 bus/controller instances.
Target Numbers
The number following the "t" in a LUN, disk, tape, or DVD DSF name identifies the device’s
target address, which appears in the second-to-last component of the device’s hardware path.
The target address for hardware path 1/0/2/1/1.1.3.0.0.0.1 is 0.
disk 12 1/0/2/1/1.1.3.0.0.0.1 HP HSV101
LUN Numbers
The number following the "d" in a LUN, disk, tape, or DVD DSF name identifies the device’s
LUN number, which appears in the last component of the device’s hardware path. The LUN
number for hardware path 1/0/2/1/1.1.3.0.0.0.1 is 1.
disk 12 1/0/2/1/1.1.3.0.0.0.1 HP HSV101

Module 6
Recall that the LUN number in the last component of the hardware path, and following the
“d” in the legacy DSF, doesn’t fully represent the LUN ID assigned by the array administrator.
The legacy addressing scheme only provides 3-bits (eight addresses) in the last component in
an HP-UX hardware path. Since today’s arrays often present hundreds of LUNs. Legacy
hardware addresses use the last three components of the hardware path, together, to
represent the LUN ID. The table below shows the legacy hardware paths and DSF names
that would be used to represent the first sixteen LUNs in an array.
LUN ID LUN ID LUN ID, as represented in a legacy HP-UX Legacy

(decimal) (binary) controller/target/LUN hardware address DSF
0 0000000 0000 000 x/x/x/x/x.x.x.x.0.0.0 cxt0d0
1 0000000 0000 001 x/x/x/x/x.x.x.x.0.0.1 cxt0d1
2 0000000 0000 010 x/x/x/x/x.x.x.x.0.0.2 cxt0d2
3 0000000 0000 011 x/x/x/x/x.x.x.x.0.0.3 cxt0d3
4 0000000 0000 100 x/x/x/x/x.x.x.x.0.0.4 cxt0d4
5 0000000 0000 101 x/x/x/x/x.x.x.x.0.0.5 cxt0d5
6 0000000 0000 110 x/x/x/x/x.x.x.x.0.0.6 cxt0d6
7 0000000 0000 111 x/x/x/x/x.x.x.x.0.0.7 cxt0d7
8 0000000 0001 000 x/x/x/x/x.x.x.x.0.1.0 cxt1d0
9 0000000 0001 001 x/x/x/x/x.x.x.x.0.1.1 cxt1d1
10 0000000 0001 010 x/x/x/x/x.x.x.x.0.1.2 cxt1d2
11 0000000 0001 011 x/x/x/x/x.x.x.x.0.1.3 cxt1d3
12 0000000 0001 100 x/x/x/x/x.x.x.x.0.1.4 cxt1d4
13 0000000 0001 101 x/x/x/x/x.x.x.x.0.1.5 cxt1d5
14 0000000 0001 110 x/x/x/x/x.x.x.x.0.1.6 cxt1d6
15 0000000 0001 111 x/x/x/x/x.x.x.x.0.1.7 cxt1d7
16 0000000 0010 000 x/x/x/x/x.x.x.x.0.2.0 cxt2d0
Device-Dependent Access Options

The last part of the device file name lists device-specific access options enabled by the device
file. Tape drive device file names may have a variety of options listed in this portion of the
device file name. Access options vary from device to device.
Limitations
Legacy DSF minor numbers only allocate 15 bits to identify the DSF’s associated device.
These 15 bits allow legacy DSFs to address at most 215 = 32,768 LUN paths per system. Above
the legacy addressing scheme limits, only persistent device special files are created.
Multi-pathed Device DSFs

Each path to a multi-pathed LUN yields a separate legacy DSF. Since the LUN on the slide
has four distinct paths, it has four different legacy DSF names:
c5t0d1
c7t0d1
c9t0d1
c11t0d1

Module 6
Block versus Raw DSFs

Since LUNs may be accessed in either block or raw mode, each disk or LUN requires both a
block and raw legacy DSF for each device path. /dev/dsk/ contains block DSFs.
/dev/rdsk/ contains legacy raw DSFs:
/dev/dsk/c5t0d1 /dev/rdsk/c5t0d1
Legacy DSFs for Other Devices

The example on the slide represents the DSF naming scheme for a LUN. Legacy DSFs for
disks, CDROMs, and DVDs devices follow the same naming convention, and also reside in the
/dev/dsk/ and /dev/rdsk/ directories.
Legacy DSF names for tape drive and auto-changers also follow a cxtxdx format, but reside
in /dev/rmt/ and /dev/rac/. Kernel drivers for tape drives and autochangers typically
only support raw device files.
Terminals, modems, and printers follow a very different format. Later slides describe each
device type’s unique DSF requirements in detail.

Module 6
6–6. SLIDE: Persistent DSF Names
Persistent DSF Names

• Persistent DSF names are based on a device’s LUN hardware path instance number
• Multi-pathed devices require just one block and one raw persistent DSF
• Persistent DSFs remain unchanged when the SAN or system topology changes
# ioscan –kfNn
=================================================================
LUN hardware path instance Device dependent options
/dev/disk/disk30options
Student Notes
Legacy DSF names and minor numbers encode a hardware path’s bus or controller instance
number, target number, and LUN number. The legacy scheme has a number of significant
limitations:
• Multi-pathed LUNs require separate legacy DSFs for each LUN path
• Legacy DSF names change when the SAN topology changes, since the DSF names encode
the device’s physical hardware path
• The minor number addressing scheme supported at most 32,768 total LUN addresses, of
which only 8192 LUNs can be active at any given time
Persistent DSFs resolve both of these issues by providing path-independent, WWID-based
DSF representations of up to 16,777,216 disks, LUNs, tape drives, and DVDs.
The agile view ioscan -kfNn output on this slide represents the same LUN described in
the legacy view ioscan -kf output on the previous slide. There are still four paths to the
LUN, but agile view reports a single, path-independent view of the LUN.

Module 6
The LUN’s persistent DSFs encode the instance number of the agile view LUN hardware
address rather than the bus/target/LUN numbers of the underlying legacy hardware paths
leading to the LUN. The agile view LUN hardware address ultimately maps to a LUN
WorldWide Identifier (WWID), which should remain consistent no matter which path one
uses to access the LUN.
In the example on the slide, ioscan suggests that the LUN’s agile view hardware address
instance number is 30. Thus, the LUN’s persistent DSF name is simply disk30. Since LUNs
may be accessed in either block or raw mode, each LUN has two persistent DSFs:
/dev/disk/disk30 (persistent block DSF for disk30)

/dev/rdisk/disk30 (persistent raw DSF for disk30)
Persistent DSFs for Other Devices

This example on the slide represents the persistent DSF naming scheme for a LUN.
Persistent DSFs for disks, CDROMs, and DVDs follow the naming convention described on
the slide, and also reside in the /dev/disk/ and /dev/rdisk/ directories.
Persistent DSF names for tape drive and auto-changers also encode the instance number of
the device’s Agile View LUN hardware address, but require a slightly different device prefix
and reside in the /dev/rtape/ and /dev/rchgr/ directories. Kernel drivers for tape
drives and autochangers typically only support raw device files. Tape drives usually have a
suffix representing the compression, format, and other options enabled by the device file.
/dev/rtape/tape0_BEST
/dev/rchgr/autoch1
Terminals, modems, and printers only require legacy DSFs.

Module 6
6–7. SLIDE: LUN, Disk, and DVD DSF Names
LUN, Disk, and DVD DSF Names

• The table below shows DSFs created for a multi-pathed LUN with four paths
• Disks, DVDs, WORM and Optical Memory drives all use similar DSF names
Legacy DSFs Persistent DSFs

/dev/dsk/c5t0d1
/dev/dsk/c7t0d1
Block DSFs /dev/disk/disk30
/dev/dsk/c9t0d1
/dev/dsk/c11t0d1
/dev/rdsk/c5t0d1
/dev/rdsk/c7t0d1
Raw DSFs /dev/rdisk/disk30
/dev/rdsk/c9t0d1
/dev/rdsk/c11t0d1
SAN LUN
Server with 2 HBAs Array with 2 Controllers
Student Notes
LUNs, disks, CDROMs, and DVDs all follow the standard cxtxdx legacy DSF naming
convention and diskx persistent DSF naming convention.
The drivers for these devices support both block and character mode access. Legacy block
and raw DSFs reside in /dev/dsk/ and /dev/rdsk/ respectively. Persistent block and
raw DSFs reside in /dev/disk/ and /dev/rdisk/ respectively.
Using the legacy DSF scheme, every path to a LUN generates a block and raw DSF. Using the
persistent DSF scheme, each LUN requires just one block and raw DSF for the LUN
regardless of the number of underlying paths.

Module 6
6–8. SLIDE: Boot Disk DSF Names
Boot Disk DSF Names

• Integrity boot disks are subdivided into three “EFI” disk partitions
• Each EFI partition requires block and raw DSFs
− Legacy DSFs identify EFI partitions via suffixes s1, s2, s3
− Persistent DSFs identify EFI partitions via suffixes p1, p2, p3
• Though not shown below, boot disks may be multi-pathed, too
Legacy DSFs Persistent DSFs

Partition Table
/dev/dsk/c0t1d0 /dev/disk/disk27
System Partition
Block /dev/dsk/c0t1d0s1 /dev/disk/disk27_p1
(partition 1)
DSFs /dev/dsk/c0t1d0s2 /dev/disk/disk27_p2
/dev/dsk/c0t1d0s3 /dev/disk/disk27_p3 OS Partition
(partition 2)
/dev/rdsk/c0t1d0 /dev/rdisk/disk27
Raw /dev/rdsk/c0t1d0s1 /dev/rdisk/disk27_p1 Service Partition
DSFs /dev/rdsk/c0t1d0s2 /dev/rdisk/disk27_p2 (partition 3)
/dev/rdsk/c0t1d0s3 /dev/rdisk/disk27_p3 Partition Table
Integrity Boot Disk
Student Notes
PA-RISC boot disk DSFs follow the standard legacy and persistent disk DSF naming
convention described on the previous slide.
Integrity boot disks, however, are subdivided into Extensible Firmware Interface (EFI) disk
partitions. A partition table at the top of each disk records the locations of the partitions.
Each partition requires additional block and raw device files.
• The EFI system partition contains the OS loader that is responsible for loading the OS
in memory during the boot process, and several supporting files. cxtxdxs1 is the system
partition’s legacy DSF name. diskx_p1 is the system partition’s persistent DSF name.
• The EFI OS partition contains the LVM or VxVM volumes that contain the kernel and
other operating system files and directories. cxtxdxs2 is the OS partition’s legacy DSF
name. diskx_p2 is the OS partition’s persistent DSF name.
• The optional EFI HP Service Partition (HPSP) contains offline diagnostic utilities that
may be used to troubleshoot an unbootable system. cxtxdxs3 is the system partition’s
legacy DSF name. diskx_p3 is the system partition’s persistent DSF name.

Module 6
To learn more about Integrity boot disks and EFI partitions, see the Integrity boot process
chapter later in this book.

Module 6
6–9. SLIDE: Tape Drive DSF Names
Tape Drive DSF Names

• Tape drive DSFs follow the standard legacy/persistent DSF naming convention
• Suffixes identify the DSF’s density, compression, rewind, and write semantic features
Legacy DSFs Persistent DSF

Features
in /dev/rmt/ in /dev/rtape/
Best density, autorewind, AT&T style c0t0d0BEST + 0m tape0_BEST
Best density, no autorewind, AT&T style c0t0d0BESTn + 0mn tape0_BESTn
Best density, autorewind, Berkeley style c0t0d0BESTb + 0mb tape0_BESTb
Best density, no autorewind, Berkeley style c0t0d0BESTnb + 0mnb tape0_BESTnb
Student Notes
Tape drive DSF names are very similar to LUN DSF names.
Legacy Tape Drive DSFs

Legacy tape drive DSFs reside in the /dev/rmt/ directory and encode bus/target/LUN
addresses just like legacy disk and LUN DSFs. However, unlike LUNs, tape drives often
support numerous access options in the [options] portion of the device file name. The
DSF below accesses the tape drive located at bus instance 0, target 0, LUN 0 using the best
density and compression features supported by the tape drive.
/dev/rmt/c0t0d0BEST
Note that the stape kernel driver doesn’t support block mode access to tape drives, so there
isn’t a /dev/mt/ device file directory.

Module 6
Persistent Tape Drive DSFs

Much like persistent LUN DSFs, persistent tape drive DSFs encode the device’s agile view
hardware address instance number. However, persistent tape drive DSFs reside in the
/dev/rtape/ directory, and the DSF names include prefix tape rather than disk. The
DSF below accesses the tape drive with instance number 0 using the best density and
compression features supported by the tape drive.
Note that the estape kernel driver doesn’t support block mode access to tape drives, so
there isn’t a /dev/tape/ device file directory.
Tape Drive DSF Options

Unlike LUN DSFs, tape drive DSFs often support numerous access options via the
[options] portion of the DSF name. Common options, which are supported on both legacy
and persistent DSFs, include:
w Immediate report disabled. A write request waits until the data are written on the medium.
density Specifies the density or format used when writing to the tape. 11i v3 only
supports the BEST density. 11i v1 and v2 support several other formats. The list
below only describes some of the common 11i v1 and v2 density formats. See the
mt(7) man page for a complete list.
BEST Use the highest available density/compression features available
NOMOD Maintain the density/compression features used previously on the tape
DDS1 Use DDS1 format to ensure compatibility with older DDS1 tape drives
DDS2 Use DDS2 format to ensure compatibility with older DDS2 tape drives
C[n] Write data in compressed mode, on tape drives that support data compression.
Compression is automatically enabled when the density field is set to BEST.
n No rewind on close. Unless this mode is requested, the driver automatically
rewinds the tape when closed.
b Specifies Berkeley-style tape mode. When the b is absent, the tape drive
follows AT&T-style behavior.
When a file is closed after servicing a read request, if the no-rewind bit is not
set, the tape drive automatically rewinds the tape. If the no-rewind bit is set,
the behavior depends on the style mode. For AT&T-style devices, the tape is
positioned after the EOF following the data just read (unless already at BOT
or Filemark). For Berkeley-style devices, the tape is not repositioned in any
way.
w Writes wait for physical completion of the operation before returning status.
The default behavior (buffered mode or immediate reporting mode) requires
the tape device to buffer the data and return immediately with successful
status.

Module 6
See the examples on the slide and the mksf(1m) man page for more information.
9.x Compatibility
Prior to version HP-UX 10.01, tape drive DSFs followed an entirely different naming
convention:
/dev/rmt/0m First tape drive on the system
/dev/rmt/1m Second tape drive on the system
/dev/rmt/2m Third tape drive on the system
/dev/rmt/2mn Third tape drive on the system, "no-rewind" feature enabled
/dev/rmt/2mnb Third tape drive, "no-rewind" feature and Berkeley semantics enabled
Each DSF name includes an instance number to distinguish the DSF from all other tape drive
DSFs, the letter "m", and a series of access options as described previously.
11i v1, v2, and v3 automatically create the following tape drive DSFs, but they are simply
links to equivalent legacy cxtxdxBEST DSFs.
/dev/rmt/0m links to /dev/rmt/cxtxdxBEST

/dev/rmt/0mn links to /dev/rmt/cxtxdxBESTn
/dev/rmt/0mb links to /dev/rmt/cxtxdxBESTb
/dev/rmt/0mnb links to /dev/rmt/cxtxdxBESTnb

Module 6
6–10. SLIDE: Tape Autochanger DSF Names
Tape Autochanger DSF Names

• Many administrators today use tape libraries with tape autochangers
• Autochanger legacy DSF names are based on controller/target/LUN numbers
• Autochanger persistent DSF names are based on the autochanger’s instance number
Legacy DSFs Persistent DSF
/dev/rac/c5t0d2
/dev/rac/c7t0d2
/dev/rchgr/autoch1
/dev/rac/c9t0d2
/dev/rac/c11t0d2
Student Notes
Many administrators today use tape libraries with tape auto-changers to manage system
backups. These devices typically include one or more tape drives, magazines for storing
multiple tapes, and a robotic auto-changer mechanism to move tapes between the magazines
and drives. Backup utilities access the tape drives via standard tape DSFs in /dev/rmt/ and
/dev/rtape/. Robotic auto-changers typically have their own DSFs in /dev/rac/ and/or
/dev/rchgr/.
Legacy Auto-changer DSFs

Legacy auto-changer DSFs reside in the /dev/rac/ directory and encode bus/target/LUN
addresses just like legacy disk/LUN DSFs. Example:
/dev/rac/c0t0d0

Module 6
Persistent Auto-changer DSFs

Much like persistent LUN DSFs, persistent tape drive DSFs encode the device’s agile view
hardware address instance number. However, persistent tape drive DSFs reside in the
/dev/rchgr/ directory, and the DSF names include prefix autoch rather than disk. The
DSF below accesses the auto-changer with instance number 0.
/dev/rchgr/autoch1

Module 6
6–11. SLIDE: Terminal, Modem, and Printer DSF Names
Terminal, Modem, and Printer DSF Names

• Some terminals, modems, and printers connect directly to a serial interface card
• Others connect to the server via a “multiplexer” device and interface card
• Terminal, modem, and serial printer DSF names include two numbers:
− Interface card instance number
− Multiplexer port number (0 if not connected to a multiplexer)
Device Type DSF Examples

Terminal device file /dev/tty0p0
Modem dial-in /dev/ttyp0p0
Modem dial-out /dev/cul0p0
Modem direct connect /dev/cua0p0
Serial printer /dev/c0p0_lp
16 Port Multiplexer
Server w/ MUX interface card Terminals
Student Notes
Though many users access systems exclusively via network services today, some systems
still include hardwired terminals, modems, and printers.
Most servers still include a built-in DB9 serial port on the Core I/O card that can be used to
connect a single hardwired terminal or modem.
Administrators who require multiple serial devices can purchase an add-on multiplexer
(MUX) interface card. The interface card occupies one expansion slot on the server and
typically connects to an external box that provides 8, 16, 32, or 64 RJ45, DB25, or DB9 ports
for connecting external devices. Alternatively, it may be possible to connect serial devices to
the multiplexer card directly via a MUX fan-out cable like the one shown below.

Module 6
Hardwired Terminal DSFs

Hardwired terminal DSFs reside directly in the /dev/ directory. The DSF names have two
numeric components. The first number (which immediately follows the tty prefix)
identifies the instance number of the interface card to which the device is attached. The
second number (which immediately follows the p) identifies the multiplexer port number to
which the device is attached. If the device is attached directly to a built-in serial port rather
than a multiplexer, HP-UX uses port 0 in the DSF name.
/dev/tty0p0 terminal attached to the Core I/O serial port

/dev/tty2p3 terminal attached to MUX interface instance 2, port 3
/dev/tty2p4 terminal attached to MUX interface instance 2, port 4
See HP’s Configuring HP-UX for Peripherals manual for additional information.
Hardwired Modem DSFs

Hardwired modem DSFs also reside directly in the /dev/ directory and, like terminals, have
two numeric components. The first number identifies the instance number of the interface
card to which the device is attached. The second number identifies the multiplexer port
number to which the device is attached. If the device is attached directly to a built-in serial
port rather than a multiplexer, HP-UX uses port 0 in the DSF name.
A fully functional modem requires three device files. /dev/ttydxpx is required for dial-in
modem service. /dev/culxpx is required for dial-out service. /dev/cuaxpx is required
for direct-connect service.
See HP’s Configuring HP-UX for Peripherals manual for additional information.
Pseudo Terminals
Pseudo terminals are used by applications that provide terminal emulation capabilities, such
as hpterm, xterm, telnet, etc. The pseudo terminal driver provides support for a
device-pair termed a pseudo terminal. A pseudo terminal is a pair of character devices, a
master device and a slave device.

Module 6
The device files for pseudo terminals are found in the following places:
slave /dev/tty xx. These are links to files in the /dev/pty
directory /dev/pty/ttyxx
master /dev/pty xx. These are links to files in the /dev/ptym
directory /dev/ptym/ptyxx
streams- based pseudo slave /dev/pts/n. This is used by the dtterm terminal
emulator
streams- based master /dev/ptymx. This is used by the dtterm terminal
emulator
By default, HP-UX creates 60 pseudo-terminals of each type. If your server is likely to service
more than 60 concurrent telnet sessions, or more than 60 concurrent terminal emulator
windows, then you may need to increase the number of pseudo terminals. To increase the
number of pseudo terminals, increase the value of the npty and nstrpty kernel
parameters, and reboot. During the boot process, HP-UX executes the insf command,
which then creates the additional pseudo terminal device files. Kernel configuration will be
covered in a later chapter.

Module 6
6–12. SLIDE: Listing Legacy DSFs
Listing Legacy DSFs
• Use ioscan -kfn to list legacy hardware paths and their legacy DSFs
• Additional options filter the list by class or legacy hardware path
• Output only shows legacy addresses and DSFs
# ioscan –kfn list all devices and their legacy DSFs

# ioscan -kfnC disk list all disk class devices and their legacy DSFs
# ioscan -kfnC tape list all tape class drives and their legacy DSFs
# ioscan –kfnH 0/0/1/0/0.0.0 list a specific device/path and its legacy DSFs
# ioscan –kfn /dev/rmt/0m list a specific device/path and its legacy DSFs

==================================================================
tape 0 0/0/1/0/0.0.0 stape CLAIMED DEVICE HP C1553A
/dev/rmt/0m /dev/rmt/c0t0d0BESTb
/dev/rmt/0mb /dev/rmt/c0t0d0BESTn
/dev/rmt/0mn /dev/rmt/c0t0d0BESTnb
/dev/rmt/0mnb /dev/rmt/c0t0d0BEST
Student Notes
The next few slides discuss several commands for viewing DSFs.
The ioscan command, with the –f (full) and –n (DSF names) options, provides a
convenient mechanism for determining which legacy DSFs are associated with each
hardware path on your system. Below each hardware path, ioscan -kfn lists the legacy
DSFs associated with each hardware path.
The output below shows ioscan –kfn output for the tape drive at hardware path
0/0/1/0/0.0.0. Since tape drives support several access options, the tape drive has
several legacy DSFs.
# ioscan -kfn
==================================================================
tape 0 0/0/1/0/0.0.0 stape CLAIMED DEVICE HP C1553A
/dev/rmt/0m /dev/rmt/c0t0d0BESTb
/dev/rmt/0mb /dev/rmt/c0t0d0BESTn
/dev/rmt/0mn /dev/rmt/c0t0d0BESTnb
/dev/rmt/0mnb /dev/rmt/c0t0d0BEST

Module 6
Add additional ioscan options to view legacy DSFs associated with a specific device class
(-C) or legacy hardware path (–H). Or, specify the device of interest by providing one of the
device’s legacy DSFs as an argument. See the examples below:
# ioscan –kfn list all devices, and their device files

# ioscan -kfnC disk only list disk class device files
# ioscan -kfnC tape only list tape drives and their device files
# ioscan -kfnH 0/0/1/0/0.0.0 only list device files for 0/0/1/0/0.0.0
# ioscan -kfn /dev/rmt/0m only list device files for tape drive /dev/rmt/0m

Module 6
6–13. SLIDE: Listing Persistent DSFs
Listing Persistent DSFs

• Use the ioscan –kfnN to list LUN hardware paths and their persistent DSFs
• Additional options filter the list by class or hardware path
• Devices that support persistent DSFs report persistent DSFs
• Devices that only support legacy DSFs (eg: terminals & modems) report legacy DSFs
# ioscan –kfnN list all devices and their persistent DSFs

# ioscan -kfnNC disk list all disk class devices and their persistent DSFs
# ioscan -kfnNC tape list all tape class drives and their persistent DSFs
# ioscan –kfnNH 64000/0xfa00/0x0 list a specific device and its persistent DSFs
# ioscan –kfnN /dev/rtape/tape0 list a specific device and its persistent DSFs

==================================================================
tape 0 64000/0xfa00/0x0 estape CLAIMED DEVICE HP C1553A
/dev/rtape/tape0_BESTn
/dev/rtape/tape0_BESTb
/dev/rtape/tape0_BESTnb
Student Notes
Use the ioscan command with the –f (full), –n (DSF names), and –N (New Agile View)
options to view devices’ Agile View hardware paths and persistent DSFs. Devices that
support persistent DSFs report persistent DSFs. Devices that only support legacy DSFs (e.g.:
terminals & modems) report legacy DSFs.
The output below shows ioscan –kfnN output for the tape drive at Agile View LUN
hardware path 64000/0xfa00/0x0. Since tape drives support several access options, the
tape drive has several DSFs.
# ioscan -kfnN
==================================================================
tape 0 64000/0xfa00/0x0 estape CLAIMED DEVICE HP C1553A

Module 6
Add additional ioscan options to view legacy DSFs associated with a specific device class
(-C) or legacy hardware path (–H). Or, specify the device of interest by providing one of the
device’s DSFs as an argument. See the examples below:
# ioscan –kfnN list all devices and their persistent DSFs

# ioscan -kfnNC disk list all disk devices and their persistent DSFs
# ioscan -kfnNC tape list all tape drives and their persistent DSFs
# ioscan –kfnNH 64000/0xfa00/0x0 list a specific device and its persistent DSFs
# ioscan –fnN /dev/rtape/tape0 list a specific device and its persistent DSFs

Module 6
6–14. SLIDE: Correlating Persistent DSFs with LUNs and

lunpaths
Correlating Persistent DSFs with LUNs and lunpaths

Execute ioscan –m lun with the –H option or a DSF name to correlate
hardware paths or DSFs with their corresponding lunpath addresses
# ioscan –m lun [-H 64000/0xfa00/0x4]|[/dev/disk/disk30]

1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
1/0/2/1/0.0x50001fe15003112c.0x4002000000000000
1/0/2/1/0.0x50001fe150031128.0x4002000000000000
1/0/2/1/1.0x50001fe15003112d.0x4002000000000000
1/0/2/1/1.0x50001fe150031129.0x4002000000000000
Student Notes
The ioscan –kfnN command described on the previous page lists devices and DSFs. To
correlate those device files with lunpaths, though, use the same ioscan –m lun command
introduced in the hardware module. Note that you can specify a particular disk or LUN using
the LUN’s LUN hardware path or the LUN’s persistent DSF.
The command reports each device’s class, instance, hardware path, driver, software state,
hardware state, health status, and description.
Below each LUN hardware path, the command reports all of the lunpath hardware addresses
available to access each LUN.
Below the lunpath hardware addresses, the command reports each device’s persistent DSFs.
# ioscan –m lun
====================================================================

Module 6

1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
1/0/2/1/0.0x50001fe15003112c.0x4002000000000000
1/0/2/1/0.0x50001fe150031128.0x4002000000000000
1/0/2/1/1.0x50001fe15003112d.0x4002000000000000
1/0/2/1/1.0x50001fe150031129.0x4002000000000000
By default, the command displays all disks and LUNs. Add the –H option with a LUN
hardware path to view a specific disk or LUN.
# ioscan –m lun -H 64000/0xfa00/0x4

====================================================================
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
Or, add the –D option with a persistent DSF to view a specific disk or LUN.
# ioscan –m lun –D /dev/disk/disk30

====================================================================
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000

Module 6
6–15. SLIDE: Correlating Persistent DSFs with WWIDs
Correlating Persistent DSFs with WWIDs

• SAN and array administrators identify LUNs via WWID and LUN ID numbers
• Use scsimgr get_attr to correlate a LUN hardware path or DSF with a WWID
View the WWID for all LUNs, or a specific LUN hardware path or DSF
# scsimgr get_attr -a wwid \
[all_lun]|[-H 64000/0xfa00/0x4]|[-D /dev/rdisk/disk30]
name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =
Student Notes
When troubleshooting SAN issues, it is oftentimes helpful to know a device’s WWID and
underlying lunpath hardware paths. Use the same scsimgr command introduced in the
hardware module. Note that you can view all LUNs, or specify a particular LUN using the
LUN’s LUN hardware path or the LUN’s raw persistent DSF.
# scsimgr get_attr -a wwid all_lun
name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =
name = wwid
current = 0x600508b400012fd20000900001900000

Module 6
default =
saved =
name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =
# scsimgr get_attr -a wwid -D /dev/rdisk/disk30
name = wwid
current = 0x600508b400012fd20000a00000250000
default =
saved =
Recall that you can also use the scsimgr command to obtain a LUN’s LUNID. However, in
order to obtain the LUNID, you must provide a lunpath hardware address. Rather, use the
ioscan –m lun –D /dev/disk/disk30 command to determine the LUN’s lunpaths;
then use one of the lunpath addresses as an argument to scsimgr.
# ioscan –m lun –D /dev/disk/disk30

====================================================================
1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
1/0/2/1/0.0x50001fe150031128.0x4001000000000000
1/0/2/1/1.0x50001fe15003112d.0x4001000000000000
1/0/2/1/1.0x50001fe150031129.0x4001000000000000
-a lunid \
-H 1/0/2/1/0.0x50001fe15003112c.0x4001000000000000
name = lunid
default =
saved =

Module 6
6–16. SLIDE: Correlating Persistent DSFs with Legacy DSFs
Correlating Persistent DSFs with Legacy DSFs

• Admins managing multiple OS versions may need to correlate persistent/legacy DSFs
• Use ioscan –m dsf to list persistent DSFs and their corresponding legacy DSFs
Map all persistent DSFs to corresponding legacy DSFs

# ioscan –m dsf
Map a specific legacy DSF to an associated persistent DSF

# ioscan -m dsf /dev/dsk/c5t0d1
Persistent DSF Legacy DSF(s)
========================================
/dev/disk/disk30 /dev/dsk/c5t0d1
Map a specific persistent DSF to associated legacy DSFs

# ioscan -m dsf /dev/disk/disk30
========================================
/dev/dsk/c7t0d1
/dev/dsk/c9t0d1
/dev/dsk/c11t0d1
Student Notes
Administrators making the transition from legacy addressing to Agile View addressing can
use ioscan –m dsf to correlate legacy and persistent DSFs.
Execute ioscan –m dsf to view a list of all persistent DSFs and their corresponding legacy
DSFs, The output only includes devices that support persistent DSFs.
# ioscan –m dsf
/dev/rdisk/disk30 /dev/rdsk/c5t0d1
/dev/rdsk/c7t0d1
/dev/rdsk/c9t0d1
/dev/rdsk/c11t0d1
/dev/rdsk/c7t0d2
/dev/rdsk/c9t0d2
/dev/rdsk/c11t0d2
/dev/rdsk/c7t0d3
/dev/rdsk/c9t0d3

Module 6
/dev/rdsk/c11t0d3
To map a specific legacy DSF to an associated persistent DSF, specify the legacy DSF as an
argument.
# ioscan -m dsf /dev/dsk/c5t0d1

========================================
To map a specific persistent DSF to associated legacy DSFs, specify the persistent DSF as an
argument.
# ioscan -m dsf /dev/disk/disk30

========================================
/dev/dsk/c7t0d1
/dev/dsk/c9t0d1
/dev/dsk/c11t0d1

Module 6
6–17. SLIDE: Decoding Persistent and Legacy DSF Attributes
Decoding Persistent and Legacy DSF Attributes
• Use lssf to display detailed information about a DSF’s attributes

• lssf displays both legacy and persistent DSFs
Decode a legacy DSF’s major and minor numbers

# lssf /dev/rmt/c0t0d0BESTnb
stape card instance 0 SCSI target 0 SCSI LUN 0
Berkeley No-Rewind BEST density
at address 0/0/1/0/0.0.0 /dev/rmt/0mnb
Decode a persistent DSF’s major and minor numbers

# lssf /dev/rtape/tape0_BESTnb
estape Berkeley No-Rewind BEST density
at address 64000/0xfa00/0x0 /dev/rtape/tape0_BESTnb
Student Notes
Many devices have multiple DSFs, since devices can often be accessed via a variety of
combinations of access options. Some utilities and applications require DSFs that enable
specific options. For instance, make_tape_recovery, which creates a bootable system
recovery tape, requires a “No-Rewind” DSF.
ioscan lists a device’s DSFs, but doesn’t indicate which device-specific options each DSF
enables. Use the lssf command to decode a DSF’s major and minor number and report the
DSF’s driver name, hardware address, and access options. The command accepts both
legacy and persistent DSF arguments.
# lssf /dev/rmt/c0t0d0BESTnb
stape card instance 0 SCSI target 0 SCSI LUN 0
Berkeley No-Rewind BEST density
at address 0/0/1/0/0.0.0 /dev/rmt/0mnb

Module 6
# lssf /dev/rtape/tape0_BESTnb
estape Berkeley No-Rewind BEST density
at address 64000/0xfa00/0x0 /dev/rtape/tape0_BESTnb
To view multiple DSFs, include a wildcard in the DSF name argument.
# lssf /dev/rtape/*
estape AT&T BEST density at address 64000/0xfa00/0x9
estape Berkeley BEST density at address 64000/0xfa00/0x9
estape AT&T No-Rewind User Config at address 64000/0xfa00/0x9
estape Berkeley No-Rewind BEST density at address 64000/0xfa00/0x9
Questions
The last few slides described several ways to view DSFs. Which command would be most
appropriate for each of the following situations?
1. A DBA has requested additional disk space. Which command would you use to list the
persistent DSFs of all of the disk class devices on the system?
2. While troubleshooting a problem, you determine that /dev/disk/disk30 isn’t

behaving properly. The array administrator needs the LUN’s WWID to investigate the
problem. How can you determine the LUN’s WWID?
3. Your new backup software requires a no-rewind tape device file. How can you determine
which /dev/rtape/tape0_* DSFs enable the no-rewind option?

Module 6
Answers
1. A DBA has requested additional disk space. Which command would you use to list the
persistent DSFs of all of the disk class devices on the system?
# ioscan –fnNC disk or

# ioscan –m lun
2. While troubleshooting a problem, you determine that /dev/disk/disk30 isn’t

behaving properly. The array administrator needs to know the LUN’s WWID to
investigate the problem. How can you determine the LUN’s WWID?
# scsimgr get_attr –a wwid -D /dev/rdisk/disk30
3. Your new backup software requires a no-rewind tape device file. How can you determine
which /dev/rtape/tape0_* DSFs enable the no-rewind option?
# lssf /dev/rtape/tape0_*

Module 6
6–18. SLIDE: Managing Device Files
Managing Device Files
• HP-UX automatically creates DSFs for most devices during system startup
• HP-UX 11i v3 automatically creates persistent DSFs for dynamically added LUNs, too
• HP-UX also provides tools for manually creating and managing device files
• insf Create default DSFs for auto-configurable devices

• mksf Create non-default DSFs for auto-configurable devices
• mknod Create custom DSFs for non-auto-configurable devices
• rmsf Remove devices and DSFs
Student Notes
HP-UX automatically recognizes most supported device types, and automatically creates
standard DSFs. These devices are said to be “auto-configurable”.
During the 11i v1, v2, and v3 system startup process, HP-UX automatically probes the
hardware installed on the system, “binds” an appropriate kernel driver to each auto-
configurable device, assigns instance numbers, and creates legacy and persistent DSFs for
new devices.
HP-UX 11i v3 also detects LUNs added or modified on running systems and dynamically
creates persistent DSFs as necessary.
Although HP-UX creates most DSFs automatically, the administrator can manually create and
manage DSFs using the commands below:
• insf Creates default DSFs for auto-configurable devices

• mksf Creates non-default DSFs for auto-configurable devices
• mknod Creates custom DSFs for non-auto-configurable devices

Module 6
• rmsf Removes devices and DSFs
The next few slides describe these commands in detail. You can also use the sam, smh, and
pdweb GUI/TUI interfaces to manage DSFs.

Module 6
6–19. SLIDE: Creating DSFs via insf
Creating DSFs via insf

Use insf to install standard DSFs for new devices, and recreate missing DSFs
Scan for new hardware

# ioscan
Create DSFs for newly added devices
# insf -v
Create DSFs for new devices and re-create missing DSFs for existing devices
# insf –v -e
Create or recreate DSFs for a specific hardware path or class
# insf –v –e -H 64000/0xfa00/0x0
# insf –v –e –C estape
See the insf man page for many more options and examples
Student Notes
HP-UX 11i v1, v2, and v3 automatically create legacy and persistent DSFs for new devices
during system startup. 11i v3 even detects LUNs added or modified on an already-running
system, and creates persistent DSFs if necessary.
The administrator can also manually create standard DSFs via the insf command after:
• accidentally deleting DSFs; or
• adding hot-pluggable devices
Before running insf, run ioscan to scan the hardware and bind kernel drivers to new
devices. Do not include the –k or –u options. The –k and –u options report cached device
information, but don’t scan for new devices. In 11i v3, ioscan also automatically creates
DSFs for new devices; thus, it may not even be necessary to proceed to the insf command
in the next step!
# ioscan

Module 6
Next, execute insf –v to create standard DSFs for new devices. The –v (verbose) option
reports the new DSF names.
# insf -v
insf: Installing special files for stape instance 0 address 0/1/1/1.4.0
insf: Installing special files for estape instance 1 address
64000/0xfa00/0x0
making rtape/tape1_BEST c 23 0x000009
making rtape/tape1_BESTn c 23 0x00000b
making rtape/tape1_BESTb c 23 0x00000c
making rtape/tape1_BESTnb c 23 0x00000d
By default, insf only creates DSFs for new devices. Add the –e (existing) option to recreate
missing DSFs for a previously configured device. In the example below, the first insf
command does not install any DSFs since the device was previously configured. The second
command recreates missing DSFs for the existing device as a result of the –e option.
# insf –v
# insf –v -e
64000/0xfa00/0x9
(creates DSFs for all other devices, too)
To create DSFs for selected devices rather than all devices, use -H and -C to select devices
by hardware path or device class. If –H specifies an Agile View LUN hardware path, insf
only creates persistent DSFs. If –H specifies a legacy hardware path, insf creates legacy
DSFs. The –C option creates both legacy and persistent DSFs.
# insf –v –e -H 64000/0xfa00/0x0
64000/0xfa00/0x0
# insf –v –e –C tape
64000/0xfa00/0x0

Module 6
6–20. SLIDE: Creating DFSs via mksf
Creating DSFs via mksf
• For tape drives and other devices that support device dependent options,
insf only creates device files for the most common combinations of options
• Use mksf to configure device files for other unusual combinations of options;
see the mksf(1m) man page for driver-specific options
Configure a DDS2, no-rewind DSF for the tape drive at 64000/0xfa00/0x0 :

# mksf –v –H 64000/0xfa00/0x0 –b DDS2 -n
See the mksf and mt man pages for many more device-specific options and examples
Student Notes
insf only configures standard device files for auto-configurable devices. For example, insf
automatically creates the following DSFs for DDS tape drives:
/dev/rmt/0m
/dev/rmt/0mb
/dev/rmt/0mn
/dev/rmt/0mnb
/dev/rmt/c0t0d0BEST
/dev/rmt/c0t0d0BESTb
/dev/rmt/c0t0d0BESTn
/dev/rmt/c0t0d0BESTnb

Module 6
To create a device file supporting an unusual combination of special option, use mksf. The
example below creates a DSF for the tape drive at hardware path 64000/0xfa00/0x0 using
the DDS2 density format (-b DDS2), and with no-auto-rewind enabled (-n).
# mksf -v -H 64000/0xfa00/0x0 -b DDS2 -n

making rtape/tape1_DDS2n c 23 0x000011
mksf options vary from driver to driver. Options that are meaningful to one device driver
may be meaningless to others. The mksf(1m) and mt(7) man pages describe dozens of
options that may be used to configure device files with various combinations of options.
Fortunately, the mksf command is rarely needed since insf automatically creates most
commonly used DSFs.

Module 6
6–21. SLIDE: Creating DSFs via mknod
Creating DSFs via mknod
• If a device isn’t configurable via insf or mksf,

manually create DSFs with custom major/minor numbers using mknod
• mknod must be used to create LVM volume group DSFs,

and may be necessary to create DSFs for other vendors’ devices
# mknod /dev/vg01/group c 64 0x010000
Device File Name Block/Character Major# Minor#
Student Notes
The vast majority of HP-UX DSFs can be auto-configured by insf and mksf. Devices that
aren’t auto-configurable must be configured via mknod. The mknod command requires
several options and arguments:
• The full pathname for the new device file. Device files are typically stored in /dev.
• b or c, to indicate whether you wish to create a block or character device file.
• The major number of the kernel driver used to access the device. Use the lsdev
command to view a list of drivers and their associated major numbers.
• The minor number. Consult your device’s documentation to determine an appropriate

minor number.
HP’s Logical Volume Manager (LVM) volume group device files are perhaps the most
common DSFs that must be manually configured using mknod. A later chapter discusses
LVM concepts and commands more formally; for now, we will simply concentrate on the

Module 6
mknod options required to create an LVM volume group device file. The example on the slide
shows the full syntax for the mknod command required to create a volume group device file.
After creating a device file with mknod, you may need to execute the chmod command to set
appropriate permissions. A volume group device file should be owned by root, with 640
permissions. Other device files’ permissions will vary.

Module 6
6–22. SLIDE: Removing DSFs via rmsf
Removing DSFs via rmsf

• HP-UX automatically creates device files for new devices
• When a device is removed, its device files must be manually removed via rmsf
List devices and DSFs associated with non-existent “stale” devices (11i v3 only)
# lssf -s
Remove devices and DSFs associated with non-existent “stale” devices (11i v3 only)
# rmsf –v –x
Remove a specific DSF
# rmsf –v /dev/disk/disk1
Remove all of the device files associated with a device, and the device definition
# rmsf –v -a /dev/disk/disk1
Or … specify the device’s hardware path
# rmsf –v –H 64000/0xfa00/0x1
Student Notes
HP-UX automatically creates DSFs for new devices, but after removing a device, the device’s
DSFs must be manually removed via the rmsf command.
First, execute lssf –s to determine if there are any “stale” DSFs that reference non-existent
devices. The –s is only available on 11i v3.
# lssf –s
Stale Block Device Files

------------------------
/dev/disk/disk100
Stale Character Device Files

----------------------------
/dev/rdisk/disk100

Module 6
To remove the stale DSFs, execute rmsf –v –x. The –x is only available on 11i v3.
# rmsf –v –x
Removing stale block DSF /dev/disk/disk100
Removing stale character DSF /dev/rdisk/disk100
rmsf can also be used to remove a specific DSF.
# rmsf –v /dev/disk/disk100
rmsf: Removing special file /dev/disk/disk100
To preemptively remove DSFs before removing a LUN, run rmsf –v –a. The command
removes the specified device’s DSFs, as well as the device definition.
If you specify a legacy DSF, rmsf removes the DSF’s legacy hardware path and the legacy
hardware path’s associated DSFs. Persistent DSFs remain unaffected.
If you specify a persistent DSF, rmsf removes the DSF’s agile view LUN hardware path and
its associated persistent DSFs. Legacy DSFs remain unaffected.
# rmsf -v -a /dev/disk/disk100
rmsf: Removing special file /dev/disk/disk100
rmsf: Removing special file rdisk/disk100
Alternatively, specify the target device via the device’s hardware path.
• If the hardware path belongs to a node with H/W type DEVICE, all special files
mapping to devices at that hardware path and the system definition of those devices are
removed.
• If the hardware path belongs to LUN hardware path of a node of type DEVICE, the device
should not be in an open state for the command to complete successfully.
• If the hardware path belongs to a node with H/W type LUN_PATH, all legacy special
files mapping to devices at that hardware path, as well as the system definition of those
devices, are removed.
• If the hardware path belongs to a node for which H/W type is TGT_PATH, no special
files are removed; only the corresponding node is removed.
• If the hardware path belongs to a node for which H/W type is not DEVICE, then, a
special file is removed as follows:
• If the hardware path is a leaf node, only special files for that node will be
removed.
• If the hardware path has children, then a warning message will be issued and
system definition of all the children devices and their special files are removed.

Module 6
6–23. SLIDE: Disabling and Enabling Legacy Mode DSFs
Disabling and Enabling Legacy Mode DSFs

• By default, HP-UX 11i v3 enables both legacy and persistent mode device files
• Legacy mode can be disabled if no longer needed
• Be sure to convert all legacy DSF references to persistent DSFs before disabling!
Determine whether legacy mode is currently enabled

# insf -v -L
Disable legacy mode and remove legacy mode DSFs
# rmsf –v –L
Re-enable legacy mode and recreate legacy DSFs
# insf –L
Student Notes
By default, HP-UX 11i v3 automatically enables and creates both legacy and persistent mode
device files. You can disable legacy mode if you no longer need legacy mode DSFs. Be sure,
though, to convert all DSF references in volume manager, file system, and application
configuration files to persistent DSFs before disabling legacy mode! The iofind command
can help identify legacy DSF references. See the HP-UX 11i v3 Persistent DSF Migration
Guide on http://docs.hp.com for more information.
To determine if legacy mode DSFs are currently enabled, execute insf –v -L.
# insf -v -L
To disable legacy mode and remove legacy mode DSFs execute rmsf –v -L. Be sure to
convert all legacy mode DSF references to persistent DSFs first!
# rmsf –v –L
To re-enable legacy mode and recreate legacy DSFs, execute insf –L.
# insf –L

Module 6
6–24. LAB: Configuring Device Files
Directions
Carefully follow the instructions below, and record the commands used to answer each
question.
Part 1: Viewing and Interpreting Device Files

For several questions, you will need to know the DSF name of your system boot disk.
Execute the lvlnboot –v command to determine your boot disk device file.
# lvlnboot –v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/disk/diska_p2 -- Boot Disk
Boot: lvol1 on: /dev/disk/diska_p2
Root: lvol3 on: /dev/disk/diska_p2
Swap: lvol2 on: /dev/disk/diska_p2
Dump: lvol2 on: /dev/disk/diska_p2, 0
In the lab solutions for the questions that follow, this disk will be identified as diska.
Record it here:
Boot Disk Persistent DSF: /dev/disk/disk__
1. Some commands require block DSFs; some commands require character DSFs.
Is the boot disk DSF above a block or character DSF?
2. Which kernel driver is associated with this DSF?
3. How can you view a list of the other DSFs associated with the disk? On Integrity
systems, which DSF represents the EFI boot disk partition containing the operating
system?
4. What is the agile view LUN hardware path associated with this DSF?

Module 6
5. When troubleshooting SAN problems, it’s oftentimes helpful to know a LUN’s WWID.
What is the boot disk’s WWID?
6. Servers often access arrays via multiple redundant paths to enhance performance and
availability. How many paths are available to the disk?
7. How can you correlate the boot disk’s persistent DSF with its legacy DSFs?
8. Are there any other disks available on the system? View a list of all of the disk class
devices and their persistent DSFs. Record the persistent block DSF for one of the other
disks on the system below:
Non Boot Disk Persistent DSF: /dev/disk/disk___

In the lab solutions for the questions that follow, this disk will be identified as diskb.

Module 6
Part 2: Managing DSFs with rmsf and insf

1. Use ioscan –kfnN /dev/disk/diskb to determine and record the LUN hardware
path of the spare disk selected in the previous step in the lab. You will need it later in the
lab.
# ioscan –kfnN /dev/disk/diskb
Agile view LUN hardware path: 64000/0xfa00/0x____
2. HP-UX auto-configures commonly used DSFs for new LUNs and devices, so it’s becoming
less and less common for administrators to manually create DSFs. If someone
accidentally removes a DSF, though, it may be necessary for the administrator to recreate
it. Use the following command to remove your spare disk’s block persistent DSF:
# rmsf /dev/disk/diskb
3. Run ioscan –kfnNH followed by the LUN hardware path identified previously to view
the disk’s persistent DSFs. Did the previous command remove just the block DSF, or did
it remove the raw DSF, too?
# ioscan –kfnNH 64000/0xfa00/0x___
4. Oops... We didn’t really want to remove that DSF. Try running insf –v –H followed by
the LUN hardware path to recreate the missing DSF. Then execute the command a
second time with the –e option. What is the significance of the –e option?
# insf –v –H 64000/0xfa00/0x___
# insf –v –e –H 64000/0xfa00/0x___
5. Run ioscan –kfnNH followed by the LUN hardware path to verify that the DSF is back.
6. HP-UX typically auto-configures DSFs for new devices, but does not remove DSFs when
LUNs and devices are removed from the system. Use the command below to remove
your spare disk LUN hardware path and all of its DSFs.
# rmsf –v –H 64000/0xfa00/0x___
7. Run ioscan –kfnNH followed by the LUN hardware path identified previously. Does
the disk and/or its persistent DSFs still appear in the output?

Module 6
8. Oops... We didn’t really want to remove that device. Run ioscan -fnN to scan for new
hardware. Why was it important to exclude the –k option? Is the missing LUN hardware
path back? What about the DSFs?
# ioscan –fnN | more
9. In 11i v3, the kernel and ioscan automatically create DSFs for new devices. In 11i v1
and v2, the administrator must either reboot or manually run insf to create DSFs for
new devices and LUNs. Though not necessary in 11i v3, go ahead and run insf to install
DSFs for any devices that might be missing DSFs.
# insf –v -e

Module 6
Part 3: (Optional) Managing DSFs with mksf

insf only creates the DSFs most commonly required by a device. Administrators who
require unusual DSFs may have to create additional DSFs with the mksf command. This part
of the lab explores the options required to accomplish this, specifically by creating a DSF for
a serial printer. If your lab system doesn’t have serial port, or if time is short, your instructor
may suggest skipping this portion of the lab.
1. First, determine your server’s serial port hardware path and view a list of existing DSFs.
Note the hardware path and driver name.
# ioscan –kfnNC tty
Hardware Path: ___________________
Driver Name: ___________________
2. View the mksf(1m) man page. Search for the list of mksf options supported by the
asynchronous I/O (asio0) driver. Which option may be used to create a line printer
DSF?
# man 1m mksf type /asio to search for the asio driver portion of the man page
3. Create a DSF for a line printer attached to the serial port identified in step 1 above.
4. Run the ioscan command again to verify your work. There should be a cxpx_lp DSF.

Module 6
6–25. LAB SOLUTIONS: Configuring Device Files
Directions
Carefully follow the instructions below, and record the commands used to answer each
question.
Part 1: Viewing and Interpreting Device Files

For several questions, you will need to know the DSF name of your system boot disk.
Execute the lvlnboot –v command to determine your boot disk device file.
# lvlnboot –v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/disk/diska_p2 -- Boot Disk
Boot: lvol1 on: /dev/disk/diska_p2
Root: lvol3 on: /dev/disk/diska_p2
Swap: lvol2 on: /dev/disk/diska_p2
Dump: lvol2 on: /dev/disk/diska_p2, 0
In the lab solutions for the questions that follow, this disk will be identified as diska.
Record it here:
Boot Disk Persistent DSF: /dev/disk/disk_____
1. Some commands require block DSFs; some commands require character DSFs.
Is the boot disk DSF above a block or character DSF?
Answer:
# ll /dev/disk/diska
The b at the beginning of the ll output, as well as the fact that the DSF is in the
/dev/disk/ directory rather than /dev/rdisk/, indicate that this is a block DSF.
2. Which kernel driver is associated with this DSF?
Answer:
# lssf /dev/disk/diska
esdisk section 2 at address 64000/0xfa00/0x1 /dev/disk/diska_p2
The driver name will be the first field in the output, and can also be seen as a result of the
lsdev(1m) command.

Module 6
3. How can you view a list of the other DSFs associated with the disk? On Integrity
systems, which DSF represents the EFI boot disk partition containing the operating
system?
Answer:
# ioscan -kfnN /dev/disk/diska or

# ioscan –m lun /dev/disk/diska
PARISC boot disks have just two DSFs: a block DSF and a raw DSF.
Integrity boot disks should have eight DSFs: a block and raw DSF for the entire disk, plus
block and raw DSFs for each of the EFI partitions. The /dev/[r]disk/diska_p2
DSFs represent the OS partition in 11i v3. In 11i v1 and v2, the OS partition DSF ends in
s2.
4. What is the agile view LUN hardware path associated with this DSF?
Answer:
# ioscan -kfnN /dev/disk/diska or

# ioscan –m lun /dev/disk/diska or
# lssf /dev/disk/diska
5. When troubleshooting SAN problems, it’s oftentimes helpful to know a LUN’s WWID.
What is the boot disk’s WWID?
Answer:
# scsimgr get_attr –a wwid -D /dev/rdisk/diska
Look for the WWID line in the output.
6. Servers often access arrays via multiple redundant paths to enhance performance and
availability. How many paths are available to the disk?
Answer:
# ioscan –m lun /dev/rdisk/diska
Count the number of lunpaths.
7. How can you correlate the boot disk’s persistent DSF with its legacy DSFs?
Answer:
# ioscan –m dsf /dev/disk/diska

Module 6
8. Are there any other disks available on the system? View a list of all of the disk class
devices and their persistent DSFs. Record the persistent block DSF for one of the other
disks on the system below:
Non Boot Disk Persistent DSF: /dev/disk/disk___

In the lab solutions for the questions that follow, this disk will be identified as diskb.
Answer:
# ioscan –kfnNC disk or

# ioscan –m lun
There should be at least one disk on the system besides the boot disk.

Module 6
Part 2: Managing DSFs with rmsf and insf

1. Use ioscan –kfnN /dev/disk/diskb to determine and record the LUN hardware
path of the spare disk selected in the previous step in the lab. You will need it later in the
lab.
# ioscan –kfnN /dev/disk/diskb
Agile view LUN hardware path: 64000/0xfa00/0x____
2. HP-UX auto-configures commonly used DSFs for new LUNs and devices, so it’s becoming
less and less common for administrators to manually create DSFs. If someone
accidentally removes a DSF, though, it may be necessary for the administrator to recreate
it. Use the following command to remove your spare disk’s block persistent DSF:
# rmsf /dev/disk/diskb
3. Run ioscan –kfnNH followed by the LUN hardware path identified previously to view
the disk’s persistent DSFs. Did the previous command remove just the block DSF, or did
it remove the raw DSF, too?
Answer:
rmsf only removed the block DSF this time.
4. Oops... We didn’t really want to remove that DSF. Try running insf –v –H followed by
the LUN hardware path to recreate the missing DSF. Then execute the command a
second time with the –e option. What is the significance of the –e option?
# insf –v –H 64000/0xfa00/0x___
# insf –v –e –H 64000/0xfa00/0x___
Answer:
The –e option recreates missing DSFs for existing devices that were previously
configured. The –e option isn’t required when creating DSFs for new devices that haven’t
been previously configured.
5. Run ioscan –kfnNH followed by the LUN hardware path to verify that the DSF is back.
Answer:
Once again, the LUN hardware path should have two DSFs.

Module 6
6. HP-UX typically auto-configures DSFs for new devices, but does not remove DSFs when
LUNs and devices are removed from the system. Use the command below to remove
your spare disk LUN hardware path and all of its DSFs.
# rmsf –v –H 64000/0xfa00/0x___
7. Run ioscan –kfnNH followed by the LUN hardware path identified previously. Does
the disk and/or its persistent DSFs still appear in the output?
Answer:
Neither the disk’s agile view LUN hardware path nor its persistent DSFs appear in the
ioscan output.
8. Oops... We didn’t really want to remove that device. Run ioscan -fnN to scan for new
hardware. Why was it important to exclude the –k option? Is the missing LUN hardware
path back? What about the DSFs?
# ioscan –fnN | more
Answer:
The –k option uses cached hardware information. Excluding –k forces ioscan to scan
for new devices, thus re-recognizing the spare disk’s LUN hardware path. In 11i v3,
ioscan also automatically creates DSFs for new devices, so the DSFs should be back,
too.
9. In 11i v3, the kernel and ioscan automatically create DSFs for new devices. In 11i v1
and v2, the administrator must either reboot or manually run insf to create DSFs for
new devices and LUNs. Though not necessary in 11i v3, go ahead and run insf to install
DSFs for any devices that might be missing DSFs.
# insf –v -e

Module 6
Part 3: (Optional) Managing DSFs with mksf

insf only creates the DSFs most commonly required by a device. Administrators who
require unusual DSFs may have to create additional DSFs with the mksf command. This part
of the lab explores the options required to accomplish this, specifically by creating a DSF for
a serial printer. If your lab system doesn’t have serial port, or if time is short, your instructor
may suggest skipping this portion of the lab.
1. First, determine your server’s serial port hardware path and view a list of existing DSFs.
Note the hardware path and driver name.
Hardware Path: ___________________
Driver Name: ___________________
2. View the mksf(1m) man page. Search for the list of mksf options supported by the
asynchronous I/O (asio0) driver. Which option may be used to create a line printer
DSF?
# man 1m mksf type /asio to search for the asio driver portion of the man page
Answer:
The –l option creates line printer DSFs.
3. Create a DSF for a line printer attached to the serial port identified in step 1 above.
Answer:
# mksf –v –H hwpath –l
4. Run the ioscan command again to verify your work. There should be a cxpx_lp DSF.

Module 6

Module 7 ⎯ Managing Disk Devices
Objectives
• Describe the reasons for disk partitioning.
• Partition a disk using the whole disk layout approach.
• Define the terms Volume Group, Logical Volume, and Physical Volume.
• View the existing LVM configuration.
• Create LVM Physical Volumes, Volume Groups, and Logical Volumes.
• Compare and contrast the advantages and disadvantages of the whole disk layout
approach, LVM, and the Veritas Volume Manager.
• Compare and contrast the advantages and disadvantages of LVMv1.0 and LVM v2.x.

Module 7
Managing Disk Devices
7–1. SLIDE: Disk Partitioning Concepts
Disk Partitioning Concepts

• Every disk on an HP-UX system may include one or more disk partitions
• HP-UX supports three different solutions for creating and managing partitions
• Each partition can be used for:
– A file system
/home file system
– Swap space
– Raw application data /data file system
• Partitions can be configured using:
– The Whole Disk Approach raw oracle data

– Logical Volume Manager (LVM)
swap space
– Veritas Volume Manager (VxVM)
Student Notes
Disk space is organized into partitions. A partition is nothing more than a portion of disk
space allocated for a particular purpose. A partition can span one disk, multiple disks, or a
portion of a disk. Each partition can contain one of the following:
• A file system (space allocated for files and directories)

• A swap area (space used by the kernel to supplement physical memory)
• Raw data (data accessed directly by an application, such as a database)
• A boot area (space containing utilities used during the boot process)
HP-UX offers three different approaches for creating and managing disk partitions:
• The whole disk approach

• The Logical Volume Manager (LVM)
• The Veritas Volume Manager (VxVM)

Module 7
Some of the disks on your system can be configured using the whole disk layout approach,
while others can be configured using LVM. All three techniques can be used concurrently on
the same system, but not on the same disk.
All three approaches have advantages and disadvantages. This chapter will discuss all three
disk-partitioning techniques, but will emphasize LVM, which is currently the most common
disk space management solution on HP-UX.

Module 7
7–2. SLIDE: Whole Disk Partitioning Concepts
Whole Disk Partitioning Concepts

• The whole disk approach supports partitioning a disk five different ways
• However, the whole disk approach has three significant limitations
– Partitions can’t span multiple disks
– Each disk can contain at most one file system partition
– Partitions can’t be easily extended
File System Swap Space Raw Space
Boot Area
File System
File System
Swap
Swap
Student Notes
Using the whole disk approach, a disk may be configured five different ways:
• The disk can be dedicated entirely for use by a single file system via the newfs
command. See the file system module later in the course for details.
# newfs /dev/rdisk/disk1
• The disk can be dedicated entirely for use as swap via the swapon command. See the
swap module later in the course for details.
# swapon /dev/disk/disk1
• The disk can be dedicated entirely for use as raw disk space for an application. See your
application’s documentation for more information.
• The disk can contain a file system and swap space. The example below configures a file
system at the top of the disk, reserving 1024MB at the end of the disk for use as swap
space. See the swap module later in the course for details.

Module 7
# newfs –R 1024 /dev/rdisk/disk1

# swapon –e /dev/disk/disk1
• A disk can be configured as a boot disk, containing the root file system, a swap area, and
a boot area containing utilities used during the boot process. Use Ignite-UX to configure
whole-disk boot devices. To learn more about boot disks, see the OS installation chapter
later in the course.
Though the whole disk approach is easy to use, it has several limitations:
• A file system cannot span multiple disks.
• Each disk can contain at most one file system partition
• Partitions can’t be easily extended when more space is needed.

For these reasons, many administrators choose to use the Logical Volume Manager to
manage disk space instead of the whole disk approach.

Module 7
7–3. SLIDE: Logical Volume Manager Concepts
Logical Volume Manager Concepts
• HP’s LVM volume manager is much more flexible than the whole disk approach
– Partitions/volumes can span multiple disks
– Multiple partitions/volumes may be configured on a single disk
– Partitions/volumes can be easily extended and reduced as needs change
• LVM is included in all current versions of HP-UX
– BaseLVM is included with the operating system
– LVM Mirrordisk/UX is available for an extra charge
Physical Physical Volume

Volume Volume Group
Logical Volumes
Student Notes
Logical Volume Manager (LVM) makes it possible to pool space from several disks (known as
"Physical Volumes") to form a "Volume Group". You can then subdivide the space in the
volume group into "Logical Volumes" (the LVM equivalent of a partition). Logical Volume
Manager (LVM) overcomes the limitations of the whole disk layout scheme by making it
possible to:
• Create volumes that span multiple disks.
• Create logical volumes on a single disk.
• Extend and reduce volumes as necessary.
LVM is available for all current versions of HP-UX.
The BaseLVM product, which provides functionality for creating, extending, reducing
volumes is included with HP-UX. The BaseLVM product also enables LVM “striping”, which
load balances I/O across multiple disks or disk controllers.

Module 7
Customers who manage mission critical servers may wish to purchase the add-on
Mirrordisk/UX license, which enables LVM to maintain redundant copies of a volume.
Customers who use disk arrays that provide hardware-based mirroring generally do not
require the Mirrordisk/UX license. To learn more about LVM mirroring, attend HP Customer
Education’s LVM course (H6285S).
The remaining slides in this chapter describe LVM concepts and basic commands in detail.

Module 7
7–4. SLIDE: LVM Physical Volume Concepts
LVM Physical Volume Concepts
• Any disk that has been initialized for use in LVM via the pvcreate
command is considered to be an LVM Physical Volume
• Any disk, from a simple internal SCSI or SAS disk, to a disk array LUN
may be configured as a Physical Volume
VG: vg00 VG: vgdbase
LV: lvol1 (100MB) LV: tables (10GB)

LV: lvol2 (1024MB) LV: index (1GB)
LV: lvol3 (1024MB) LV: logs (1GB)
PV PV PV PV PV PV
Student Notes
A disk managed by LVM is known as a physical volume. Any disk, from a simple internal
SCSI or SAS disk, to a LUN on a disk array may be configured as a Physical Volume.
Several special data structures must be created on a disk before it can be used by LVM. The
size of these structures is determined by the parameters that are chosen at the time the
physical volume and associated volume group are created, and may range from one megabyte
to a few hundred megabytes in very large volume groups.
Once these data structures have been created, the disk is considered to be a physical volume,
and may be added to a volume group.
Physical volumes are identified by their corresponding disk DSF names.
HP-UX 11i v1 and v2 physical volume examples:

• /dev/dsk/c1t1d1 and /dev/rdsk/c1t1d1
• /dev/dsk/c2t2d2 and /dev/rdsk/c2t2d2
HP-UX 11i v3 physical volume examples:

Module 7
• /dev/disk/disk1 and /dev/rdisk/disk1

• /dev/disk/disk2 and /dev/rdisk/disk2
Although you may have a combination of LVM disks, VxVM disks, and whole disks on your
system, any given disk may only be managed by one volume manager.

Module 7
7–5. SLIDE: LVM Volume Group Concepts
LVM Volume Group Concepts
• An LVM volume group is a group of disks that have been initialized for use
by LVM that are managed together as unit
• A system may have one or many volume groups

PV PV PV PV PV PV
Student Notes
A volume group is a group of one or more physical volumes. The physical volumes in a
volume group form a pool of disk space which may be allocated to one or more logical
volumes.
Naming Convention
Volume groups usually conform to the following naming convention:
• /dev/vg00
• /dev/vg01
• /dev/vg02
You can stray from the numeric naming convention, but HP recommends that you prefix each
volume group name with “vg”:
• /dev/vgoracle
• /dev/vgeurope

Module 7
• /dev/vgmarketing
vg00 is a special volume group known as the "root volume group" which typically contains
the default boot disk and the majority of the HP-UX operating system. HP strongly
recommends that vg00 be used only for primary swap and OS-related file systems such as /,
/stand, and perhaps /tmp, /var, and /opt. Create other volume groups on your system
for user and application data based on your users’ needs. Following this recommendation
greatly simplifies updates and recovery.

Module 7
7–6. SLIDE: LVM Logical Volume Concepts
LVM Logical Volume Concepts
• An LVM Logical Volume is a virtual partition of disk space within a volume group
• A logical volume may occupy a portion of a single disk, or may span multiple disks
• Logical volumes can be easily extended and reduced as necessary
• A logical volume may be used to store a file system, swap, or raw application data

PV PV PV PV PV PV
Student Notes
Disk space from a volume group may be allocated to one or more logical volumes. A logical
volume is a virtual partition of disk space within a volume group. Like physical disks, a
logical volume may contain a file system, swap area, or raw space for an application.
• Logical volumes can encompass all of, or any portion of, the space on a physical volume.
• Logical volumes can span multiple LVM physical volumes.
• Logical volumes can be resized, or even moved to a different physical volume in the
volume group if the need arises.
• Logical volumes can be mirrored, striped, or distributed to improve performance and/or

availability. To learn more about mirrored and striped logical volumes, attend HP’s LVM
course (H6285S).
• A logical volume may contain a file system, swap area, or raw space for an application.
By default, LVM assigns logical volume names as follows:

Module 7
• /dev/vg01/lvol1
• /dev/vg01/lvol2
• /dev/vg01/lvol3
However, it is best to use logical volume names that describe the volume contents:
• /dev/vg01/datavol
• /dev/vg01/swapvol
• /dev/vg01/oraclevol

Module 7
7–7. SLIDE: LVM Extent Concepts
LVM Extent Concepts

• LVM allocates and manages disk space in units known as Extents
• When a PV is added to a VG, it is subdivided into multiple, equal-size Physical Extents
• When an LV is created, it is allocated one or more equal-size Logical Extents
• Each Logical Extent must map to a Physical Extent on a PV
• LVM stores these extent maps in header structures at the top of every PV
LEs for lvol1 VG01

LE0 PV0:PE0
LE1 PV0:PE1
LE2 PV0:PE2
PV0:PE3
LEs for lvol2 PV1:PE0
LE0 PV1:PE1
LE1 PV1:PE2
LE2 PV1:PE3
Student Notes
LVM manages disk space in units known as extents. An extent represents the smallest
allocatable unit of space in an LVM volume group.
When you add a physical volume to a volume group, LVM subdivides the physical volume into
multiple, equal-size physical extents (PEs). The physical extents are added to the volume
group’s extent map.
A logical volume consists of a series of sequentially numbered, equal-size logical extents

(LEs). Each logical extent is nothing more than a pointer to a physical extent on disk. Larger
logical volumes have more logical extents, and smaller logical volumes have fewer logical
extents. In order to make a logical volume larger, LVM need only allocate additional extents.
LVM stores a volume group’s logical to physical extent map in the headers at the top of each
disk in the volume group.
The volume group shown on the slide, vg01, has two logical volumes. Each logical volume
has three logical extents. Each logical extent is a pointer to a physical extent on the disk.
Note that the physical extents associated with a logical volume may or may not reside on the

Module 7
same physical volume. In the example on the slide, the first physical extent for lvol2 is on
the first physical volume, while the remaining physical extents reside on the second physical
volume. This ability to overcome physical disk boundary limitations is one of the primary
advantages that LVM offers over the whole disk layout approach.

Module 7
7–8. SLIDE: LVM Extent Size Concepts
LVM Extent Size Concepts
The extent size is configurable on a per-VG basis

• Valid extent sizes range from 1MB to 256MB
• A smaller extent size provides more flexibility when creating smaller LVs
• A larger extent size enables creation of larger volumes, and less header space
• The extent size has no direct impact on LVM performance
• The extent size may not be changed after volume group creation
Questions
1. What is the smallest possible LV …
a) If your extent size is 1MB?
b) If your extent size is 256MB?
2. How many extents would be required to manage a 4GB disk …
a) Given a 1MB extent size?
b) Given a 4MB extent size?
c) Given a 256MB extent size?
Student Notes
The PE and LE sizes are consistent throughout a volume group, and may be set when the
volume group is initially created. Supported extent sizes are: 1MB, 2MB, 4MB, 8MB, 16MB,
32MB, 64MB, 128MB, and 256MB. In LVMv1, the default extent size is 4MB. In LVMv2, there
is no default extent size; the extent size must be specified by the administrator.
The extent size determines the minimum unit of space that can be allocated to a logical
volume. If you use the default 4MB extent size, every logical volume in your volume group
must be a multiple of 4MB (4MB, 8MB, 12MB, 16MB, 20MB, 24MB, etc.). If you use a 256MB
extent size, every logical volume must be a multiple of 256MB (256MB, 512MB, 768MB, etc.).
Thus, a smaller extent size allows you to specify logical volume sizes to a finer level of
granularity.
The extent size also helps determine the maximum physical volume size allowed in a volume
group.
In 11i v1 and v2, the administrator defines max PE/PV at volume group creation. The
parameter must be between one and 65535. The default is 1016, or the number of extents
required to represent the largest disk initially added to the volume group. Thus, accepting

Module 7
the default extent size (4MB) and max PE/PV value (1016) allows a volume group to support
physical volumes no larger than 4MB x 1016 = 4064MB. Increasing the extent size to 256MB
allows a volume group to support physical volumes up to 256MB x 1016 = 260096MB.
In 11i v3, LVMv2.x provides much more flexibility. You still must define an extent size, but
instead of defining a PE/PV value, you simply specify the maximum expected volume group
size. LVM automatically calculates the number of physical extents required to accommodate
the specified maximum volume group size. Using the 11i v3 vgmodify command, you can
easily change the maximum volume group size later. The next slide discusses LVM versions
in much greater detail.
In general, if you expect to have very large physical and logical volumes in a volume group, it
makes sense to select a larger extent size when you create the volume group.
Note that the extent size may impact the size of the LVM headers, but it does not directly
impact system performance.

Module 7
7–9. SLIDE: LVM Volume Group Versions and Limits
LVM Volume Group Versions and Limits

• HP currently supports three LVM VG versions; the newer VG versions provide greater
expandability
• Multiple VG versions may be used concurrently on a system
• The latest 11i v3 release can use any LVM volume group, regardless of the VG version
Expandability LVM v1.0 LVM v2.0 LVM v2.1 LVM v2.2

HP-UX Version Supported >=11.11 >=11.31.0803 >=11.31.0809 >=11.31.1003
Max VG Size (Tbytes) 510 2048 2048 2048
Max LV Size (Tbytes) 16 256 256 256
Max PV Size (Tbytes) 2 16 16 16
Max VGs 256 512 2048 2048
Max LVs 255 511 2047 2047
Max PVs 255 511 2048 2048
Max Mirrors 2 5 5 5
Max Stripes 255 511 511 511
Max Stripe Size (Kbytes) 32768 262144 262144 262144
Max Logical Extents per LV 65535 33554432 33554432 33554432
Max Physical Extents per PV 65535 16777216 16777216 16777216
Max Extent Size (Mbytes) 256 256 256 256
Student Notes
HP currently supports several LVM volume group versions. The LVM volume group version
determines the maximum size disks and volumes that may be configured in a volume group,
and impacts the availability of other LVM features, too. As shown on the slide, the newer
volume group versions provide much greater expandability than LVMv1.0.
HP-UX 11i v1 and v2 only support LVMv1.0 volume groups. LVMv2.x volume groups may not
be used on 11i v1 and 11i v2 systems.
The latest 11i v3 release can use any LVM volume group regardless of the VG version. To
ensure backwards compatibility, LVMv1.0 remains the default volume group version for new
volume groups in 11i v3, but the administrator can request any volume group version at
volume group creation. Multiple layouts may be used concurrently on a system, but not in a
single volume group. Boot disks must be configured via LVM v1.0 or LVMv2.2; not LVM v2.0
or LVMv2.1.
To determine which version(s) of LVM are supported on your system, execute lvmadm –t.
If the command doesn’t exist, your system only supports LVMv1.0. Otherwise, the command
displays the currently supported LVM versions, and their associated limits.

Module 7
11i v3 now includes a vgversion command for upgrading LVMv1.0 volume groups to
LVMv2.x. To learn more about the vgversion command, attend HP Customer Education’s
LVM class (H6285S).
HP-UX imposes several restrictions on LVM volume groups and physical volumes, and these
limits vary significantly, as reported by the lvmadm command.
# lvmadm -t
--- LVM Limits ---
VG Version 1.0
Max VG Size (Tbytes) 510
Max LV Size (Tbytes) 16
Max PV Size (Tbytes) 2
Max VGs 256
Max LVs 255
Max PVs 255
Max Mirrors 2
Max Stripes 255
Max Stripe Size (Kbytes) 32768
Max LXs per LV 65535
Max PXs per PV 65535
Max Extent Size (Mbytes) 256
VG Version 2.0
Max VGs 512
Max LVs 511
Max PVs 511
Max Mirrors 5
Max Stripes 511
VG Version 2.1
Max VGs 2048
Max LVs 2047
Max PVs 2048
Max Mirrors 5
Max Stripes 511

Module 7
VG Version 2.2
Max VGs 2048
Max LVs 2047
Max PVs 2048
Max Mirrors 5
Max Stripes 511
Min Unshare unit(Kbytes) 512
Max Unshare unit(Kbytes) 4096
Max Snapshots per LV 255

Module 7
7–10. SLIDE: LVM DSF Directories
LVM DSF Directories

Like physical disks, LVM volume groups and logical volumes are identified and
accessed via device files under /dev
/dev
disk rdisk vg01
disk1 disk1 group VG DSF
disk2 disk2 datavol LV Block DSF
disk3 disk3 rdatavol LV Raw DSF
swapvol LV Block DSF

Block PV DSFs Raw PV DSFs
rswapvol LV Raw DSF
Student Notes
Physical volumes, volume groups, and logical volumes are all referenced via DSFs just as disk
devices are referenced via DSFs.
Physical Volume DSFs

Since disks may be referenced in either block or character mode, each physical volume has
both a block and a character DSF.
The examples below represent 11i v1 and v2 physical volume DSFs:
/dev/dsk/c1t1d1 block DSF

/dev/rdsk/c1t1d1 raw DSF
The examples below represent 11i v3 physical volume DSFs:
/dev/disk/disk1 block DSF

/dev/rdisk/disk1 raw DSF

Module 7
Volume Group DSFs

Volume groups are referenced via DSFs, too. Each volume group has a subdirectory under
/dev containing a group DSF for the volume group itself, as well as the DSFs for all of the
logical volumes within the volume group. The name of the volume group's subdirectory
determines the volume group's name.
/dev/vg01 directory containing DSFs associated with vg01

/dev/vg01/group DSF for volume group vg01
Logical Volume DSFs

Logical volume DSFs are stored in the directory of the volume group to which they belong.
Each logical volume has two DSFs: one is used when accessing the logical volume in
character mode; the other is used when accessing the logical volume in block mode.
/dev/vg01/lvol1 block DSF for logical volume "lvol1" in vg01

/dev/vg01/rlvol1 raw DSF for logical volume "lvol1" in vg01

Module 7
7–11. SLIDE: LVMv1 Volume Group and Logical Volume DSFs
LVMv1 Volume Group and Logical Volume DSFs
• Each VG has a character device file called “group”

• Each LV has one character device file, and one block device file
• LVMv1 DSFs always have major# 64
• The first two digits in the minor# indicate the VG#, 0x00-0xff
• The last two digits in the minor# indicate the LV#, 0x00-0xff (0x00 for group)
/dev/vg01 VG LV
/dev/vg01/group c 64 0x010000
/dev/vg01/lvol1 b 64 0x010001
/dev/vg01/lvol2 b 64 0x010002
/dev/vg01/rlvol1 c 64 0x010001
/dev/vg01/rlvol2 c 64 0x010002
VG/LV Name Block/Character Major# Minor#
Student Notes
Like all other DSFs, every logical volume and volume group DSF must have a major and a
minor number. The major and minor numbers are slightly different in LVMv1 versus LVMv2.
This slide focuses on LVMv1. The next slide focuses on LVMv2 major and minor numbers.
LVMv1 Volume Group DSFs

Each volume group has a subdirectory under /dev containing a group DSF for the volume
group itself, as well as the DSFs for all of the logical volumes within the volume group. The
name of the volume group's subdirectory determines the volume group's name.
/dev/vg01 directory containing DSFs associated with vg01
The volume group subdirectory must contain a group DSF that represents the volume group.
/dev/vg01/group DSF for volume group vg01

Module 7
The group DSF must have a major and a minor number. All LVMv1 DSFs use major number
64, the major number associated with the LVMv1 kernel driver.
The first two digits of the group DSF’s minor number uniquely identify the DSF’s volume
group. The remaining bits in the group DSF’s minor number must be 0000.
When using numeric volume group names, match the first two digits of the minor number to
the volume group number. Thus, the minor number for /dev/vg01/group would typically
be 0x010000.
When using non-numeric volume group names, simply ensure that the first two digits of the
group DSF minor number are unique.
LVMv1 Logical Volume DSFs

Logical volume DSFs are stored in the directory of the volume group to which they belong.
Each logical volume has two DSFs: one is used when accessing the logical volume in
raw/character mode; the other is used when accessing the logical volume in block mode.
/dev/vg01/lvol1 block DSF for logical volume "lvol1" in vg01

/dev/vg01/rlvol1 raw DSF for logical volume "lvol1" in vg01
The major number for both logical volume DSFs should be 64, the major number associated
with the LVMv1 kernel driver.
The first two digits of each DSF’s minor number identify which volume group the DSF is
associated with. The last two digits identify the logical volume associated with the DSF.
Thus, the minor number for /dev/vg01/lvol2 would typically be 0x010002.
When using non-numeric logical volume names, simply ensure that the last two digits are
unique.
The example on the slide lists some typical major and minor numbers for an LVMv1 volume
group.
Questions
If vg02 has three logical volumes created using the default naming convention:
1. What directory would contain the logical volumes' DSFs?
2. What would be the name of the volume group's DSF?
3. What would be the name of the first logical volume's raw DSF?
4. Overall, how many DSFs should you find in /dev/vg02?
5. What would be the minor number of the third logical volume's DSF?

Module 7
7–12. SLIDE: LVMv2 Volume Group and Logical Volume DSFs
LVMv2 Volume Group and Logical Volume DSFs
• Each VG has a character device file called “group”

• Each LV has one character device file, and one block device file
• LVMv2 DSFs always have major# 128
• The first three digits in the minor# indicate the VG#, 0x000-0x7ff
• The last three digits in the minor# indicate the LV#, 0x001-0x7ff (0x000 for group)
/dev/vg01 VG LV
/dev/vg01/group c 128 0x001000
/dev/vg01/lvol1 b 128 0x001001
/dev/vg01/lvol2 b 128 0x001002
/dev/vg01/rlvol1 c 128 0x001001
/dev/vg01/rlvol2 c 128 0x001002
VG/LV Name Block/Character Major# Minor#
Student Notes
LVMv2.x volume group and logical volume DSFs are structured slightly differently. The
LVMv2.x major number is 128 rather than 64.
Also, to accommodate more volume groups per host, and more logical volumes per volume
group, LVMv2.x DSFs use all six digits in the volume group and logical volume minor
numbers.
The first three digits represent the volume group to which a DSF belongs and may range in
value from 0x000 to 0x7ff (0 to 2047 in decimal).
The last three digits uniquely identify the logical volumes within a volume group and may
also range in value from 0x001 to 0x7ff (1 to 2047 in decimal). The volume group’s group
device file claims the 0x000 minor number.
When using non-numeric volume group or logical names, simply ensure that the minor
number is unique.
The example on the slide lists some typical major and minor numbers for an LVMv2.x volume
group.

Module 7
7–13. SLIDE: Creating Physical Volumes
Creating Physical Volumes

Before adding a disk to an LVM volume group,
initialize PVRA/VGRA headers on the disk via pvcreate
PVRA/VGRA PVRA/VGRA
disk1 disk2
Determine which disks already belong to volume groups

# strings /etc/lvmtab 11i v1 and v2
# lvmadm –l 11i v3 only
Initialize the physical volumes

# pvcreate /dev/rdisk/disk1
# pvcreate /dev/rdisk/disk2
Student Notes
Before you can use space on a disk for logical volumes, you must configure the disk as an
LVM physical volume. Once the disk has been configured as a physical volume, you can add
the disk to a volume group and begin allocating space from the disk to logical volumes.
Preparing a Physical Volume

The disk you want to use as a physical volume must be connected to your system, must be
powered on, and must not belong to an existing volume group. Use ioscan –fnC disk
(11i v1 and v2) or ioscan –fnNC disk (11i v3) to view a list of disks on the system.
LVM uses two binary configuration files to record which disks belong to LVM volume groups.
/etc/lvmtab contains a list of existing LVMv1.0 volume groups and physical volumes.
/etc/lvmtab_p contains a list of LVMv2.x volume groups and disks, if any.
On 11i v1 and v2 systems you can use the strings command to view the ASCII contents of
/etc/lvmtab and determine which disks belong to volume groups.
# strings /etc/lvmtab

Module 7
/dev/vg00
/dev/disk/disk0_p2
/dev/vg01
/dev/disk/disk1
/dev/disk/disk2
On 11i v3, the new lvmadm –l command displays the contents of /etc/lvmtab and
/etc/lvmtab_p in a more user-friendly format.
# lvmadm -l
--- Version 1.0 volume groups ---
VG Name /dev/vg00
PV Name /dev/disk/disk0_p2
--- Version 2.2 volume groups ---

VG Name /dev/vg01
PV Name /dev/disk/disk1
/dev/disk/disk2
Compare the ioscan output to the output from strings and lvmadm -l to determine
which disks are available for use as LVM physical volumes. Disks that appear in the ioscan
output, but not in the strings or lvmadm output do not currently belong to LVM volume
groups.
LVMv1.0 supports physical volumes up to 2TB. 11i v1 requires patch PHKL_30622 to support
physical volumes greater than 256GB. 11i v2 requires patch PHKL_31500. 11i v3 includes
large physical volume support by default.
LVMv2.x supports much larger physical volumes up to 16TB.
Use the diskinfo command to determine the size of a prospective physical volume.
# diskinfo /dev/rdisk/disk1
SCSI describe of /dev/rdisk/disk1:
vendor: HP
product id: HSV101
type: direct access
size: 35651584 Kbytes
bytes per sector: 512
Next, execute the pvcreate command to create LVM header structures on the disk. If the
disk was previously part of another volume group, you may need to use the -f option on
pvcreate. The example on the slide uses 11i v3 persistent disk DSFs. In 11i v1 and v2, use
legacy DSFs instead.
# pvcreate -f /dev/rdisk/disk1
# pvcreate -f /dev/rdisk/disk2
Your disk is now ready to be added to a new or existing volume group.

Module 7
LVM Data Structures

LVM stores information in data structures at the beginning of the Physical Volume.
• The Physical Volume Reserved Area (PVRA) contains LVM information specific to
that Physical Volume. It is created by the pvcreate(1M).
• The Volume Group Reserved Area (VGRA) contains LVM information specific to the
entire Volume Group. LVM maintains a copy of the VGRA on each Physical Volume in the
Volume Group. The VGRA includes a Volume Group Status Area (VGSA) which contains
quorum information for the Volume Group, and the Volume Group Descriptor Area
(VGDA) which contains additional configuration information required by the LVM kernel
driver. The VGRA is created by vgcreate(1M).
• The User Data Area contains the physical extents that are allocated to file systems,
virtual memory (swap), or user applications. When a volume group is created, the user
data area is divided into fixed-size physical extents, which map to logical extents. The
map of Logical Extents is contained in the VGRA.
• In earlier versions of HP-UX, LVM compensated for disk irregularities by “relocating” data
that would otherwise have been written to unusable disk blocks to the Bad Block
Relocation Area (BBRA) at the end of the disk. Today, bad block relocation
functionality is provided by disk firmware so the BBRA is irrelevant. To avoid creating a
BBRA, include the –d 0 option on pvcreate. BBRA is no longer created in LVMv2.x
volume groups.
• LVM boot disks contain a Boot Disk Reserved Area (BDRA) and other additional data
structures required by the boot process.
LVM Overhead
The LVM header structures consume some disk space at the top of every physical volume.
This overhead is set at a fixed boundary for bootable LVM disks (2912 KB). Disk space
overhead required on non-bootable disks depends on parameters specified by the
administrator when the volume group is created. Increasing the “Max PV/VG” or “Max
PE/PV” parameters in LVMv1.0, or increasing the maximum volume group size parameter in
LVMv2.x, increases the size of the LVM headers. See the vgcreate(1M) man page for
additional information.

Module 7
7–14. SLIDE: Creating LVMv1 Volume Groups
Creating LVMv1 Volume Groups

After initializing physical volumes, initialize a volume group
• Use mkdir to create an LVMv1 volume group DSF directory
• Use mknod to create an LVMv1 volume group DSF file
• Use vgcreate to add the volume group to /etc/lvmtab
vg01
disk1 disk2
# mkdir /dev/vg01
# chown root:sys /dev/vg01; chmod 755 /dev/vg01
# chown root:sys /dev/vg01/group; chmod 640 /dev/vg01/group
# vgcreate vg01 /dev/disk/disk1 /dev/disk/disk2
Student Notes
After initializing physical volumes, initialize a volume group. This slide focuses on the
commands required to create an LVMv1.0 volume group. The next slide describes the
process in LVMv2.x.
Creating the Volume Group Directory

First, create a directory for the volume group. The naming convention is /dev/vgnn, where
nn is a two digit number that isn’t already assigned to another volume group, /dev/vgname
where name describes volume group’s contents and/or purpose. Overall, the directory name
can be no more than 255 characters. The directory name ultimately serves as the volume
group name, too. Note that in 11i v3 0803 and beyond, these steps are optional; vgcreate
can create the volume group directory automatically.
# mkdir /dev/vg01
# chown root:sys /dev/vg01
# chmod 755 /dev/vg01

Module 7
Creating the Volume Group Device File

Next, use the mknod command to create a DSF for the volume group in the new volume
group’s /dev/vgname directory. The DSF name must be “group“, and the DSF must be a
raw/character device file. The major number is always 64. The minor number is
hexadecimal, always ends in 0000, and has the form 0xhh0000, where hh is the
hexadecimal representation of the volume group number. To create a group file for vg01,
you would type:

# chown root:sys /dev/vg01/group
# chmod 640 /dev/vg01/group
Note that in 11i v3 0803 and beyond, these steps are optional; vgcreate can create the
volume group DSF automatically.
In 11i v1 and v2, the maxvgs kernel parameter defines the maximum number of volume
groups allowed on the system, as well as the maximum value supported in the first two digits
of the volume group DSF minor number. The default value in 11i v1 and v2 is 10, which
allows volume group DSF minor numbers from 0x000000 to 0x090000. Use kmtune (11i
v1) or kctune (11i v2) to view the current value of the kernel parameter.
# kctune maxvgs
Tunable Value Expression
maxvgs 10 Default
In 11i v3, maxvgs no longer exists; administrators can create up to 256 LVMv1 volume groups
by default.
Creating the Volume Group and Assigning Physical Volumes

Finally, use vgcreate to add the volume group to LVM’s /etc/lvmtab configuration file
and assign one or more physical volumes to the volume group. Be sure to use the physical
volume block DSFs.
# vgcreate vg01 /dev/disk/disk1 /dev/disk/disk2
LVMv1.0 vgcreate options
Several important options may be specified at volume group creation. These options,
described below, may be defined on a per-volume group basis. Note that the options below
are LVMv1.0-specific. The next slides discuss LVMv2.x.
-l max_logical_vols Determines the maximum number of logical volumes

allowed in the volume group.
Default: 255
Minimum: 1
Maximum: 255
Since the default is also the maximum, and since

Module 7
changing this parameter offers little benefit, most

administrators accept the default.
-p max_physical_vols Determines the maximum number of physical volumes

allowed in the volume group.
Default: 16
Minimum: 1
Maximum: 255
Be sure to change this parameter if you anticipate

having more than 16 physical volumes in the volume
group.
-s physical_extent_size Determines the size, in megabytes, of each physical and

logical extent in the volume group.
Default: 4MB
Minimum: 1MB
Maximum: 256MB
If the volume group may contain large physical volumes

or large logical volumes, this parameter should be
increased to minimize the size of the physical volume
headers.
Note that the extent size in vg00 may not be 4MB.

Ignite-UX selects an extent size for vg00 based on the
size of the disks initially selected for inclusion in the
volume group.
-e max_physical_extents Determines the maximum number of physical extents

per physical volume in the volume group.
Default: 1016*
Minimum: 1
Maximum: 65535
*The default for this parameter is 1016. However, if the

size of any physical volume exceeds 1016 times the
extent size, the default value is adjusted to match the
physical volume that is initially included in the volume
group via vgcreate.
Note that if you accept the default extent size (4MB)

and the default Max PE/PV value (1016), the largest
physical volume that LVM will recognize in your volume
group is approximately 4GB. In most cases, this
parameter should be increased since today’s disks are
typically much larger than 4GB.

Module 7
The vgdisplay command reports the current values for each of these attributes.
# vgdisplay vg01
…
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 4
…
WARNING! In 11i v1, these volume group attributes are set at creation and can’t be
changed later without removing and re-creating the volume group.
Plan your LVM layout carefully before you create your volume groups!
In 11i v2 and v3, all of the LVMv1.0 volume group attributes except the
extent size can be changed via the vgmodify command. Attend HP
Education’s LVM course (H6285S) to learn more about vgmodify.
A Note about Multipathed Disks

The 11i v3 kernel is multi-path aware. Providing any block DSF associated with a physical
volume ensures that the kernel utilizes all available paths to the physical volume.
The 11i v1 and v2 kernel aren’t multi-path aware. In order to provide path failover via the
redundant paths to a physical volume, all of the legacy path DSFs must be provided as
arguments to vgcreate. Thus, in order to create a two-disk volume group, in which each
disk is accessible via four paths, vgcreate requires eight physical volume arguments similar
to the following:
# vgcreate /dev/vg01 \
/dev/dsk/c0t0d1 /dev/dsk/c1t0d1 /dev/dsk/c2t0d1 /dev/dsk/c3t0d1
/dev/dsk/c0t0d2 /dev/dsk/c1t0d2 /dev/dsk/c2t0d2 /dev/dsk/c3t0d2
LVM reports the additional links as PV Links. To learn more about PV link configuration and
management, see the PV Link appendix at the end of this workbook.
Some array vendors offer multi-pathing software for 11i v1 and v2 that virtualize redundant
LUN paths automatically. Consult your array vendor for more information.

Module 7
7–15. SLIDE: Creating LVMv2 Volume Groups
Creating LVMv2 Volume Groups

In LVMv2, vgcreate automatically creates the VG directory and DSFs, and
requires fewer options than the LVMv1 vgcreate command.
vg01
disk1 disk2
Create the volume group

# vgcreate –V 2.2 \ Desired LVM version
–S 1t \ Maximum anticipated VG size
–s 4 vg01 \ Extent size – required!
/dev/disk/disk1 /dev/disk/disk2 Specify one or more PVs
Check attributes
# vgdisplay vg01
--- Volume groups ---
VG Name /dev/vg01
PE Size (Mbytes) 4
VG Version 2.2
VG Max Size 1t
Student Notes
The options required to create an LVMv2.x volume group are significantly different than the
commands required to create an LVMv1.0 volume group. See the example and notes below
for details. Note that vgcreate automatically creates device files for LVMv2.x volume
groups.
# vgcreate –V 2.2 –S 1t –s 4 vg01 /dev/disk/disk1 /dev/disk/disk2
-V 2.0|2.1|2.2 Determines the volume group’s volume group version.

LVMv1.0 is currently the default layout version in all HP-UX
releases, though the newer LVM versions provide greater
expandability and flexibility. You must include the –V version
option when creating LVMv2.x volume groups.
-S 1t Determines the maximum volume group size this volume group

will support. The size may be specified in megabytes (m),
gigabytes (g), terabytes (t), or petabytes (p). If you do not

Module 7
supply a unit suffix, LVM assumes megabytes. This option is

required when creating LVMv2 volume groups.
-s 4 Determines the size, in megabytes, of each physical and logical

extent in the volume group.
Default: None – this option must be explicitly specified

Minimum: 1MB
Maximum: 256MB
Unlike LVMv1.0, LVMv2.x requires the administrator to

explicitly specify an extent size. The extent size impacts the
maximum volume group size. To determine the minimum
possible extent size before creating an LVMv2.x volume group
of a specific size, execute the vgcreate –E command as
shown below:
# vgcreate -V 2.2 -E -S 1p
Max_VG_size=1p:extent_size=32m
Or, use the command below to determine the maximum

volume group size that can be accommodated by a specific
extent size:
# vgcreate -V 2.2 -E -s 1
Max_VG_size=32t:extent_size=1m
/dev/disk/disk1... Specify the list of disks you initially wish to assign to the
volume group. At least one disk is required. LVM records the
LVMv2 volume group / physical volume assignments in
/etc/lvmtab_p and in the volume group’s VGRA headers.
Administrators typically choose to use 11i v3 persistent disk
DSFs when assigning disks to the volume group.
The vgdisplay command reports the current values for each of these attributes, plus
several others that aren’t included below. A slide later in the chapter discusses the
vgdisplay command more formally.
# vgdisplay vg01
…
VG Name /dev/vg01
…
PE Size (Mbytes) 4
VG Version 2.2
VG Max Size 1t
…
The LVMv1.0 vgcreate –p, -l, and -e options don’t apply to LVMv2.x volume groups.

Module 7
7–16. SLIDE: Creating Logical Volumes
Creating Logical Volumes

After creating a volume group, use lvcreate to populate the
volume group with logical volumes
vg01
datavol
disk1 disk2
# lvcreate –n datavol –L 16 vg01

or
# lvcreate -n datavol vg01
# lvextend –L 16 /dev/vg01/datavol /dev/disk/disk1
Student Notes
After creating a volume group, create logical volumes in the volume group via the lvcreate
command. The examples on the slide create two 16MB logical volumes in vg01 called
swapvol and datavol. When lvcreate creates a logical volume, it records the logical
volume’s configuration information in the kernel’s LVM structures and in the LVM headers on
the volume group’s disks. It also creates block and character DSFs for the logical volume in
the volume group’s DSF /dev/vgnn directory.
# lvcreate -L 16 -n swapvol vg01

# lvcreate -L 16 -n datavol vg01
The volume group name is the only required argument. The example below creates two
empty logical volumes in vg01 using default logical volume names lvol1 and lvol2.
# lvcreate vg01
# lvcreate vg01

Module 7
The list below describes some of the most common lvcreate command options:
-L logical_volume_size Specifies the size of the logical volume in megabytes.

The size specified will be rounded up to the nearest
whole logical extent. The default is zero. The
maximum value varies, depending on the volume group
version number. Execute lvmadm -t to determine
the limit for your volume group version.
-l logical_extents_number Specifies the number of logical extents in the logical

volume. The default is zero. The maximum value
varies, depending on the volume group version number.
Execute lvmadm -t to determine the limit for your
volume group version.
-n name Specifies the new logical volume’s name. By default,

lvcreate assigns numeric volume names (e.g.:
lvol1, lvol2, lvol3, ...).
lvcreate supports many other options, too. See the lvcreate(1m) man page or attend
HP Education’s LVM course (H6285S) for more information.

Module 7
7–17. SLIDE: Verifying the Configuration
Verifying the Configuration

Verify Volume Groups:
# vgdisplay
# vgdisplay –v
# vgdisplay –v vg01
Verify Logical Volumes:

# vgdisplay –v vg01 | grep “LV Name”
# lvdisplay /dev/vg01/datavol
# lvdisplay –v /dev/vg01/datavol
Verify Physical Volumes:

# vgdisplay –v vg01 | grep ″PV Name″
# pvdisplay /dev/disk/disk1
# pvdisplay –v /dev/disk/disk1
Student Notes
After creating physical volumes, volume groups, and logical volumes, use pvdisplay,
vgdisplay, and lvdisplay to verify the results.
Viewing Volume Groups

vgdisplay reports a volume group centric view of the configuration. The –v (verbose)
option displays volume group header information, and a summary of each physical volume
and logical volume. Without the verbose option, vgdisplay only reports volume group
header information. In either case, the command can be executed with or without a volume
group name. Without a volume group name, it lists all of the volume groups on the system.
For LVMv1:
# vgdisplay -v vg01
VG Name /dev/vg01
VG Write Access read/write
VG Status available

Module 7
Max LV 2047
Cur LV 0
Open LV 0
Max PV 2048
Cur PV 2
Act PV 2
Max PE per PV 262144
VGDA 4
PE Size (Mbytes) 4
Total PE 500
Alloc PE 8
Free PE 492
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 2.2 this line only appears in 11i v3
VG Max Size 1t this line only appears in 11i v3
VG Max Extents 262144 this line only appears in 11i v3
--- Logical volumes ---

LV Name /dev/vg01/swapvol
LV Status available/syncd
LV Size (Mbytes) 16
Current LE 4
Allocated PE 4
Used PV 1
LV Name /dev/vg01/datavol
LV Size (Mbytes) 16
Current LE 4
Allocated PE 4
Used PV 1
--- Physical volumes ---

PV Status available
Total PE 250
Free PE 242
PV Status available
Total PE 250
Free PE 250
Viewing Logical Volumes

In order to view logical volume information, first use vgdisplay –v to get a list of logical
volume names.
# vgdisplay –v vg01 | grep "LV Name"


Module 7
Then use lvdisplay –v (verbose) to display a logical volume’s header information, plus
the logical volume’s extent map. Without the verbose option, lvdisplay only reports
logical volume header information.
# lvdisplay -v /dev/vg01/swapvol
VG Name /dev/vg01
LV Permission read/write
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 16
Current LE 4
Allocated PE 4
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default
--- Distribution of logical volume ---

PV Name LE on PV PE on PV
/dev/disk/disk1 4 4
--- Logical extents ---

LE PV1 PE1 Status 1
0000 /dev/disk/disk1 0000 current
# lvdisplay -v /dev/vg01/datavol
VG Name /dev/vg01
LV Permission read/write
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 16
Current LE 4
Allocated PE 4
Stripes 0
Stripe Size (Kbytes) 0
Bad block NONE
Allocation strict

Module 7
IO Timeout (Seconds) default
--- Distribution of logical volume ---

PV Name LE on PV PE on PV
/dev/disk/disk1 4 4
--- Logical extents ---

LE PV1 PE1 Status 1
Viewing Physical Volumes

In order to view logical volume information, first use vgdisplay –v to get a list of physical
volume names.
# vgdisplay –v vg01 | grep "PV Name"

Then use pvdisplay –v (verbose) to display a physical volume’s header information, plus
an extent map. Without the verbose option, pvdisplay only reports physical volume
header information.
# pvdisplay –v /dev/disk/disk1
--- Physical volumes ---
VG Name /dev/vg01
PV Status available
Allocatable yes
VGDA 2
Cur LV 2
PE Size (Mbytes) 4
Total PE 250
Free PE 242
Allocated PE 8
Stale PE 0
IO Timeout default
Autoswitch On
Proactive Polling On
--- Distribution of physical volume ---

LV Name LE of LV PE for LV
/dev/vg01/swapvol 4 4
/dev/vg01/datavol 4 4
--- Physical extents ---

PE Status LV LE
00000 current /dev/vg01/swapvol 00000

Module 7

00004 current /dev/vg01/datavol 00004
00008 free 00000
00009 free 00000
00010 free 00000

Module 7
7–18. SLIDE: Disk Space Management Tool Comparison
Disk Space Management Tool Comparison
Whole Disk LVM VxVM

HP-UX versions supported 10.x,11.x,11i 10.x,11.x,11i 11i
Boot disk support? Yes Yes Yes
GUI configuration tool available? sam, smh sam, smh vea
Available on other platforms? Similar Similar Yes
Can partitions span disks? No Yes Yes
Online resizing supported? No Yes Yes
Online backups supported? No Yes* Yes*
Striping (RAID 0) supported? No Yes Yes
Mirroring (RAID 1) supported? No Yes* Yes*
Mirrored stripes (RAID 0/1) supported? No Yes* Yes*
RAID 5 supported? No No Yes*
Dynamic relayout support? No No Yes*
Dynamic multi-pathing support? No Active/Passive Active/Active*
* Features indicated by an asterisk may require an extra license
Student Notes
The first slide in this chapter noted that HP-UX now supports three different disk space
management solutions. Depending on your system's needs, you can choose to use one, two,
or all three solutions on your system. This slide compares the relative advantages and
disadvantages of each approach.
HP-UX Versions Supported

The whole disk approach and LVM are available on all current versions of HP-UX. VxVM is
only supported in HP-UX 11i v1 and later versions of HP-UX.
The earliest versions of VxVM could only be used to configure HP-UX data disks. However,
VxVM 3.5, which is the current version of VxVM on 11i v1 and v2, and VxVM 4.1 and 5.0 on v3,
can be used to manage both data and boot disks.

Module 7
GUI Configuration Tool Available?

Whole disk and LVM partitions can be configured through sam (11i v1 and v2) or the SMH
fsweb GUI/TUI interface (11i v2 and v3). VxVM supports a Java-based interface called
Veritas Enterprise Administrator (vea) in all current versions of HP-UX.
Available on Other Platforms?

Some variation of the whole disk layout approach is available on almost all UNIX platforms.
Logical Volume Manager is included with most Linux distributions, and AIX includes a similar
volume manager. LVM commands on HP-UX and Linux are nearly identical. Volume
manager commands on AIX are different.
Veritas supports VxVM on Linux, most major commercial UNIX flavors, and even on
Microsoft Windows. VxVM commands are identical across platforms.
Can Partitions Span Disks?

Today's databases are oftentimes several hundred gigabytes in size, and can span multiple
disks. LVM and VxVM make this possible by allowing logical partitions to span multiple
physical disks. Partitions created using the whole disk approach cannot span disks.
Online Resizing Supported?

Partitions configured via the whole disk layout approach can't be resized. LVM and VxVM
both allow the administrator to extend and reduce partitions at will, while disks are being
accessed.
Online Backups Supported?

More and more IT shops today operate 24 hours per day, 7 days per week. These "always-on"
environments make it difficult to perform system backups, since data files are constantly
changing. Both LVM and VxVM make it possible to perform backups on a "live" volume. This
functionality requires an additional license.
Striping (RAID 0) Supported?

Striping maps a partition's data so that the data is interleaved among two or more physical
disks to ensure that each disk shares an equal portion of the overall system I/O load. Load
balancing the system disks in this manner can greatly improve system performance in some
situations. VxVM and LVM include striping functionality by default.
Mirroring (RAID 1) Supported?

With an appropriate license, both LVM and VxVM support data "mirroring". Data written to a
mirrored partition is physically written to two or more physical disks. Thus, even if a single
disk fails, your applications can still access their data via the second mirror. LVMv1.0
supports three-way mirroring. LVMv2.x supports six-way mirroring. VxVM supports up to 32
mirrors per volume.

Module 7
Mirrored Stripes (RAID 0/1) Supported?

Disk mirroring provides improved reliability, while disk striping provides improved
performance. With an appropriate license, LVM and VxVM both make it possible to mirror
and stripe a partition simultaneously.
RAID 5 Supported?
The mirrored/striped partitions described above deliver both stability and performance.
However, mirrored/striped partitions are also expensive to implement, since every megabyte
of data requires two or more megabytes of disk space: one for each mirror. RAID 5 is a
sophisticated technology that provides the same stability that one would expect from a
mirrored partition, while simultaneously providing some of the same read performance
benefits that one would expect from a striped partition.
RAID 5 functionality is available via an add-on license for VxVM. RAID 5 functionality is not
available in LVM.
Dynamic Relayout Support?

The last few sections on this slide noted that VxVM supports striped, mirrored,
mirrored/striped, and RAID 5 partitions. VxVM also makes it possible to dynamically convert
a partition from one format to another. For instance, a RAID 5 partition may be converted to
a mirrored partition. Striping parameters may be changed while users are accessing mounted
file systems! This functionality is not supported in LVM.
Dynamic Multipathing Support?

Most disk arrays can be accessed via two or more paths through a SAN. If one path fails,
LVM and VxVM dynamically switch to an alternate path to avoid downtime and data loss.
With an additional “Active/Active DMP license, VxVM can even utilize both paths
simultaneously to improve performance.
Though LVM doesn’t provide active/active dynamic multipathing, the new mass storage stack
in 11i v3 provides equivalent functionality.
Add-on Functionality
The features in the table above that are preceded by an asterisk (*) require a special license.
LVM mirroring functionality is included in the HP-UX 11i v1 & 11i v2 Enterprise and Mission
Critical Operating Environment software bundles, and in the HP-UX 11i v3 High Availability,
VSE, and Data Center Operating Environments. Other customers must purchase a license for
MirrorDisk/UX. Use the swlist command to determine if the mirroring license is
configured on your system.
# swlist –l fileset –a state LVM.LVM-MIRROR-RUN 11i v1 and v2

# swlist -l fileset –a state LVM-MirrorDisk.LVM-MIRROR 11i v3
All HP-UX Operating Environments include the Base-VxVM product, which makes it possible
to configure simple VxVM volumes and disk groups, and mirror the boot disk. In order to use
other VxVM high availability features, though, you must install one of the Veritas B9116*
bundles, or one of the T277[1-7]* Serviceguard Storage Management Suite bundles. To

Module 7
determine if you have access to the VxVM online features, type the following:
# swlist B9116* T277[1-7]*
For More Information

For more information on the advanced features of LVM and VxVM that are described above,
consider enrolling in HP Education's Hands-on with LVM and VxVM courses, H6285S and
HB505S. Several manuals for both volume managers are available on the
http://docs.hp.com website.

Module 7
7–19. LAB: Configuring Disk Devices
Directions
In this exercise you will have an opportunity to create physical volumes, volume groups, and
logical volumes in LVM disk layout 1 (LVMv1). Your system should have at least one unused
spare disk. Your instructor will tell you which spare disk to use. Record the disk DSF name
below. If you consult the solutions, note that diska should be replaced with your spare
disk’s DSF name.
diska = ____________________
Except where noted, do all of the exercises from the command line.
Part 1: Choosing a Disk for Use in a Volume Group

1. How many disks do you have on your system? Determine each disk's agile view
hardware path and DSF names.
2. Use lvmadm -l to determine which of the disks on your system are already members of
active volume groups. Verify that the spare disk suggested by your instructor is not
already listed in /etc/lvmtab and /etc/lvmtab_p.
3. Before adding a disk to a volume group, you may want to check the size of the disk. This
is accomplished via the diskinfo command. How large is your spare disk?
# diskinfo /dev/rdisk/diska

Module 7
Part 2: Creating a Physical Volume, Volume Group, and Logical

Volumes
1. Which LVM volume group versions are supported on your lab system? Execute lvmadm
-t to find out.
2. Configure your free disk as an LVM physical volume.
3. Can you pvdisplay your disk at this point? Try it.
4. Create a new LVMv1.0 vg01 volume group using your newly created physical volume.
You will have an opportunity to configure an LVMv2.x volume group later in the lab.
5. Use vgdisplay and pvdisplay to check the status of your new physical volume and
volume group. How many physical volumes are in the volume group at this point? How
many logical volumes are in the volume group at this point? What is the extent size?
6. Create two 24-MB logical volumes in your new volume group. Name the first logical
volume cadvol and the second camvol.

Module 7
7. Use vgdisplay and lvdisplay to ensure that your new logical volumes were actually
created.
8. Do an ll of the /dev/vg01 directory. What is the name of the volume group DSF for
your new volume group? Each of your logical volumes should have two DSFs. Why?
9. Remove the vg01 volume group. For now, use the shortcut cookbook described below.
A later chapter in the course describes the process required to remove volume group
more formally.
# vgchange –a n vg01
# vgexport vg01
10. Execute vgdisplay vg01. This should report that the volume group no longer exists.
If the volume group does exist, return to the previous step.

Module 7
Part 3: (Optional) LVM "What-Ifs"

1. Re-pvcreate the spare disk you used in the previous part of the lab. If you get an error
message, there may be old LVM headers remaining on the disk from a previous class.
Add the –f (force) option to overwrite the old headers. Be sure you’re using the right
disk, though, as pvcreate’ing an Integrity boot disk with the –f option can render a
system unbootable!
2. For the sake of variety, create a new LVMv2.0 volume group called vg02 using the spare
disk you just pvcreated. Specify a 4MB extent size and ensure that volume group can
accommodate up to 1TB of disk space.
3. Now that you have a volume group, try creating a few logical volumes. Create a logical
volume called test1vol in vg02. This time, though, don't specify a size for your logical
volume. Based on the result of this experiment, what is the default logical volume size?
# lvcreate -n test1vol vg02

# vgdisplay -v vg02
4. What happens if you don't specify a logical volume name when you lvcreate? Try it.
Create two new logical volumes of size 12 MB and 16 MB, leaving off the -n option in
both cases. What names did LVM assign to your new logical volumes? Why?

Module 7
5. See what happens if you attempt to create an 11 MB logical volume in vg02 called
test2vol. Watch the output from lvcreate carefully. What size is your new logical
volume? Explain.
6. At some point in your UNIX career, you will almost certainly accidentally execute
lvcreate -l instead of lvcreate -L. What appears to be the difference between
these two options? Try it and find out.
# lvcreate -l 12 -n test3vol vg02

# lvcreate -L 12 -n test4vol vg02
# vgdisplay -v vg02 | more
more formally.
# vgexport vg02

Module 7
Part 4: (Optional) Exploring VxVM

This optional portion of the lab gives you an opportunity to explore some of the basic VxVM
functionality.
1. This portion of the lab requires X-windows. Ask your instructor how to launch X-
windows on your lab system. Verify that a DISPLAY variable exists. If so, X-windows
launched properly.
# echo $DISPLAY
2. VxVM refuses to manage disks that contain LVM header information. Use the dd
command to remove any remnants of the LVM headers from your spare disk.
# dd if=/dev/zero of=/dev/rdisk/diska bs=1024 count=1024
3. Verify that VxVM is installed on your system. The VxVM 4.1 product name is Base-
VXVM. The VxVM 5.0 product name is Base-VxVM-50. Exactly one of the two products
should be installed.
# swlist Base-VxVM-50 Base-VXVM
4. Run the vxinstall program to startup the VXVM daemons. You only need to run this
utility once, when you first install VxVM.
# vxinstall
• Don’t enter any license keys. The license required to create mirrored and RAID5
volumes should already be installed..
• Don’t use enclosure-based names; we’ll discuss enclosure-based names later in the
course.
• Don’t select a default disk group.
Answer:
# vxinstall
VxVM uses license keys to control access. If you have not yet
installed a VxVM license key on your system, you will need to do
so if you want to use the full functionality of the product.
Licensing information:
System host ID: 4289413582
Host type: ia64 hp server rx2600
Are you prepared to enter a license key [y,n,q] (default: n) n

Do you want to use enclosure based names for all disks? [y,n,q,?]
(default: n) n
Populating VxVM DMP device directories ....

V-5-1-0 vxvm:vxconfigd: NOTICE: Generating /etc/vx/array.info
The Volume Daemon has been enabled for transactions.

Module 7
Starting the relocation daemon, vxrelocd.

Starting the cache deamon, vxcached.
Starting the diskgroup config backup deamon, vxconfigbackupd.
Do you want to setup a system wide default disk group? [y,n,q,?]

(default: y) n
5. VxVM can be managed from the command line, or via the "Veritas Enterprise
Administrator" (vea) GUI-based management tool. In this lab, we will use vea. Launch
the VEA client GUI.
# /opt/VRTSob/bin/vea
6. If VEA offers to create a profile for you, click OK to accept.
7. Click File->Connect.
8. Enter your lab system’s fully qualified hostname, then click [Connect] to connect.
9. Login using your root username and password. Click [OK].
10. When the VEA interface appears, click the magnifying glass icon to the left of your
hostname in the system object list on the left.
11. Click the magnifying glass to the left of “StorageAgent”.
12. Click Actions->Rescan to ensure that VEA is displaying the most current information.
13. Click Disk Groups in the object list on the left. If you have any disk groups, they
should appear in the object detail list on the right. You should not have any disk groups
currently.

Module 7
Creating a New Disk Group
14. Click Disk Groups in the object browser on the left. VxVM disk groups are similar to
LVM volume groups. If you had any disk groups, they would appear in the detail pane on
the right. There shouldn’t be any disk groups currently.
15. Click Actions->New Disk Group... to create a new disk group.
16. In the New Disk Group Wizard dialog box ...
a. Click Next> to proceed past the instruction screen.
b. Enter datadg in the Group name field.
c. In the Available Disks list, select your spare disk. Note that VxVM uses legacy
device file names rather than persistent device file names by default..
d. In the Disk Names text box, enter datadg01. VxVM will use datadg01 as a
hardware path independent name for the disk.
e. Click the Add> button.
f. Click the Next button.
g. Confirm that you wish to add the disk to the disk group.
h. Click Finish to confirm that you wish to create the disk group.
17. Back in the VEA main window, click Disk Groups in the object list on the left to verify
that your disk group was successfully created.
Create a New Volume
18. Back in the VEA main window, select the new datadg disk group.
19. Click Actions->New Volume... to create the new volume. VxVM volumes are similar
to LVM logical volumes.
20. Click Next.
21. Select disk group datadg.
22. Click Next.
23. In the Choose the method by which to select Disks for this Volume
dialog box, click Let Volume Manager decide which disks to use. Click
Next>.
24. In the New Volume Wizard dialog box:

Module 7
a. Enter datavol as the Volume Name.
b. Enter 32MB as the volume size.
c. Click Next.
25. When asked to select attributes for the new volume, accept all of the defaults and click
Next.
26. In the Create file system dialog box, select No File System, then click Next.
27. Click Finish to finish creating your volume.
28. Back in the VEA main window, click Volumes in the object list on the left to verify that
your volume was successfully created.
Destroying a disk group
29. Back in the VEA main window, click Disk Groups in the object list.
30. Select your datadg disk group.
31. Click Actions->Destroy Disk Group... to destroy the disk group.
32. Confirm that you wish to destroy the disk group.
Exiting VEA
33. Click File->Exit to exit VEA.
34. LVM refuses to overwrite VxVM headers. Use the dd command to clobber any VxVM
headers remaining on the disk.
NOTE: This lab only demonstrated VxVM's basic functionality. For more
information on VxVM, attend HP's Veritas Volume Manger training
courses, HB505S, or read the Veritas Volume Manager documentation
on http://docs.hp.com.

Module 7
Part 5: (Optional) Exploring the SMH

If time permits, explore the Disks and File Systems functional area in the SMH. If you
create any new file systems or logical volumes in the SMH, remove them before proceeding.
# smh -> Disks and File Systems or

# fsweb
A similar Disks and File Systems functional area exists in sam in earlier versions of
HP-UX.

Module 7
Part 6: Creating One Last Volume Group

1. In preparation for the discussion of file systems and swap in the following chapters,
create an LVMv2.2 volume group called vg01 with your spare disk. Specify maximum
volume group size 1TB with a 4MB extent size. Create two 32MB logical volumes in vg01
called datavol and swapvol.

Module 7
7–20. LAB SOLUTIONS: Configuring Disk Devices
Directions
In this exercise you will have an opportunity to create physical volumes, volume groups, and
logical volumes. Your system should have at least one unused spare disk. Your instructor
will tell you which spare disk to use. Record the disk DSF name below. If you consult the
solutions, note that diska should be replaced with your spare disk’s DSF name.
diska = ____________________
Except where noted, do all of the exercises from the command line.
Part 1: Choosing a Disk for Use in a Volume Group

1. How many disks do you have on your system? Determine each disk's agile view
hardware path and DSF names.
Answer:
# ioscan -kfnNC disk
2. Use lvmadm -l to determine which of the disks on your system are already members of
active volume groups. Verify that the spare disk suggested by your instructor is not
already listed in /etc/lvmtab and /etc/lvmtab_p.
Answer:
# lvmadm -l
The disk suggested by your instructor should not appear in the output.
3. Before adding a disk to a volume group, you may want to check the size of the disk. This
is accomplished via the diskinfo command. How large is your spare disk?
Answer:
The disk size will vary.

Module 7
Part 2: Creating a Physical Volume, Volume Group, and Logical

Volumes
1. Which LVM volume group versions are supported on your lab system? Execute lvmadm
-t to find out.
Answer:
# lvmadm -t
2. Configure your free disk as an LVM physical volume.
Answer:
The solutions reference /dev/[r]disk/diska. Your spare disk name may be

different.
# pvcreate /dev/rdisk/diska
3. Can you pvdisplay your disk at this point? Try it.
Answer:
# pvdisplay /dev/disk/diska
Fails. You can't pvdisplay a disk until it is a member of a volume group.
4. Create a new LVMv1.0 vg01 volume group using your newly created physical volume.
You will have an opportunity to configure an LVMv2.x volume group later in the lab.
Answer:
# mkdir /dev/vg01
# vgcreate vg01 /dev/disk/diska
5. Use vgdisplay and pvdisplay to check the status of your new physical volume and
volume group. How many physical volumes are in the volume group at this point? How
many logical volumes are in the volume group at this point? What is the extent size?
Answer:

Currently there should be just one PV in the volume group, and no LVs. The PE size
should be 4 MB (the default).
6. Create two 24-MB logical volumes in your new volume group. Name the first logical
volume cadvol and the second camvol.

Module 7
Answer:
# lvcreate -L 24 -n cadvol vg01

# lvcreate -L 24 -n camvol vg01
7. Use vgdisplay and lvdisplay to ensure that your new logical volumes were actually
created.
Answer:
# vgdisplay -v | more
# lvdisplay -v /dev/vg01/cadvol
# lvdisplay -v /dev/vg01/camvol
8. Do an ll of the /dev/vg01 directory. What is the name of the volume group DSF for
your new volume group? Each of your logical volumes should have two DSFs. Why?
Answer:
# ll /dev/vg01
The volume group DSF should be called /dev/vg01/group. Each logical volume
requires both a raw and a block DSF. Some commands used to access logical volumes
require a block DSF, while others require a character DSF. Both DSF types are required
for every DSF.
more formally.
# vgexport vg01
10. Execute vgdisplay vg01. This should report that the volume group no longer exists.
If the volume group does exist, return to the previous step.
Answer:
# vgdisplay -v vg01

Module 7
Part 3: (Optional) LVM "What-Ifs"

1. Re-pvcreate the spare disk you used in the previous part of the lab. If you get an error
message, there may be old LVM headers remaining on the disk from a previous class.
Add the –f (force) option to overwrite the old headers. Be sure you’re using the right
disk, though, as pvcreate’ing an Integrity boot disk with the –f option can render a
system unbootable!
Answer:
# pvcreate -f /dev/rdisk/diska
2. For the sake of variety, create a new LVMv2.0 volume group called vg02 using the spare
disk you just pvcreated. Specify a 4MB extent size and ensure that volume group can
accommodate up to 1TB of disk space.
Answer:
# vgcreate –V 2.0 –S 1t –s 4 vg02 /dev/disk/diska
# vgdisplay -v vg02
3. Now that you have a volume group, try creating a few logical volumes. Create a logical
volume called test1vol in vg02. This time, though, don't specify a size for your logical
volume. Based on the result of this experiment, what is the default logical volume size?
# lvcreate -n test1vol vg02

# vgdisplay -v vg02
Answer:
The new logical volume is created with size 0 MB. The default logical volume size
appears to be 0 MB. This is the expected behavior in all current volume group versions.
4. What happens if you don't specify a logical volume name when you lvcreate? Try it.
Create two new logical volumes of size 12 MB and 16 MB, leaving off the -n option in
both cases. What names did LVM assign to your new logical volumes? Why?
Answer:
# lvcreate -L 12 vg02
# lvcreate -L 16 vg02
# vgdisplay -v vg02
By default, LVM uses the following naming convention for new logical volumes: lvol1,
lvol2, lvol3,... This is the expected behavior in all current volume group
versions.
In this case, since these were the second and third logical volumes in vg02, LVM named
them lvol2 and lvol3. The number after lvol should match the last couple of digits
of the logical volume DSF's minor number.

Module 7
5. See what happens if you attempt to create an 11 MB logical volume in vg02 called
test2vol. Watch the output from lvcreate carefully. What size is your new logical
volume? Explain.
Answer:
# vgdisplay -v vg02
If you choose a size that is not a multiple of the extent size, LVM rounds up to the nearest
extent boundary.
6. At some point in your UNIX career, you will almost certainly accidentally execute
lvcreate -l instead of lvcreate -L. What appears to be the difference between
these two options? Try it and find out.
# lvcreate -l 12 -n test3vol vg02

Answer:
The -L option defines a logical volume's size in megabytes, while the –l option defines a
logical volume's size in extents. Thus, using lvcreate –l 12 results in a much larger
logical volume than lvcreate –l 12. This is the expected behavior in all current
volume group versions.
more formally.
# vgexport vg02

Module 7
Part 4: (Optional) Exploring VxVM

This optional portion of the lab gives you an opportunity to explore some of the basic VxVM
functionality.
1. This portion of the lab requires X-windows. Ask your instructor how to launch X-
windows on your lab system. Verify that a DISPLAY variable exists. If so, X-windows
launched properly.
# echo $DISPLAY
2. VxVM refuses to manage disks that contain LVM header information. Use the dd
command to remove any remnants of the LVM headers from your spare disk.
3. Verify that VxVM is installed on your system. The VxVM 4.1 product name is Base-
VXVM. The VxVM 5.0 product name is Base-VxVM-50. Exactly one of the two products
should be installed.
# swlist Base-VxVM-50 Base-VXVM
4. Run the vxinstall program to startup the VXVM daemons. You only need to run this
utility once, when you first install VxVM.
# vxinstall
• Don’t enter any license keys. The license required to create mirrored and RAID5
volumes should already be installed..
• Don’t use enclosure-based names; we’ll discuss enclosure-based names later in the
course.
• Don’t select a default disk group.
Answer:
# vxinstall
VxVM uses license keys to control access. If you have not yet
installed a VxVM license key on your system, you will need to do
so if you want to use the full functionality of the product.
Licensing information:
System host ID: 4289413582
Host type: ia64 hp server rx2600
Are you prepared to enter a license key [y,n,q] (default: n) n

Do you want to use enclosure based names for all disks? [y,n,q,?]
(default: n) n
Populating VxVM DMP device directories ....

V-5-1-0 vxvm:vxconfigd: NOTICE: Generating /etc/vx/array.info
The Volume Daemon has been enabled for transactions.

Module 7
Starting the relocation daemon, vxrelocd.

Starting the cache deamon, vxcached.
Starting the diskgroup config backup deamon, vxconfigbackupd.
Do you want to setup a system wide default disk group? [y,n,q,?]

(default: y) n
5. VxVM can be managed from the command line, or via the "Veritas Enterprise
Administrator" (vea) GUI-based management tool. In this lab, we will use vea. Launch
the VEA client GUI.
# /opt/VRTSob/bin/vea
6. If VEA offers to create a profile for you, click OK to accept.
7. Click File->Connect.
8. Enter your lab system’s fully qualified hostname, then click [Connect] to connect.
9. Login using your root username and password. Click [OK].
10. When the VEA interface appears, click the magnifying glass icon to the left of your
hostname in the system object list on the left.
11. Click the magnifying glass to the left of “StorageAgent”.
12. Click Actions->Rescan to ensure that VEA is displaying the most current information.
13. Click Disk Groups in the object list on the left. If you have any disk groups, they
should appear in the object detail list on the right. You should not have any disk groups
currently.

Module 7
Creating a New Disk Group
14. Click Disk Groups in the object browser on the left. VxVM disk groups are similar to
LVM volume groups. If you had any disk groups, they would appear in the detail pane on
the right. There shouldn’t be any disk groups currently.
15. Click Actions->New Disk Group... to create a new disk group.
16. In the New Disk Group Wizard dialog box ...
a. Click Next> to proceed past the instruction screen.
b. Enter datadg in the Group name field.
c. In the Available Disks list, select your spare disk. Note that VxVM uses legacy
device file names rather than persistent device file names by default..
d. In the Disk Names text box, enter datadg01. VxVM will use datadg01 as a
hardware path independent name for the disk.
e. Click the Add> button.
f. Click the Next button.
g. Confirm that you wish to add the disk to the disk group.
h. Click Finish to confirm that you wish to create the disk group.
17. Back in the VEA main window, click Disk Groups in the object list on the left to verify
that your disk group was successfully created.
Create a New Volume
18. Back in the VEA main window, select the new datadg disk group.
19. Click Actions->New Volume... to create the new volume. VxVM volumes are similar
to LVM logical volumes.
20. Click Next.
21. Select disk group datadg.
22. Click Next.
23. In the Choose the method by which to select Disks for this Volume
dialog box, click Let Volume Manager decide which disks to use. Click
Next>.
24. In the New Volume Wizard dialog box:

Module 7
a. Enter datavol as the Volume Name.
b. Enter 32MB as the volume size.
c. Click Next.
25. When asked to select attributes for the new volume, accept all of the defaults and click
Next.
26. In the Create file system dialog box, select No File System, then click Next.
27. Click Finish to finish creating your volume.
28. Back in the VEA main window, click Volumes in the object list on the left to verify that
your volume was successfully created.
Destroying a disk group
29. Back in the VEA main window, click Disk Groups in the object list.
30. Select your datadg disk group.
31. Click Actions->Destroy Disk Group... to destroy the disk group.
32. Confirm that you wish to destroy the disk group.
Exiting VEA
33. Click File->Exit to exit VEA.
34. LVM refuses to overwrite VxVM headers. Use the dd command to clobber any VxVM
headers remaining on the disk.
NOTE: This lab only demonstrated VxVM's basic functionality. For more
information on VxVM, attend HP's Veritas Volume Manger training
courses, HB505S, or take a look at the Veritas Volume Manager
documentation on http://docs.hp.com.

Module 7


# fsweb
HP-UX.

Module 7
Part 6: Creating One Last Volume Group

1. In preparation for the discussion of file systems and swap in the following chapters,
create an LVMv2.2 volume group called vg01 with your spare disk. Specify maximum
volume group size 1TB with a 4MB extent size. Create two 32MB logical volumes in vg01
called datavol and swapvol.
Answer:

Module 7

Module 8 ⎯ Managing File Systems
Objectives
List the file system types available in HP-UX.
Describe the difference between user data and metadata.
Describe the structure of a JFS file system.
Define the terms: superblock, inode, directory, directory entry, block, and extent.
Compare and configure hard and soft links.
Create file systems with newfs.
Manually mount VxFS, CDFS, ISO, and MemFS file systems via mount.
Unmount file systems via umount.
Automatically mount file systems via /etc/fstab.

Module 8
8–1. SLIDE: File System Overview
File System Overview
• A UNIX file system is a collection of files and directories managed together as a unit
• Each file system resides in a logical volume, or a whole disk partition
• Systems often have multiple file systems, each containing a portion of the system’s files
• Mounting a file system makes the file system accessible to users
• Mount point directories enable users to transparently navigate between file systems
/dev/vg00/lvol3 file system
home etc dev data
user1 user2 user3 file1 file2 file3
/dev/vg00/lvol4 file system /dev/vg01/datavol file system
Student Notes
A UNIX file system is a collection of files and directories stored and managed together as a
unit. Each file system resides in a separate logical volume or whole disk partition. HP-UX
systems usually have multiple file systems.
• Operating system files under /usr are usually stored in one file system.
• Variable length log and spool files under /var are usually stored in another file system.
• Temporary files under /tmp are usually stored in another file system.
• User home directories under /home are usually stored in another file system.
• Data files under /data may be stored in yet another file system.
The / (root) file system is a special file system that includes the /etc, /dev, /sbin, and
other directories containing files used very early in the system boot process.

Module 8
Why Configure Multiple File Systems?

Although all of the files and directories on a system could be stored in the root file system,
separating subtrees of the file hierarchy into several distinct file systems offers several
advantages:
The administrator can allocate a fixed amount of disk space to each file system to ensure that
no single file system is allowed to monopolize an entire disk. The administrator might, for
instance, allocate 1GB to the /tmp file system. This ensures that temporary files under /tmp
can use at most 1GB of disk space.
Each file system may be tuned independently. There are a number of parameters associated
with each file system that can significantly affect system performance. It may be beneficial
to optimize some file systems for storage of large files, while others are optimized for storage
of smaller files.
File system maintenance tasks may be performed on one file system, while other file systems
remain accessible to your users.
Mounting File Systems
Mounting a file system makes the file system accessible to users by logically associating the
file system with a directory in the system’s file hierarchy. The directory upon which a file
system is mounted is known as the file system’s mount point directory. Mount points enable
users to easily navigate from file system to file system with no knowledge of the underlying
partitions.
The directory structure on the slide includes files residing in three different file systems.
The files residing in /etc and /dev reside in the “root” file system stored in
/dev/vg00/lvol3. HP-UX mounts the root file system on the / directory very early in the
system startup process.
The file system contained in /dev/vg00/lvol4, which contains user home directories, is
mounted on the /home mount point.
The file system contained in /dev/vg01/datavol, which contains application data files, is
mounted on the /data mount point.
These are just a few examples; systems typically have many more mounted file systems.
The administrator can also unmount a file system, rendering the file system temporarily
inaccessible to users. Some administrative tasks described later in the course can only be
performed on unmounted file systems
Viewing the Mounted File Systems

Two commands allow you to view a list of your currently mounted file systems:
# mount -v reports which file systems are mounted where
# bdf also reports file system sizes, and other info

Module 8
8–2. SLIDE: File System Types
File System Types

• HP-UX supports multiple file system types, each offering unique features & benefits
• HP-UX commands behave the same regardless of the underlying file system type
– HFS High Performance File System

– JFS/VxFS Journaled File System / Veritas File System
– CFS Cluster File System
– CDFS CD-ROM File System
– LOFS Loopback File System
– NFS Network File System
– CacheFS NFS Cache File system
– CIFS Common Internet File System
– MemFS Memory-based File System
Student Notes
HP-UX supports several different file system types. The notes below briefly describe some of
the features of the most common file system types.
High-Performance File System (HFS)

HFS is HP's implementation of the UNIX File System (UFS). HFS file systems reside on mass
storage devices, usually hard disk drives. Prior to HP-UX Release 10.01 this was HP's only
disk-based file system. HFS is rarely used in 11i v1, v2, and v3 and may be removed from a
future release.
Journaled / Veritas File System (JFS/VxFS)

The HP-UX Journaled File System (JFS), also known as the Veritas File System (VxFS), is an
extent-based journaling file system which offers fast file system recovery and on-line features
such as on-line backup, on-line resizing and on-line reorganization. An intent log logs
pending file system data structure updates. After an improper system shutdown, the fsck
(file system check) utility uses the intent log to either complete or rollback pending updates,
and maintain file system integrity.

Module 8
There are two JFS products. The BaseJFS file product provides fast recovery feature and is
included in all current HP-UX releases. OnlineJFS offers these additional capabilities:
• online defragmentation and reorganization
• online expansion and contraction of file system size
• online backup
Notes later in this chapter describe the steps required to configure JFS file systems.
Cluster File Systems (CFS)

CFS enables multiple nodes in a high availability cluster to simultaneously mount a file
system. CFS requires an additional license and should only be used in high availability
clusters. HP Education’s HP Serviceguard 2 course (U8601S) discusses CFS in detail.
CD-ROM File Systems (CDFS)

CDFS is used to mount CD-ROMs and DVDs. Files and directories on CD-ROMs and DVDs
are read-only. CD-ROMs come in a variety of formats. Notes later in this chapter describe
the steps required to mount CDFS file systems.
Loopback File Systems (LOFS)

HP’s loopback file system makes it possible for a directory hierarchy to appear under
multiple local mount points.
Network File Systems (NFS)

NFS makes it possible for an NFS server to share directories with remote NFS clients. NFS
clients mount the server’s file systems, providing the client users transparent access to the
server’s files.
HP Education’s System and Network Administration 2 course (H3065S) discusses NFS in

detail.
CacheFS
CacheFS performs local disk caching of NFS file systems on NFS clients, reducing network
traffic, and potentially improving NFS client and server performance. CacheFS only
improves NFS read performance; it does not affect NFS write performance.
The first time data is read from an NFS-mounted file system, there is some overhead while
CacheFS writes NFS file system data to its local cache. After the data is written to the cache,
read performance for the file system is significantly improved. CacheFS regularly polls the
server to maintain consistency with the server.
To learn more about CacheFS, read the CacheFS chapter in the NFS Services
Administrator’s Guide on http://docs.hp.com.
Common Internet File System (CIFS)

HP’s CIFS product provides a full implementation of Microsoft's "Common Internet File
System" protocol, which is used by Windows 95, Windows 98, Windows 2000, and NT for
sharing network file and printer resources. Using HP CIFS, HP-UX and Microsoft Windows
systems can seamlessly and transparently share resources.

Module 8
HP CIFS includes several components:

The server portion of HP CIFS is based on Samba, an open source CIFS server solution that
has been ported to many UNIX platforms. File systems made available from an HP-UX server
via Samba can be mounted on Windows clients as standard drive letters and can be accessed
via the Windows "Network Neighborhood" and "Windows Explorer" like standard Microsoft
file shares. In fact, your HP-UX Samba server can even be a Primary Domain Controller and
print server for Microsoft clients!
HP includes CIFS client software in the HP CIFS product. This software makes it possible to
mount file shares from any Samba or Microsoft server on an HP-UX client using the
/etc/fstab file and the standard UNIX mount command. File systems mounted via the
CIFS client software may be accessed using all the standard UNIX utilities and system calls.
Finally, the HP CIFS product includes a Pluggable Authentication Module (PAM) library to
allow users to log onto their HP-UX systems using their Windows domain usernames and
passwords.
HP CIFS is included in the HP-UX Operating Environments.
For more information on Samba and CIFS, read HP's CIFS documentation on
http://docs.hp.com, or purchase O'Reilly and Associates, Using Samba (ISBN 1-56592-
449-5).
Memory-based File System (MemFS)

Writing data to and from a physical disk is a resource intensive operation; accessing data in
memory is typically much faster.
The HP-UX “memory-based file system” product (MemFS) enables you to store directories
and files in memory rather than on disk. Users can access files and directories in a MemFS
file system as they would files and directories in an HFS or JFS file system, though the
internal implementation is quite different from disk-based file systems.
MemFS typically provides extremely high throughput. However, since MemFS files are
stored in memory rather than on disk, MemFS files and directories never persist across
reboots. Thus, MemFS is most appropriate for application file systems containing temporary
files.
MemFS was first introduced in 11i v2 and is now supported in 11iv3, too.
To learn more about MemFS, see the Memory File System (MemFS) 2.0 for HP-UX 11i v3
Administrator's Guide on http://docs.hp.com.
Mixing and Matching File Systems

All of the file systems on a system may be the same file system type, but more typically, a
machine's file system hierarchy is comprised of several different file system types.
Fortunately, the same application system calls and file system navigation commands such as
cd, cp, and mv work across all file system types.

Module 8
Viewing File system Types

Use the following commands to determine a file system’s file system type:
# mount –v what types of file systems are currently mounted?
# fstyp /dev/vg00/rlvol1 what type of file system is contained in /dev/vg00/lvol1?

Module 8
8–3. SLIDE: Part 1: File System Concepts
Managing File
Systems
Part 1: File System Concepts
Student Notes
Disk space allocated to a file system, regardless of the file system type, is subdivided into file
system blocks. The blocks in a file system may be used for two different purposes.
Some of the blocks in a file system store the actual data contained in user, application, and
OS files. These data blocks account for the majority of the blocks in most file systems.
Some of the blocks in every file system store the file system's metadata. A file system's
metadata describes the structure of the file system. A conceptual understanding of these
structures will contribute greatly to your success as a system administrator.
The next few slides describe some of the metadata structures that are common to most file
system types.

Module 8
8–4. SLIDE: Superblock Concepts
Superblock Concepts
• Every file system has a superblock containing file system structural information
• Use fstyp –v to view selected superblock fields
# fstyp -v /dev/vg01/rdatavol
file system type vxfs
version: 6
f_bsize: 8192
f_frsize: 1024
f_blocks: 32768
f_bfree: 31139
f_bavail: 29193
f_files: 7816
f_ffree: 7784
file system size f_size: 32768
(continues)
Student Notes
Superblock Concepts
Every file system has a structure called a superblock that contains general information
about the file system. The superblock identifies the file system type, size, status, and
attributes, and contains pointers to all of the other file system metadata structures. Since the
superblock contains such critical information, most file systems maintain multiple redundant
copies of the superblock.
The fstyp command displays portions of a file system’s superblock. The slide highlights a
couple fields of particular interest. See the statvfs(2) man page to view brief descriptions
of several other fields reported by fstyp.
vxfs Å file system type
version: 6
f_bsize: 8192
f_frsize: 1024

Module 8
f_blocks: 16384
f_bfree: 14755
f_bavail: 13833
f_files: 3720
f_ffree: 3688
f_favail: 3688
f_fsid: 1073741834
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 16
f_fsindex: 9
f_size: 16384 Å file system size

Module 8
8–5. SLIDE: Inode Concepts
Inode Concepts
• Every file system has an inode table containing an inode for each file & subdirectory
• A file’s inode records the file’s file permissions, owner, group, and other attributes
• Use ll –i to view inode numbers and attributes
# ll -i /data
3 drwxr-xr-x 2 root root 96 Jul 5 16:34 lost+found
101 -rw-rw-rw- 1 root sys 125 Jul 7 10:04 file1
inode# file attributes stored in inodes
Student Notes
Every file system has a structure called an inode table, which contains an inode for each file
and subdirectory. A file’s inode identifies the file's type, permissions, owner, group, size, and
other attributes. A file's inode also contains pointers to the data blocks associated with the
file. Each inode is identified by a unique inode number within the file system.
When a user or application accesses a file, the kernel consults the file’s inode to determine if
the user is permitted to access the file. If so, kernel uses the pointers in the inode to locate
the file’s data blocks.
Viewing Inodes
The ll command displays file attributes from the inode table. When executed with the –i
option, ll also displays each file’s inode number.
# ll -i /data
3 drwxr-xr-x 2 root root 96 Jul 5 16:34 lost+found

Module 8

The bdf –i command reports the number of available, used, and free inodes in a file system.
JFS creates additional inodes as needed, so the number of available inodes may change as the
number of files in a file system increases.
# bdf -i /data
Filesystem kbytes used avail %used iused ifree %iuse Mounted
/dev/vg01/datavol 16384 1731 13743 11% 9 3663 0% /data

Module 8
8–6. SLIDE: Directory Concepts
Directory Concepts
• Directories may be used to organize groups of related files and subdirectories
• Each directory contains one or more directory entries
• Each directory entry associates a file name with an inode number
• Use ls -i to list the file names in a directory, and each file’s inode number
# ls -i /data
3 lost+found
101 file1
102 file2
103 file3
104 file4
105 file5
inode# file names
Student Notes
Directories may be used to organize groups of related files and subdirectories. Each
directory contains one or more directory entries. Each directory entry associates a file name
with an inode number.
Viewing Directories
Use ls to list the file and subdirectory names in a directory. Add the -i option to include
each file’s inode number, too
# ls -i /data
3 lost+found
101 file1
102 file2
103 file3
104 file4
105 file5

Module 8
8–7. SLIDE: Block and Extent Concepts
Block and Extent Concepts
• JFS subdivides a file system’s disk space into equal-size blocks

• A JFS extent is a variable-length sequence of adjacent blocks
• When allocating space for a file, JFS allocates extents, rather than individual blocks
• Extent-based allocation allows JFS to very efficiently service large I/O requests
JFS Block
JFS Extent allocated to a file
Student Notes
Disk space allocated to a file system is subdivided into file system blocks. When a user
writes to a file, HP-UX allocates one or more data blocks to store the file’s data. The
algorithm used to allocate and manage blocks to files varies by file system type. The notes
below are JFS-specific.
JFS Blocks
JFS subdivides a file system’s disk space into equal-size blocks. The block size determines
the smallest unit of disk space that can be allocated to a file.
The block size must be consistent within a file system, but may vary between file systems.
1KB, 2KB, 4KB, and 8KB are the currently supported block sizes. File systems with many
small files may benefit from a smaller block size. File systems with relatively few files may
benefit from a larger block size. Benchmark your application with several different block
sizes to determine the ideal configuration. The block size may be specified at file system
creation, but cannot be changed thereafter.

Module 8
The block size impacts the file system’s maximum file system size. File systems greater than
4TB require a larger block size. For example, in order to create a file system that is larger
than 16TB, JFS requires an 8KB block size. See the mkfs_vxfs(1M) man page for more
information.
JFS Extents
A JFS extent is a variable-length sequence of adjacent blocks. When allocating space for a
file, JFS allocates extents, rather than individual blocks. As a file grows, JFS tries to extend
the file’s last existing extent.
If JFS can’t extend the last existing extent, it uses another extent elsewhere in the file system.
Allocating one large contiguous extent to a file rather than multiple discontiguous blocks
allows JFS to very efficiently service large I/O requests.
Viewing the Block Size

The mkfs –F vxfs –m command reports an existing file system’s layout attributes,
including the file system’s block size.
# mkfs -F vxfs -m /dev/vg01/rdatavol

mkfs -F vxfs –o ninode=unlimited,bsize=1024,version=6,
inosize=256,logsize=1024,largefiles /dev/vg01/rdatavol 16384
There isn’t an easy way to view the number and size of an individual file’s blocks and extents,
but the fsadm –F vxfs –DE command does report the average number of extents per file,
and the size and distribution of a mounted file system’s free extents. A later chapter explains
how to use this command to “defragment” a file system.
# fsadm -F vxfs -E /data

Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
1 2 2 14653
blocks used for indirects: 0
% Free blocks in extents smaller than 64 blks: 0.42
% Free blocks in extents smaller than 8 blks: 0.03
% blks allocated to extents 64 blks or larger: 0.00
Free Extents By Size
1: 1 2: 0 4: 1
8: 1 16: 1 32: 1
64: 0 128: 2 256: 2
512: 1 1024: 1 2048: 0
4096: 1 8192: 1 16384: 0
32768: 0 65536: 0 131072: 0
262144: 0 524288: 0 1048576: 0
2097152: 0 4194304: 0 8388608: 0
16777216: 0 33554432: 0 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0

Module 8
8–8. SLIDE: Hard Link Concepts
Hard Link Concepts

• Hard links associate multiple directory entries with a shared inode and data
• Hard links cannot cross file system boundaries
• Hard links cannot link directories
Directory /data Inode Table Data Blocks
f1 101 101 -rwxr-xr-x

file1 101
# ln /data/file1 /data/f1
# ll -i
101 -rwxr-xr-x 2 root sys 1599 Jul 12 00:39 f1
101 -rwxr-xr-x 2 root sys 1599 Jul 12 00:39 file1
Student Notes
Although most inodes are associated with exactly one directory entry, hard links make it
possible to associate multiple directory entries with a single inode. Since the inode contains
pointers to a file’s blocks and extents, both hard links ultimately reference the same user
data, too. This, in effect, allows your users to reference a single file via several different file
names.
The example on the slide shows a file /data/f1 that is hard linked to /data/file1. Both
names reference the same inode, and thus share the same permissions, owner, time stamp,
and data.
Since both file names reference the same inode, they also both ultimately reference the same
data blocks. Changes made to f1 will be reflected in file1, and vice versa. f1 and file1
are essentially the same file! Oftentimes it is useful to associate multiple file names with a
single file in this manner.

Module 8
A hard link may be created with the ln command. The first argument identifies the file name
of the existing file, and the second identifies the name of the new link:
# ln /data/file1 /data/f1 Creates a hard link to f1

# ll /data Shows the number of links to each file
101 -rwxr-xr-x 2 root sys 1599 Jul 12 00:39 f1
Creating a hard link creates a new directory entry for the new link, and increments the link
count field in the inode. The second field in the output from the ll command shows the
number of links to each file.
Administrators sometimes use hard links to associate multiple file names with a single device
file. For instance, some 11i v1 and v2 administrators use hard links to provide more user-
friendly tape drive DSF names:
# ln /dev/rmt/c0t0d0BEST /dev/tape
After the administrator creates this link, users can access the c0t0d0 tape drive using the
intuitive name /dev/tape, rather than the cryptic default name /dev/rmt/c0t0d0BEST.
Be aware of two hard link limitations:
• Hard links cannot cross file system boundaries.
• Hard links cannot link directories.
Questions
1. Why isn't it possible to link across file system boundaries?
2. How would link /data/f1 be affected if you were to remove /data/file1?

Module 8
8–9. SLIDE: Symbolic Link Concepts
Symbolic Link Concepts

• Symbolic links associate multiple directory entries with a single file
• Symbolic links can cross file system boundaries
• Symbolic links can link both files and directories
Directory /data Inode Table Data Blocks
f2 112 112 link to /data/file2

file2 102 102 rwxr-xr-x
# ln -s /data/file2 /data/f2
# ll -i
112 lrwxrwxrwx 1 root sys 2 Jul 12 00:41 f2 -> file2
Student Notes
Symbolic links, like hard links, make it possible to associate multiple file names with a single
file. Unlike hard links, however, symbolic links can cross file system boundaries, and can be
used to link directories.
In the example on the slide, /data/f2 is a symbolic link to /data/file2. f2 and file2
have distinct directory entries and inodes. However, as shown on the slide, /data/f2 is
nothing more than a pointer to /data/file2! Accessing /data/f2 yields the same data
one would see when accessing /data/file2.
Symbolic links are particularly useful when you must move files from one file system to
another, but still wish to be able to use the file's original path name. In HP-UX version 9.x,
system executables were stored in the /bin directory. In HP-UX version 10.x, many
operating system executables were moved to /usr/bin. However, a symbolic link exists
from /bin to /usr/bin so users and applications can still use the version 9 path names.
This is just one situation where symbolic links are commonly used.

Module 8
Use the ln command with -s to create a symbolic link. The first argument identifies the
existing file that you wish to link to. Additional arguments specify the path names of the
symbolic links you wish to create to the existing file.
# ln -s /data/file2 /data/f2
112 lrwxrwxrwx 1 root sys 2 Jul 12 00:41 f2 -> file2
The ll command identifies symbolic links with an l in the first character position. Also, the
file name field in the ll output identifies the file to which a symbolic link leads.
NOTE: In the example above, removing /data/file2 will not automatically

remove the /data/f2 link! After removing /data/file2, accessing the
link will result in an error message.
# rm /data/file2
# cat /data/f2
cat: Cannot open /data/f2: No such file or directory
Question
1. Why is it possible to create symbolic links, but not hard links, across file system
boundaries?

Module 8
8–10. SLIDE: Intent Log Concepts
Intent Log Concepts

• JFS file systems use an intent log to track pending file system metadata updates
• Improper shutdowns interrupt updates and may result in metadata inconsistencies
• After an improper shutdown, fsck uses the intent log to restore metadata consistency
Example: Remove file f2 from a JFS file system
Superblock: Superblock: Superblock: Superblock:

Space in Use: 50MB Space in Use: 50MB Space in Use: 20MB Space in Use: 20MB
Intent Log: Intent Log: Intent Log: Intent Log:

update superblock update superblock ; update superblock
remove inode remove inode ; remove inode
deallocate extents deallocate extents ; remove extents
Inodes: Inodes: Inodes: Inodes:

#101 rwxr-xr-x f1 #101 rwxr-xr-x f1 #101 rwxr-xr-x f1 #101 rwxr-xr-x f1
#102 rwxr-xr-x f2 #102 rwxr-xr-x f2 #102 rwxr-xr-x f2
Extents: Extents: Extents: Extents:

f1 f1 f1 f1
f2 f2 f2
1.Before Update 2.Update Intent Log 3.Remove File 4.Update Complete!
Student Notes
JFS file systems use an intent log to track pending file system metadata updates.
Improper system shutdowns caused by power outages, system panics, or administrator error
may result in file system metadata inconsistencies. During the next system boot, HP-UX
automatically executes fsck (file system check) to repair these inconsistencies. Repairing
large HFS file systems after an improper shutdown may take several hours, and may not even
be possible in some cases. Repairing JFS file systems typically only takes a few seconds;
fsck simply consults the intent log and nullifies or completes the pending metadata updates.
The intent log only guarantees metadata integrity; applications must provide their own
logging mechanism to guarantee data integrity.
The intent log is a circular log. When JFS completes an update, it reuses that transaction’s
space in the intent log to service new transactions.
The intent log size is configurable and can be as large as 16MB in JFS file system layout 4,
and as large as 256MB in JFS file system layout 6. The default size varies based on the file
system size. A larger intent log may improve performance on NFS servers and other systems

Module 8
that manage metadata-intensive workloads. Choosing a smaller log size leaves more room in
the file system for files and directories. A smaller intent log also decreases the time required
to complete an fsck intent log replay after an improper shutdown. You can use the fsadm
command to resize the intent log.
Example: What Happens When a File is Removed from a JFS file system?
The graphic on the slide describes the process JFS uses to remove a file, and the impact this
process has on the JFS file system structures. After each step below, what impact would a
system crash have on the file system? Would the file system be left in a consistent state? If
not, what could be done conceptually to return the file system to a consistent state?
1. The diagram on the left depicts a JFS file system containing two files: f1 (20MB) and f2
(30MB).
2. When a user removes file f2, JFS starts by updating an in-core, memory-based copy of
the file system metadata to reflect the fact that the file has been removed. This step isn’t
shown on the slide.
After updating the in-core metadata, JFS records its intent to modify the metadata in the
on-disk "intent log". Then, if the update is interrupted by a system crash, JFS has a record
of pending file system metadata changes. This greatly simplifies recovery after a system
crash.
3. After writing the intent log transaction, JFS makes the required changes to the on-disk
meta-data. Removing f1 requires JFS to de-allocate f1's inode and data blocks, remove
the file’s directory entry, and update the free-space, space-in-use, and other fields in the
superblock.
4. As JFS completes changes to the file system metadata, it marks the appropriate intent log
entries "done". After an intent log entry is marked "done", JFS reuses that entry's space
for newly requested transactions.
Viewing the Intent Log

The fsdb file system debugger can be used to view the contents of the intent log, but the
procedure for doing so is complex. The administrator can easily view the size of the intent
log via mkfs.
# mkfs -F vxfs -m /dev/vg01/rdatavol

mkfs -F vxfs –o ninode=unlimited,bsize=1024,version=6,
inosize=256,logsize=1024,largefiles /dev/vg01/rdatavol 16384

Module 8
8–11. SLIDE: HFS / VxFS Comparison
HFS / VxFS Comparison
HFS JFS
Max Supported 128GB/128GB 2TB/2TB (11i v1 w/ JFS 3.5)
2TB/32TB (11i v2 w/ JFS 4.1)
File and File System Size (11i v1, v2, v3) 16TB/32TB (11i v3 w/ JFS 4.1)
16TB/40TB (11i v3 w/ JFS 5.0)
May be used for /stand? Yes Yes*

Access Control Lists Available? Yes Yes
File System Tuning Available? Yes Yes
Fast File System Recovery? No Yes
Online Resizing Available? No Yes**
Defrag Utility Available? No Yes**
Online Backup Available? No Yes**
* Only on Integrity servers

** Requires the OnlineJFS product
Student Notes
The second slide in the chapter noted that HP-UX supports two single-system, disk-based file
systems: HFS and JFS. The slide above summarizes the differences between the two file
system types.
Some JFS features in the table are followed by an asterisk (*). These features are only
available with the "Online" JFS product. See the section below titled "Upgrading Base JFS
Systems to Online JFS" for more information.
Note that HFS has been officially deprecated. Though it is still supported in 11i v3, HFS may
not be supported in future releases.
Max File / File System Size

HFS file systems now support a maximum file/file system size of 128 GB.
JFS maximum file and file system sizes vary by JFS version and OS release. The chart on the
slide shows the current maximum file and file system sizes at the time this book went to
press. See the latest release notes for more information.

Module 8
Note that the maximum supported logical volume size in 11i v1 and v2 is 2TB. 11i v2
customers who require larger file systems should consider using VxVM volumes rather than
LVM logical volumes, as VxVM supports much larger volumes.
See the Upgrading JFS File Systems section below to learn about JFS version upgrade
options.
Kernel Support
The HP-UX kernel loader on PARISC is unable to read JFS metadata structures. As a result,
the /stand file system must be HFS on PARISC systems. All other file systems may be, and
usually are, JFS.
The IPF kernel loader is able to read JFS metadata structures, so on Integrity servers the
/stand file system is JFS.
Access Control List Support

Standard UNIX permissions only allow three sets of permissions on each file. One set of
permissions determines what access rights are granted to the file's owner, one set of
permissions determines what access rights are granted to the members of the file's group,
and one set of permissions determines what access rights are granted to everyone else.
Access Control Lists make it possible to configure additional permissions for additional users
and groups! HFS has supported a proprietary version of Access Control Lists for many years
on HFS file systems (see the man pages for chacl(1) and lsacl(1)). HP's original JFS
release didn't support ACLs. JFS 3.3 introduced support for up to 13 ACLs per file. JFS 4.1
now supports up to 1024 ACLs per file in 11i v3. The HFS and JFS ACL implementations are
somewhat different. To learn about JFS ACLs, attend HP-UX Security 1 course, or take a
look at HP's HP JFS 3.3 Access Control Lists white paper on http://docs.hp.com.
File System Tuning

HFS supports a tunefs command that may be used to tune a variety of file system
parameters on a per-file-system basis. JFS supports a similar command, vxtunefs.
vxtunefs is discussed in HP Education’s Performance and Tuning (H4262S) class.
Fast File System Recovery

After a system crash, it can take minutes or even hours to repair an HFS file system's
metadata structures. If an HFS file system's metadata can't be repaired after a crash, it
sometimes becomes necessary to restore the entire file system from tape!
JFS metadata, on the other hand, can be repaired after a system crash in a matter of seconds
using the JFS intent log. In 24x7 environments the JFS fast crash recovery functionality is
invaluable.
Online Resizing
HFS file systems can't be extended while users are still accessing files in the file system; the
administrator must unmount the file system. HFS provides no mechanism for reducing a file
system online or offline.

Module 8
JFS makes it possible to extend, and even reduce, file systems that are still being accessed by
users. Note, however, that this feature is only available to users of the Online JFS product;
Base JFS users still must umount before their file systems can be extended.
Defrag Utility Available?

Over time, as users create, remove, and extend files, file systems tend to become
"fragmented" with blocks and fragments scattered across the entire logical volume or disk.
Eventually, fragmentation may cause serious performance problems.
The Online JFS product includes a defragmentation utility that rearranges file system blocks
to improve performance. No defragmentation utility is available for HFS.
Online Backup Available?

The Online JFS product includes a file system snapshot capability, which makes it possible to
back up a file system, even while files and directories are being modified.
Upgrading HFS File Systems to JFS

JFS versions 3.3 and greater make it possible to convert HFS file systems to JFS more
directly. The sample sequence of commands below convert the /data HFS file system JFS
(the procedure is described in detail in the vxfsconvert(1m) man page.
# bdf /data verify that the file system has at least 15% free before proceeding
# umount /data
# /sbin/fs/vxfs/vxfsconvert /dev/vg01/rdatavol
# fsck -F vxfs -y -o full /dev/vg01/rdatavol
# mount /dev/vg01/datavol /data
# vi /etc/fstab change the file system type to vxfs
Upgrading Base JFS Systems to Online JFS

Each version of JFS is available in two flavors. The base JFS product, which provides fast
crash recovery functionality, is included with all versions of HP-UX.
OnlineJFS is an extra product that makes it possible to extend, reduce, defragment, back up,
and tune JFS file systems on mission critical, 24x7 systems. OnlineJFS is included in the
HP-UX 11i v1 and v2 "Enterprise" and "Mission Critical" bundles, and in the 11i v3 “VSE”,
“High Availability”, and “Data Center” Operating Environments. Other customers must
purchase and OnlineJFS license separately.
Use the following command to determine if you have the optional OnlineJFS product
installed. The product name suffix varies somewhat depending on the JFS version, so
include an asterisk wildcard character on the end of the product name.
# swlist –l product OnlineJFS*
Customers who have an Online JFS license can install the Online JFS product from the
Applications CD with the swinstall command.
# swinstall

Module 8
After installing the software, you can begin using the Online features immediately; no
changes are required to the existing JFS file systems.
Upgrading JFS File Systems

Each major HP-UX release has introduced a new version of JFS, supporting new features and
functions. You must consider two issues when determining which of these features will be
available on your system: (a) the version number on the JFS product installed on your system
and (b) the file system’s JFS layout version. The table below summarizes the current JFS
versions available for various HP-UX OS versions at the time this book went to press.
HP-UX OS Default JFS Default JFS Comments

Version Product Version Layout Version
11i v1 3.5 5
11i v2 4.1 6 VxFS 5.0 upgrade available
11i v3 4.1 or 5.0* 7
* 11i v3 administrators can select either VxFS 4.1 or 5.0 during the OS installation process.
See the VxFS Installation Guide on http://docs.hp.com if you want to upgrade your
JFS software from 4.1 to 5.0.
Later JFS versions provide backwards compatibility with older JFS versions. Thus, a system
running JFS 5.0 can still mount a file system created in JFS 3.5. To take advantage of the
latest JFS features and performance benefits, though, consider upgrading the file system
metadata structures to the current JFS Layout Version via the vxupgrade command while
the file system remains mounted.
# vxupgrade -n 7 /data
/data: vxfs file system version 7 layout
Determining Your File System Type and Version

You can determine a logical volume or disk's file system type with the fstyp command. If
the file system is VxFS/JFS, the second line will display the JFS file system layout version
number.
vxfs
version: 6
f_bsize: 8192
f_frsize: 1024
f_blocks: 16384
f_bfree: 14653
f_bavail: 13738
f_files: 3692
f_ffree: 3660
f_favail: 3660
f_fsid: 1073741834
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5

Module 8
f_featurebits: 0
f_flag: 16
f_fsindex: 9
f_size: 16384

Module 8
8–12. SLIDE: Part 2: Creating and Mounting File Systems
Managing File
Systems
Part 2: Creating and Mounting
File Systems
Student Notes
Ignite-UX, HP’s installation utility, automatically creates file systems on the system boot disk.
New application installations and expanding user and application disk space requirements
may require the administrator to extend existing file systems or create additional new file
systems. A later chapter discusses the procedures required to extend file systems. The
remaining slides in this chapter discuss the commands required to create and mount a new
file system.

Module 8
8–13. SLIDE: Overview: Creating and Mounting a File System
Overview: Creating and Mounting a File System

Creating and mounting a file system is a four step process
1. Identify or create an empty volume or disk

# lvcreate –L 16 –n datavol vg01
2. Create the new file system in the volume

# newfs /dev/vg01/rdatavol
3. Create a mount point and mount the file system

# mkdir /data
4. Add the file system to the /etc/fstab file

# vi /etc/fstab
Student Notes
The slide above overviews the process required to create a new file system; the remaining
slides in the chapter discuss each step in detail.
Step 1: Identify or Create an Empty Logical Volume or Disk

A file system can be created in an empty logical volume, or on a whole disk partition.
When using whole disk partitioning, use ioscan to view a list of disks, then consult
/etc/lvmtab, swapinfo, and bdf to determine which disks are already in use. By process
of elimination, identify an unused disk.
# ioscan –fnC disk view a list of disk DSFs in 11i v1 and v2

# ioscan –fnNC disk view a list of disk DSFs in 11i v3
# strings /etc/lvmtab which disks are configured as LVM disks?
# swapinfo –d which disks are configured as whole disk swap?
# bdf which disks are configured as whole disk file system disks?

Module 8
When using LVM, execute vgdisplay to determine if the desired volume group has
sufficient free space to accommodate a new logical volume.
# vgdisplay vg01
...
VG Name /dev/vg01
...
PE Size (Mbytes) 4
Free PE 8691
...
If the volume group lacks sufficient free space, add another disk to the volume group. If the
volume group has sufficient free space, execute lvcreate to create a new logical volume.
# lvcreate –L 16 –n datavol vg01
To learn more about adding disks and logical volumes, see the LVM chapters elsewhere in
this course.
Step 2: Create the New File System

Next, create a superblock, inode table, and other file system metadata structures for the new
file system via the newfs(1m) command. The example below creates a JFS file system in
logical volume /dev/vg01/rdatavol. The next slide presents more newfs examples.
Steps 3: Create a Mount Point and Mount the File System

Once the file system metadata structures have been created with newfs, create a mount
point directory, and mount the file system. A later slide describes a few of the many available
mount options.
# mkdir /data
Step 4: Add the File System to /etc/fstab

Finally, to ensure that the file system remounts after every reboot, add it to the /etc/fstab
configuration file. Every time the system boots, /sbin/init.d/localmount
automatically mounts all local file systems defined in /etc/fstab.

Module 8
8–14. SLIDE: Creating a File System
Creating a File System

Use newfs to create a super block, intent log, inode table and other required
file system metadata structures in a logical volume
Before After
Superblock
Intent Log
Inode Table
/dev/vg01/datavol /dev/vg01/datavol
Create a file system in a logical volume

# newfs [-F vxfs] \
[-o largefiles] \
[-s size] \
[-v] /dev/vg01/rdatavol
Verify a file system
# mkfs [–F vxfs] -m /dev/vg01/rdatavol
Student Notes
After selecting a logical volume or disk to be used by a new file system, use the newfs
command to create a superblock, inode table, and other metadata structures. In its simplest
form, newfs only requires a target DSF name, which may be a logical volume or a whole disk
DSF. Be sure to use the device’s raw/character DSF. The output below was captured on an
11i v3 system. newfs command output is slightly more verbose in 11i v1 and v2.
newfs: /etc/default/fs is used for determining the file system
type
version 6 layout
16384 sectors, 16384 blocks of size 1024, log size 1024 blocks
largefiles supported
newfs is just a front-end utility for the mkfs command, which actually creates the file
system. To see which file system layout options mkfs used when creating the file system,
execute mkfs with the –m option. When executed with the –m option, mkfs doesn’t
overwrite the file system; it simply reports the specified file system’s current configuration.

Module 8
# mkfs -m /dev/vg01/rdatavol
mkfs: /etc/default/fs is used for determining the file system type
mkfs -F vxfs -o ninode=unlimited,bsize=1024,version=6,inosize=256,
logsize=1024,largefiles /dev/vg01/rdatavol 16384
Both newfs and mkfs support a number of additional options which are described below.
newfs Options Common to HFS and VxFS

The newfs command has many options. Some apply to both file system types, some only
apply to HFS, and some only apply to JFS. The following list is a description of some of the
options that apply to both file system types.
-F hfs|vxfs Defines the desired file system type. If -F is not specified, the default
file system type is determined from the /etc/default/fs file.
-o largefiles Determines if the file system will allow "large files" over 2 GB in size.
Large files can be dynamically enabled/disabled later on a mounted file
system via fsadm.
# fsadm -F vxfs /data

nolargefiles
# fsadm -F vxfs -o largefiles /data
# fsadm -F vxfs /data
largefiles
-s size Specifies the desired file system size in blocks. Add a k, m, or g to

specify the size in kilobytes, megabytes, or gigabytes. By default,
newfs uses all of the space available on the specified logical volume
or disk.
-b block-size Specifies the file system's block size.
For HFS file systems, valid values are: 4096, 8192, 16384, 32768, or
65536 bytes. The default block size is 8192 bytes.
For JFS file systems, valid values are: 1024, 2048, 4096, or 8192 bytes.
For file systems smaller than 2TB, the default block size is 1024. For
file systems larger than 2TB, JFS increases the block size. See the
mkfs_vxfs(1m) man page for details.
-v Verbose. Display the mkfs command used to create the file system.
Additional Options Specific to HFS

Some newfs options are usually used only when creating HFS file systems:
-L/-S Early versions of HP-UX supported only "short" file names up to 14

characters in length. You can still enforce this limit if you wish using

Module 8
the -S option. By default, however, file systems now allow "long" file
names up to 256 characters in length.
-f frag-size Specifies the file system's fragment size in bytes. The fragment size
must be a power of two no smaller than the system’s physical block
size and no smaller than one-eighth of the file system block
size. The default value is 1024 bytes.
-m min-free This indicates the percentage of space in the file system reserved for
use by root. If the amount of free space in the file system falls below
this percentage, only the superuser can write to the file system. The
default value is 10%. Consider decreasing this value in large file
systems.
Additional Options Specific to VxFS

newfs provides few options for customizing VxFS file system layouts. With the exception of
-o largefiles described previously, most administrators accept the newfs defaults.
To customize other VxFS file system layout attributes, create the file system via mkfs rather
than newfs. The example below creates a VxFS file system with a 2MB intent log (rather
than the default 1MB). Specifying a non-default intent log size is recommended when
creating file systems to be shared via NFS.
# mkfs -F vxfs -o ninode=unlimited,bsize=1024,version=6,inosize=256,

logsize=2048,largefiles /dev/vg01/rdatavol 16384
See the mkfs_vxfs(1m) man page for more information.
Additional Options Specific to the Whole-disk Approach

Most administrators today choose to partition disks using LVM. If you prefer to use the
whole disk approach, use a newfs command similar to one of the following:
# newfs -F hfs /dev/rdisk/disk1 creates an HFS on disk1

# newfs -F vxfs /dev/rdisk/disk1 creates a VxFS on disk1
The -R option reserves space at the end of the disk for use as swap space:
# newfs -F hfs -R 200 /dev/rdisk/disk1 HFS, with 200 MB reserved for swap
# newfs -F vxfs -R 200 /dev/rdisk/disk1 VxFS, with 200 MB reserved for swap
You can also create a boot disk using the whole disk approach. See the description of the –B
option on the newfs_hfs(1m) man page for more information. Most administrators
configure boot disks via LVM, in which case newfs –B isn’t necessary.
NOTE: There are several man pages for the newfs command.
• newfs(1m) describes newfs options common to all file systems.
• newfs_hfs(1m) describes HFS-only options
• newfs_vxfs(1m) describes VxFS-only options.

Module 8
8–15. SLIDE: Mounting a File System
Mounting a File System

Mounting a file system logically associates the file system with a mount point
directory in a parent file system (typically the root file system)
usr var data file1 file2 file3
/dev/vg00/lvol3 root file system /dev/vg01/datavol file system
Create a mount point

# mkdir /data
Mount a file system
Verify that a file system successfully mounted
# mount -v
Student Notes
Mounting a File System

After creating a file system on a logical volume or device, incorporate it into the system's file
hierarchy by creating a mount point and mounting the file system. Note that the mount
command, unlike the newfs and mkfs commands, requires a block DSF rather than a
raw/character DSF.
# mkdir /data create a mount point

# mount /dev/vg01/datavol /data mount a file system on the mount point
Mounting a file system logically associates the root directory of the new file system with the
mount point directory. Accessing files below the mount point directory actually references
files in the file system mounted on the mount point directory.
NOTE: Most file system administration commands such as newfs require raw DSFs.
The mount command, however, requires a block DSF.

Module 8
Verify your work by running mount –v or bdf.
# mount -v
/dev/vg00/lvol3 on / type vxfs
ioerror=nodisable,log,dev=40000003
on Tue Jun 26 05:17:38 2007
/dev/vg00/lvol1 on /stand type vxfs
ioerror=mwdisable,log,tranflush,dev=40000001
on Tue Jun 26 05:17:45 2007
/dev/vg00/lvol8 on /var type vxfs
ioerror=mwdisable,delaylog,dev=40000008
on Tue Jun 26 05:18:08 2007
/dev/vg00/lvol7 on /usr type vxfs
on Tue Jun 26 05:18:08 2007
/dev/vg00/lvol4 on /tmp type vxfs
on Tue Jun 26 05:18:08 2007
/dev/vg00/lvol6 on /opt type vxfs
on Tue Jun 26 05:18:08 2007
-hosts on /net type autofs
ignore,indirect,nosuid,soft,nobrowse,dev=1000002
on Tue Jun 26 05:18:39 2007
/dev/vg00/lvol5 on /home type vxfs
on Mon Jul 2 13:34:18 2007
/dev/vg01/datavol on /data type vxfs
ioerror=mwdisable,delaylog,dev=4000000a
on Thu Jul 12 23:28:05 2007
The bdf command also displays a list of mounted file systems, as well as the amount of
space in use and available in each mounted file system.
# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 1048576 309216 733648 30% /
/dev/vg00/lvol1 1835008 144144 1677696 8% /stand
/dev/vg00/lvol8 8912896 347504 8501576 4% /var
/dev/vg00/lvol7 4030464 2991960 1030456 74% /usr
/dev/vg00/lvol4 524288 21184 499176 4% /tmp
/dev/vg00/lvol6 5308416 3796456 1500192 72% /opt
/dev/vg00/lvol5 212992 7776 203928 4% /home
/dev/vg01/datavol 16384 1730 13746 11% /data
Guidelines for Choosing a Mount Point

Though mount points can be created in any directory, most file systems are mounted on
mount points immediately under the / directory. /usr, /tmp, /home, and /data are just a
few examples of mount point directories you may have on your system.

Module 8
File systems should only be mounted on empty directories. If a file system is mounted on a
directory that already contains files and directories, those files and directories will be hidden
until the file system is unmounted!
Finally, note that it is not possible to mount a file system on a directory that another user or
application is currently using. Trying to mount a file system on a directory that is already in
use results in a "device busy" message.
Mount Options Common to HFS and VxFS

The mount command has many options. Some apply to both file system types, and some
only apply to a specific file system type. Following is a list of mount options common to
most file system types.
-a Mount all file systems listed in /etc/fstab.
-aF FSType Mount all file systems of the specified type.
-l List all mounted local file systems.
-v List all mounted file systems.
-o rw|ro Mount file system “read-write” or “read-only”.
-o suid|nosuid Enable/disable SUID executables.
-o quota|noquota Enable/disable quota checking. See the quota(5) man page for
-o [no]largefiles The nolargefiles option blocks attempts to access files

beyond 2GB, even if the file system’s largefiles bit is set.
The largefiles option allows attempts to access files

beyond 2GB, but only if the file system’s largefiles bit is
set.
-o defaults Mount rw,suid,largefiles,noquota.
mount Options Specific to HFS

There are a few HFS-specific mount options, but they are very infrequently used. Check the
mount_hfs(1m) man page for more information.
mount Options Specific to VxFS

VxFS supports numerous mount options. Tweaking these options can significantly impact
the performance of your JFS file systems. For example, the –o log|delaylog|tmplog
options determine when and how VxFS uses the intent log.
The –o log option ensures that when a process modifies a file, VxFS logs all of the
metadata changes to the intent log on disk before the application proceeds on to other tasks.
This guarantees the integrity of all file system metadata, but may slightly degrade
performance.

Module 8
The -o delaylog option guarantees full integrity for critical metadata. Logs critical
metadata changes immediately. Less critical metadata changes (such as time stamp changes)
may be lost in case of a system crash. This is the default logging option.
The -o tmplog option delays logging in a number of circumstances, which improves

performance, but increases the possibility of data loss or corruption. This option should only
be used when mounting temporary file systems.
For more complete descriptions of these and many other VxFS mount options, read the
mount_vxfs(1m) man page and the Veritas File System Administrator's Guide on
http://docs.hp.com, or attend HP's HP-UX Performance and Tuning class.
NOTE: There are several man pages for the mount command.
• mount(1m) describes options common to all file systems.
• mount_hfs(1m) describes HFS-only options.
• mount_vxfs(1m) describes VxFS-only options.

Module 8
8–16. SLIDE: Unmounting a File System
Unmounting a File System

• Unmounting a file system makes the file system inaccessible to users & applications
• Some administrative tasks can only be performed on unmounted file systems
usr etc data data1 data2 data3
/dev/vg00/lvol3 root file system /dev/vg01/datavol file system
Unmount a file system (fails if file system is in use)

# umount /data
Attempt to unmount all file systems
# umount -a
Verify that a file system successfully unmounted
# mount -v
Student Notes
Some administration tasks can only be completed on unmounted file systems. Unmounting a
file system logically disassociates the file system from the file system mount point, making
the file system inaccessible to users.
Now that you know how to mount a new file system, you should also be aware of how to
logically disassociate, or unmount, the new file system from the root file system. The
command used to unmount the file system is umount.
NOTE: The command is umount, not "unmount". The command uses the
block device file or mount-point directory.

Module 8
umount options include:
-a Umount "all" currently mounted file systems.
-F Fstype Specify a file system type
Instead of using the umount -a command, you can also use the umountall(1M)
command.
Unmounting Busy File Systems

By default, a file system cannot be unmounted if any of the files or directories in the file
system are currently in use, or if the file system has been configured for use as file system
swap.
Use the fuser command to identify which processes are using a file or file system. Specify
the target file system by device file name or by mount point directory (when using the mount
point directory name, also add the -c option). With the –k option, fuser also kills the
processes that are using the specified file or file system.
# fuser -u /data/data list processes using a specific file

# fuser -cu /data list processes using the file system on /data
# fuser -u /dev/vg01/datavol list processes using the FS in /dev/vg01/myfs
# fuser -ku /dev/vg01/datavol kill processes using the FS in /dev/vg01/myfs
OnlineJFS versions 3.5 and greater now include a new command that will automatically
forcefully unmount a file system, even if processes are currently using the file system.
# /sbin/fs/vxfs/vxumount –o force /data
Be very careful when using the fuser and vxumount commands. If possible, it is much
safer to kill application processes gracefully using your vendors’ recommended shutdown
procedures. Using these utilities to more forcefully kill processes or unmount file systems
that are still in use may leave your applications in an unusable state.
Some file systems, such as the / (root) file system and /usr, can’t be unmounted on a
running system since critical system daemons can’t function properly without them.
The shutdown and reboot commands automatically unmount all file systems during the
system shutdown process.

Module 8
8–17. SLIDE: Automatically Mounting File Systems
Automatically Mounting File Systems

To ensure that a file system remounts after every reboot, add it to /etc/fstab
# vi /etc/fstab
/dev/vg00/lvol1 /stand vxfs defaults 0 1

/dev/vg00/lvol3 / vxfs defaults 0 1
/dev/vg01/datavol /data vxfs defaults 0 3
Mount Backup fsck

Device File Name Mount Point FS Type
Options Frequency Order
Mount one file system in /etc/fstab

# mount /data
Mount all file systems in /etc/fstab
# mount -a
Repair and mount all file systems in /etc/fstab
# mountall
Student Notes
All file systems are unmounted during system shutdown. Any file systems that you wish to
mount automatically after the next system reboot should be added to the /etc/fstab file.
During the boot process, the /sbin/init.d/localmount script automatically mounts
file systems listed in /etc/fstab. This configuration file is not automatically maintained by
the system; it should be manually updated after creating or removing file systems.
After adding a file system to /etc/fstab, you needn't enter the full form of the mount
command when mounting the new file system. Look at the following examples:
# mount /data mount /data -- no need to name the logical volume

# mount –a mount all file systems in /etc/fstab
# mount /dev/vg01/datavol mount /dev/vg01/datavol -- no need to name the mount
point

Module 8
Syntax for /etc/fstab

Fields in the /etc/fstab file include the following:
block the block device file of the disk or logical volume containing the file
system
directory the file system’s mount point directory
type the file system type. Types include:
• cdfs local CD-ROM file system.

• hfs high-performance (McKusick) file system.
• nfs network or remote file system.
• vxfs journaled file system.
• swap the device file name is made available as a piece of
swap space by the swapon command.
• swapfs the file system which directory resides in is made
available as swap space by the swapon command.
• lofs the file system is a loopback file system.
• ignore marks unused sections (on multi-file system disks).
options a comma-delimited list of options used by mount(1M) and swap(1M).

Examples are:
• defaults Sets rw, suid and noquota mount options.

If you use this option, no other options can be
specified.
• rw (default) read/write
• ro read only
• suid (default) set user-id allowed
• nosuid no set user-id allowed
• quota enables checking of disk quota on this file
system
• noquota (default) no quota checking on this file system
backup-frequency reserved for possible use by future backup utilities.
pass-number determines the order in which fsck checks file systems after an
improper shutdown
comment a comment field (must be preceded by a #)
NOTE: For a more detailed description of the /etc/fstab file syntax, see
the fstab(4) man page. Also take a look at the man pages mount:
mount(1m), mount_hfs(1m), and mount_vxfs(1m) for file system
specific mount options.

Module 8
8–18. SLIDE: Mounting CDFS File Systems
Mounting CDFS File Systems
Use CDFS to mount High Sierra, ISO 9600, and Rock Ridge CDROMs.
1. Determine the device file name of the DVD drive.

# ioscan –funC disk 11i v1 and v2
# ioscan –funNC disk 11i v3
2. Create a mount point.

# mkdir /dvd
3. Mount the file system (additional mount options required in 11i v1).
# mount -F cdfs /dev/disk/disk1 /dvd
4. Add the file system to /etc/fstab

# vi /etc/fstab
/dev/disk/disk1 /dvd cdfs noauto 0 0
Student Notes
CDFS is a kernel subsystem that makes it possible to mount CDROMs and DVDs on HP-UX
systems. CDFS supports several common CDROM formats:
• the ISO9600 format

• the High Sierra format
• the ISO9660 Rockridge Extension format
(requires PHKL_28025 and PHKL_26269 in 11i v1)
Mounting a CDROM/DVD requires several steps. Simply create a mount point directory, then
mount the file system using the CDROM/DVD’s block DSF. At a minimum, use the ro mount
option to make it clear that the file system is read-only. The mount example on the slide
includes two additional options, which will be described in more detail below.
# ioscan -fnC disk find the block device file (11i v1 & v2)
# ioscan -fnNC disk find the block device file (11i v3)
# mkdir /dvd create a mount point directory
# mount –F cdfs /dev/disk/disk1 /dvd mount the CDROM/DVD

Module 8
Adding CDFS File Systems to /etc/fstab

Optionally, you can include CDFS file systems in the /etc/fstab file. Note that we use
fsck order number 0 as a place-holder in /etc/fstab; one would never actually run fsck
on a CDFS file system.
Also consider including the noauto option in /etc/fstab cdfs entries. This option
prevents the /sbin/init.d/localmount script from automatically mounting cdfs file
systems during the system boot process, but still allows the administrator to manually mount
a CDROM/DVD by simply typing mount /dvd. Here is a typical CDFS entry in
/etc/fstab :
/dev/disk/disk1 /dvd cdfs noauto 0 0
Once mounted, CDROM file systems can be accessed using the same HP-UX file system
commands that are used to navigate an HFS or JFS file system.
Converting File Names using CDFS Mount Options in 11i v1

By default in 11i v1, CDFS displays filenames using the standard 8.3;1 filename format that
was once popular in the PC world:
# mount -F cdfs –o ro /dev/disk/disk1 /dvd

# ls /dvd
RUNINSTA.;1
INDEX.HTM;1
This format may be inconvenient in an HP-UX environment since the semicolon is used as a
command separator in the POSIX shell. You can disable lowercase-to-uppercase filename
translation, and suppress the display of version numbers by using the -o cdcase option:
# mount -F cdfs –o ro,cdcase /dev/dsk/cxtxdx /dvd

# ls /dvd
runInsta.
index.htm
If you install the ISO 9660 Rockridge Extension patches mentioned above and mount file
systems with the rr mount option, CDFS provides even more flexibility. In 11i v1, this option
is required when dealing with CDROMs from Oracle and other third party vendors.
# mount -F cdfs -o ro,cdcase,rr /dev/disk/disk1 /dvd

# ls /dvd
runInstaller
index.htm
11i v2 and v3 display full length file names and uppercase and lower case filenames by
default, so the rr and cdcase options are not necessary.
CD-RW CDs
The open source cdrecord, CDROM burner software is included with the HP’s free Ignite-
UX product, which you can optionally install from the HP-UX media kit. If you wish to create

Module 8
DVD-R or DVD-RW disks, download and install the dvd+rw-tools product from
http://software.hp.com.

Module 8
8–19. SLIDE: Mounting ISO Files
Mounting ISO Files

• 11i v3 now enables you to mount ISO image files, too!
• An ISO file is a disk-based file containing an ISO 9660 CDFS file system.
• Many vendors – including HP -- now ship software in ISO format files.
1. Verify that you have the ISO enhancement bundle, and load the ISO kernel module
# swlist ISOIMAGE-ENH
# kcmodule cdfs=loaded fspd=loaded

# mkdir /dvd
3. Mount the file system.

# mount –F cdfs /root/myapp.iso /dvd
4. Add the file system to /etc/fstab.

# vi /etc/fstab
/root/myapp.iso /dvd cdfs noauto 0 0
Student Notes
11i v3 now enables you to mount ISO image files, too! An ISO file is a disk-based file
containing an ISO 9660 CDFS file system. Many vendors ship software in ISO format files.
For instance, if you have an HP support contract and request “e-delivery”, you can download
HP-UX media kits as ISO files. Search for “e-delivery” on http://www.hp.com to learn
more.
The process required to mount an ISO file is almost identical to the process required to
mount a CDROM.
1. Verify that you have the ISO enhancement bundle. This bundle is only supported on 11i
v3. Then load product’s dynamically loadable kernel module, and the cdfs kernel
module. The kernel configuration module

Module 8
# mkdir /dvd
3. Mount the file system.
# mount –F cdfs /root/myapp.iso /dvd
4. Optionally add the file system to /etc/fstab. Consider using the noauto mount
option described on the previous slide.
# vi /etc/fstab
/root/myapp.iso /dvd cdfs noauto 0 0
Creating ISO Files

You can also create your own ISO files. First, verify that you have the IGNITE product,
which you can install from the HP-UX media kit.
# swlist IGNITE
Then create the ISO with the mkisofs command. The example below creates an ISO file in
/root/user1.iso that contains the contents of the /home/user1 directory.
# /opt/ignite/lbin/mkisofs -R -o /root/user1.iso /home/user1

Total translation table size: 0
Total rockridge attributes bytes: 808
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 1c4c8
216 extents written (0 MB)

Module 8
8–20. SLIDE: Mounting LOFS File Systems
Mounting LOFS File Systems
HP’s Loopback File System (LOFS) allows a file hierarchy to appear under
multiple mount points simultaneously, without creating symbolic links
1. Create a new mount point directory

# mkdir /opt/data
2. Mount an existing hierarchy as an LOFS under a new mount point

# mount –F lofs /data /opt/data
3. Add the LOFS file system to /etc/fstab

# vi /etc/fstab
/data /opt/data lofs defaults 0 0
4. Unmount an LOFS file system

# umount /data
Student Notes
The Loopback Filesystem (LOFS) allows the same file hierarchy to appear
in multiple places. Traditionally, this was accomplished via symbolic links:
# ln -s /data /opt/data
# ls /data /opt/data
/data:
d1 d2 d3
/opt/data:
d1 d2 d3

Module 8
HP-UX provides a more elegant solution via the LOFS file system:
# mkdir /opt/data
# mount –F lofs /data /opt/data
# ls /data /opt/data
/data:
d1 d2 d3
/opt/data:
d1 d2 d3
In order to make an LOFS file system accessible after every reboot, add it to the
/etc/fstab file:
# vi /etc/fstab
/data /opt/data lofs defaults 0 0

Module 8
8–21. SLIDE: Mounting MemFS File Systems
Mounting MemFS File Systems
HP’s MemFS product provides a fast memory-based file system for storing and
managing temporary files without incurring disk I/O
1. Verify that MemFS is installed

# swlist MemFS
2. Create a new mount point directory

# mkdir /data
3. Create and mount a MemFS file system

# mount –F memfs –o size=1g –o ninode=1024 /data
4. Change the maximum size of an existing MemFS file system

# mount –o remount –o size=2g –o ninode=2048 /data
5. Add the MemFS file system to /etc/fstab

# vi /etc/fstab
memfs /data memfs size=1g,ninode=1024 0 0
Student Notes
Writing data to and from physical disks is a resource intensive operation; accessing data in
memory is typically much faster.
The HP-UX “memory-based file system” product (MemFS) allows you to store directories and
files in memory rather than on disk. Users can access files and directories in a MemFS file
system as they would files and directories in an HFS or JFS file system, though the internal
implementation is quite different from disk-based file systems.
MemFS typically provides extremely high throughput. However, since MemFS files are
stored in memory rather than on disk, as soon as you unmount a MemFS file system or
reboot, the files and directories in the file system disappear. MemFS is most appropriate for
application file systems containing temporary files.
MemFS was first introduced in 11i v2 and is now supported in 11iv3, too. You can download
the 11i v2 version of the product from http://software.hp.com. In 11i v3, MemFS is
included on the operating environment installation DVD. Use swlist to verify that you
installed the product.

Module 8
# swlist MemFS
# Initializing...
# Contacting target "myhost"...
#
# Target: myhost:/
#
# MemFS B.11.31.01 Memory File System
MemFS.MemoryFSKern B.11.31.01 Memory File System (MemFS) Kernel
Modules
MemFS.MemoryFSCmd B.11.31.01 Memory File System (MemFS) Commands
Create a mount point for the file system.
# mkdir /data
Create and mount the file system.
# mount –F memfs –o size=1g –o ninode=1024 /data
The size= option specifies the maximum file system size. If not specified, or if you specify
size=0, the size of the file system is limited only by the available swap space. If specified, it
ensures that the file system does not grow beyond the specified size. Specifying size does not
assure that the specified size will be available for use since free space on MemFS file systems
depends on available swap space at that instant.
The ninode= option specifies the maximum number of files to be allowed in the file system.
If not specified, or if you specify ninode=0, the number of files is limited only by the amount
of memory made available to MemFS by memfs_metamax kernel parameter.
After initially mounting a MemFS file system, you can change the size and ninode mount
options at any time via the –o remount option.
# mount –o remount –o size=2g –o ninode=2048 /data
To ensure that the MemFS file system remounts after every reboot, add the file system to the
/etc/fstab file.
# vi /etc/fstab
memfs /data memfs size=1g,ninode=1024 0 0
To learn more about MemFS, see the Memory File System (MemFS) 2.0 for HP-UX 11i v3
Administrator's Guide on http://docs.hp.com.

Module 8
8–22. LAB: Creating and Mounting File Systems
Directions
Record the commands used to complete the tasks below, and answer all of the questions.
Part 1: Preliminary Steps

1. The exercises in this lab assume that you already have the following logical volumes:
/dev/vg01/swapvol
/dev/vg01/datavol
If you already have these logical volumes, you can skip ahead to Part 2 of the lab.
Otherwise, create an LVMv2.2 volume group called vg01 with your spare disk. Specify
maximum volume group size 1TB with a 4MB extent size. Create two 32MB logical
volumes in vg01 called datavol and swapvol.

Module 8
Part 2: Reviewing the Current Configuration

1. How many file systems are currently mounted on your lab system?
2. List at least two reasons why it may be beneficial to configure multiple file systems rather
than one file system containing all files and directories.
3. Does your lab system have HFS file systems, JFS file systems, or both types of file
systems?
4. Name at least one advantage of using VxFS file systems rather than HFS.
5. Use the following command to determine if you have the optional OnlineJFS product
Name at least one advantage provided by the OnlineJFS product.

Module 8
6. If you execute the following commands, in which logical volume will each file be
physically stored?
# touch /stand/test1
# touch /etc/test2
7. The chapter discussed several different file system components. Match each component
below with the appropriate description.
superblock = ___ a. Records a file’s type, size, and other attributes
inode = ___ b. Records a file system’s type, size, and other attributes
intent log = ___ c. Associates file names and inode numbers
directory = ___ d. Records pending metadata updates
8. Which of the following statements are true?
a. A VxFS extent may include multiple blocks
b. Blocks included in an extent must be contiguous.
c. A VxFS extent’s size must be a multiple of the block size.

Module 8
Part 3: Creating and Mounting File Systems

1. Create a file system in the datavol logical volume. Don’t specify a file system type, and
don't mount the file system yet.
2. What type of file system did newfs create?

Which configuration file determines the default file system type?
3. Use mkfs –m to verify the new file system and answer the questions below.
a. What is the new file system’s block size?
b. What is the new file system’s intent log size?
c. Did newfs enable large files?
4. Execute mount -v. Why doesn't the new file system appear in the mount table?
5. Create a /data mount point for the new file system.

Module 8
6. Mount the file system. Verify that the file system successfully mounted.
7. Add the new file system to /etc/fstab to ensure that it remounts automatically after
every reboot. Specify backup frequency 0 and fsck check order 3.
8. Unmount the file system.
9. Execute mount –a to mount all of the file systems configured in /etc/fstab. Watch
the resulting messages carefully. You should see several error messages indicating that
/dev/vg00/lvoll and several other file systems are already mounted. Do the
mount -a output messages offer any indication that your new file systems were
successfully mounted?
10. Execute mount -a a second time and note the output messages again. Why did
mount -a mention your new file system in its output this time, but not when you
executed mount -a in the previous exercise?

Module 8
11. Execute mount –v to verify that your file system is mounted. What other information
can you glean from the mount -v output about your mounted file systems? List three
fields presented in the mount -v output.

Module 8
Part 4: Experimenting with newfs, mount, and umount

1. The exercises in this section will be more meaningful if you have some real files in the
/data file system. Copy a few files to the file system.
# cp /usr/bin/d* /data 2>/dev/null

# ls /data
You may notice a lost+found directory in your new file system. newfs creates this
directory for you automatically. The fsck utility, which may be used to repair file system
corruption, moves irreparable files to the lost+found directory. This directory will be
discussed in a later chapter.
2. Can you access files in a file system that is unmounted? Try it!
# umount /data
# ls /data
Does the /data mount point still exist?

Are any files visible under the mount point?
3. Can you copy files to the mount point directory while the file system is unmounted? Try
it!
# cp /usr/bin/r* /data 2>/dev/null

Module 8
4. What happens if you mount a file system on a mount point directory that already contains
files? Try it! Remount the file system and list the contents of /data.
# mount /data
# ls /data
Are the /data/d* files visible? Are the /data/r* files visible?
5. Can you unmount a file system that is still in use? cd to /data . Try to unmount the file
system while /data is your present working directory.
# cd /data
# umount /data
umount: cannot unmount /dev/vg00/datavol : Device busy
umount: return error 1.
What happens?
6. Before you can unmount a file system, you will have to kill all processes accessing the file
system. HP-UX provides a command to solve this very problem. Try the following
command:
# fuser -uc /data
Each entry in the fuser output lists the PID of a process accessing the file system, a
single letter code indicating how the process is using the file system ("c" indicates that a
user has changed to a directory in the file system), and the name of the user that owns
the offending process.
7. Adding the –k option causes fuser to kill the offending processes. Try it!
# fuser -kuc /data
What happens?

Module 8
8. Log back in again if necessary and unmount /data.
# umount /data
9. Remount the file system.
# mount /data
10. What happens if you accidentally newfs a device containing a mounted file system? Try
it!
11. What happens if you accidentally newfs a device containing an unmounted file system?
Try it!
# umount /data
12. Remount /data. Did your d* files survive the newfs?
# mount /data
# ls /data

Module 8
13. One last experiment: Can you unmount all of your file systems? Execute umount -a
and explain the result.
# umount –a
14. Remount all of your file systems before continuing.

Module 8
Part 5: (Optional) Mounting ISO, LOFS, and MemFS File Systems

1. Verify that you have the ISO enhancement bundle. Then ensure that the fspd and cdfs
kernel modules are loaded.
2. Create a /dvd mount point and mount the /labs/echoapp.iso ISO file. Do not add
the file system to /etc/fstab.
3. Execute mount –v and ls /dvd to verify that this worked.
4. Create a /users mount point directory and mount /home as an LOFS file system. Add
5. List the contents of /home and /users. Create a /home/user26 directory then list the
contents of /home and /users again. What is the advantage of an LOFS file system?
6. Create a /var/opt/myapp/tmp mount point. Mount a MemFS file system on the mount
point with maximum file system size 100MB.
7. Copy a few files to the file system.
# cp /usr/bin/m* /var/opt/myapp/tmp
# ls /var/opt/myapp/tmp

Module 8
8. Unmount the file system, then remount it. Are the files still there?
9. When might MemFS file systems be useful?
10. Unmount your ISO, LOFS, and MemFS file systems. If you added any ISO, LOFS, or
MemFS entries to /etc/fstab, remove them.

Module 8


# fsweb
HP-UX.

Module 8
8–23. LAB SOLUTIONS: Creating and Mounting File Systems
Directions
Record the commands used to complete the tasks below, and answer all of the questions.
Part 1: Preliminary Steps

1. The exercises in this lab assume that you already have the following logical volumes:
/dev/vg01/swapvol
/dev/vg01/datavol
If you already have these logical volumes, you can skip ahead to Part 2 of the lab.
Otherwise, create an LVMv2.2 volume group called vg01 with your spare disk. Specify
maximum volume group size 1TB with a 4MB extent size. Create two 32MB logical
volumes in vg01 called datavol and swapvol.
Answer:

Module 8
Part 2: Reviewing the Current Configuration

1. How many file systems are currently mounted on your lab system?
Answer:
# mount –v
The number of file systems may vary, but there should be at least eight.
2. List at least two reasons why it may be beneficial to configure multiple file systems rather
than one file system containing all files and directories.
Answer:
The administrator can allocate a fixed amount of disk space to each file system to ensure
that no single file system is allowed to monopolize an entire disk. The administrator
might, for instance, allocate 1GB to the /tmp file system. This ensures that temporary
files under /tmp can use at most 1GB of disk space; remaining disk space could be
preserved for other file systems.
Each file system may be tuned independently. There are a number of parameters
associated with each file system that can significantly affect system performance. It may
be beneficial to optimize some file systems for storage of large files, while others are
optimized for storage of smaller files.
File system maintenance tasks may be performed on one file system, while other file
systems remain accessible to users.
3. Does your lab system have HFS file systems, JFS file systems, or both types of file
systems?
Answer:
# mount –v
If your lab system is an Integrity server, the file systems are probably VxFS. If your lab
system is a PARISC server, then the /stand file system should be HFS, and all others
should be VxFS.
4. Name at least one advantage of using VxFS file systems rather than HFS.
Answer:
VxFS supports much larger file systems than HFS.
VxFS supports fast file system recovery after a system crash.
VxFS supports a variety of online operations that can be performed on a mounted file
system.

Module 8
5. Use the following command to determine if you have the optional OnlineJFS product
Answer:
OnlineJFS enables the administrator to extend, reduce, and defragment file systems
without unmounting.
6. If you execute the following commands, in which logical volume will each file be
physically stored?
# touch /stand/test1
# touch /etc/test2
Answer:
test1 will be stored in /dev/vg00/lvol1 since /dev/vg00/lvol1 is mounted on

/stand.
test2 will be stored in /dev/vg00/lvol3 since /etc is a subdirectory of / in the

/dev/vg00/lvol3 file system.
7. The chapter discussed several different file system components. Match each component
below with the appropriate description.
superblock = ___ a. Records a file’s type, size, and other attributes
inode = ___ b. Records a file system’s type, size, and other attributes
intent log = ___ c. Associates file names and inode numbers
directory = ___ d. Records pending metadata updates
Answer:
superblock = b
inode = a
intent log = d
directory = c

Module 8
8. Which of the following statements are true?
a. A VxFS extent may include multiple blocks
b. Blocks included in an extent must be contiguous
c. A VxFS extent’s size must be a multiple of the block size.
Answer:
All three statements are true.

Module 8
Part 3: Creating and Mounting File Systems

1. Create a file system in the datavol logical volume. Don’t specify a file system type, and
don't mount the file system yet.
Answer:
2. What type of file system did newfs create?

Which configuration file determines the default file system type?
Answer:
The output from newfs suggests that the file system type is VxFS.
The /etc/default/fs configuration file defines the default file system type:
# cat /etc/default/fs
3. Use mkfs –m to verify the new file system and answer the questions below.
a. What is the new file system’s block size?
b. What is the new file system’s intent log size?
c. Did newfs enable large files?
Answer:
# mkfs –m /dev/vg01/rdatavol
a. 1024 bytes
b. 1024KB
c. Yes.
4. Execute mount -v. Why doesn't the new file system appear in the mount table?
Answer:
# mount –v
The new file system doesn’t appear since it hasn’t been mounted yet.

Module 8
5. Create a /data mount point for the new file system.
Answer:
# mkdir /data
6. Mount the file system. Verify that the file system successfully mounted.
Answer:

# mount -v
7. Add the new file system to /etc/fstab to ensure that it remounts automatically after
every reboot. Specify backup frequency 0 and fsck check order 3.
Answer:
# vi /etc/fstab
/dev/vg01/datavol /data vxfs defaults 0 3
8. Unmount the file system.
Answer:
# umount /data
9. Execute mount –a to mount all of the file systems configured in /etc/fstab. Watch
the resulting messages carefully. You should see several error messages indicating that
/dev/vg00/lvoll and several other file systems are already mounted. Do the
mount -a output messages offer any indication that your new file systems were
successfully mounted?
Answer:
# mount –a
The output from mount -a notes that several other file systems are "already mounted",
but there is no mention of the two new file systems. Oftentimes in UNIX, the absence of
an error message, you may assume that a command has succeeded. mount -a
exemplifies this philosophy. Because mount -a didn't complain about your new file
systems, you can assume that they mounted successfully.

Module 8
10. Execute mount -a a second time and note the output messages again. Why did
mount -a mention your new file system in its output this time, but not when you
executed mount -a in the previous exercise?
Answer:
In the previous question, mount -a successfully mounted the new file systems as they
weren't yet mounted. Executing mount -a a second time generates an error message
because the new file system is already mounted.
11. Execute mount –v to verify that your file system is mounted. What other information
can you glean from the mount -v output about your mounted file systems? List three
fields presented in the mount -v output.
Answer:
Your file systems should all be mounted at this point.
mount -v presents several fields of information including:
Device name
Mount point
File system type
Mount options
Mount time

Module 8
Part 4: Experimenting with newfs, mount, and umount

1. The exercises in this section will be more meaningful if you have some real files in the
/data file system. Copy a few files to the file system.
# cp /usr/bin/d* /data 2>/dev/null

# ls /data
You may notice a lost+found directory in your new file system. newfs creates this
directory for you automatically. The fsck utility, which may be used to repair file system
corruption, moves irreparable files to the lost+found directory. This directory will be
discussed in a later chapter.
2. Can you access files in a file system that is unmounted? Try it!
# umount /data
# ls /data
Does the /data mount point still exist?

Are any files visible under the mount point?
Answer:
After unmounting the file system, the mount point is still there, but the files in the file
system are no longer visible under the mount point. The files in the file system cannot be
accessed again until the file system is remounted.
3. Can you copy files to the mount point directory while the file system is unmounted? Try
it!
# cp /usr/bin/r* /data 2>/dev/null
Answer:
This should work, but as you will discover in the next step, the files were copied to the
/data mount point in the /dev/vg00/lvol3 root file system rather than the
/dev/vg01/datavol file system!
4. What happens if you mount a file system on a mount point directory that already contains
files? Try it! Remount the file system and list the contents of /data.
# mount /data
# ls /data
Are the /data/d* files visible? Are the /data/r* files visible?
Answer:
The /data/d* files are back, but the /data/r* files are no longer accessible.

Module 8
NOTE: File systems should always be mounted on empty mount point

directories.
5. Can you unmount a file system that is still in use? cd to /data . Try to unmount the file
system while /data is your present working directory.
# cd /data
# umount /data
umount: cannot unmount /dev/vg00/datavol : Device busy
umount: return error 1.
What happens?
Answer:
The umount fails. You can’t unmount a file system that is still in use.
6. Before you can unmount a file system, you will have to kill all processes accessing the file
system. HP-UX provides a command to solve this very problem. Try the following
command:
# fuser -uc /data
Each entry in the fuser output lists the PID of a process accessing the file system, a
single letter code indicating how the process is using the file system ("c" indicates that a
user has changed to a directory in the file system), and the name of the user that owns
the offending process.
7. Adding the –k option causes fuser to kill the offending processes. Try it!
# fuser -kuc /data
What happens?
Answer:
Since your shell is the process using the file system, your terminal session should die.
8. Log back in again if necessary and unmount /data.
# umount /data
Answer:
This time it works.
9. Remount the file system.
# mount /data

Module 8
10. What happens if you accidentally newfs a device containing a mounted file system? Try
it!
Answer:
Fortunately, this fails. You can’t overwrite a mounted file system.
11. What happens if you accidentally newfs a device containing an unmounted file system?
Try it!
# umount /data
Answer:
This successfully overwrites the file system.
12. Remount /data. Did your d* files survive the newfs?
# mount /data
# ls /data
Answer:
Unfortunately, the files are gone. Be very careful when file systems are unmounted!
13. One last experiment: Can you unmount all of your file systems? Execute umount -a
and explain the result.
# umount –a
Answer:
# umount –a
umount: cannot unmount /dev/vg00/lvol6 : Device busy
Though a couple file systems may successfully unmount, most will fail because they are
in use by the system daemons.
14. Remount all of your file systems before continuing.
Answer:
# mount –a

Module 8
Part 5: (Optional) Mounting ISO, LOFS, and MemFS File Systems

1. Verify that you have the ISO enhancement bundle. Then ensure that the fspd and cdfs
kernel modules are loaded.
Answer:
2. Create a /dvd mount point and mount the /labs/echoapp.iso ISO file. Do not add
Answer:
# mkdir /dvd
# mount –F cdfs /labs/echoapp.iso /dvd
3. Execute mount –v and ls /dvd verify that this worked.
Answer:
# mount –v
# ls /dvd
4. Create a /users mount point directory and mount /home as an LOFS file system. Add
Answer:
# mkdir /users
# mount –F lofs /home /users
# vi /etc/fstab
/home /users lofs defaults 0 0
5. List the contents of /home and /users. Create a /home/user26 directory then list the
contents of /home and /users again. What is the advantage of an LOFS file system?
Answer:
# ls /home /users
# mkdir /home/user26
# ls /home /users
The contents of the two directories should be identical. LOFS makes it possible to access
a directory or file system’s content via two different mount points.
6. Create a /var/opt/myapp/tmp mount point. Mount a MemFS file system on the mount
point with maximum file system size 100MB.
Answer:

Module 8
# mkdir –p /var/opt/myapp/tmp
# mount –F memfs –o size=100m /var/opt/myapp/tmp
7. Copy a few files to the file system.
# cp /usr/bin/m* /var/opt/myapp/tmp
8. Unmount the file system, then remount it. Are the files still there?
Answer:
# umount /var/opt/myapp/tmp
# mount /var/opt/myapp/tmp
The files disappear as soon as you unmount the MemFS file system.
9. When might MemFS file systems be useful?

Answer:
MemFS file systems are useful for storing temporary application files when file access
time is important.
10. Unmount your ISO, LOFS, and MemFS file systems. If you added any ISO, LOFS, or
MemFS entries to /etc/fstab, remove them.
Answer:
# umount /dvd
# umount /users
# umount /var/opt/myapp/tmp
# vi /etc/fstab

Module 8


# fsweb
HP-UX.

Module 8


2010.H3064S StudentGuide-01 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2010.H3064S StudentGuide-01 PDF

Загружено:

Авторское право:

Доступные форматы

HP-UX System and Network

Module 1 ⎯ Course Overview

Module 2 — Navigating SAM and the SMH

Module 3 ⎯ Managing Users and Groups

http://education.hp.com i H3064S I.00

Module 4 ⎯ Navigating the HP-UX File System

Module 5 — Configuring Hardware

H3064S I.00 ii http://education.hp.com

5–44. SLIDE: Agile View FC Lunpath Hardware Addresses (2 of 2) .................................... 5-83

Module 6 ⎯ Configuring Device Files

Module 7 ⎯ Managing Disk Devices

http://education.hp.com iii H3064S I.00

7–4. SLIDE: LVM Physical Volume Concepts .............................................................................7-8

Module 8 ⎯ Managing File Systems

H3064S I.00 iv http://education.hp.com

• List the topics covered in this course.

• List the currently supported HP-UX operating system versions.

• List some common reference sources used by HP-UX system administrators.

• Determine a system’s current OS version.

http://education.hp.com 1-1 H3064S J.00

1–1. SLIDE: Course Audience

H3064S J.00 1-2 http://education.hp.com

1–2. SLIDE: Course Agenda

Managing Hardware Managing Software with SD-UX

http://education.hp.com 1-3 H3064S J.00

1–3. SLIDE: HP-UX Versions

Release Release Supports PARISC Supports Integrity

H3064S J.00 1-4 http://education.hp.com

# swlist -l bundle QPKBASE

http://education.hp.com 1-5 H3064S J.00

1–4. SLIDE: HP-UX System Administration Resources

HP-UX System Administration Resources

HP’s documentation website:

HP’s software download website:

http://www.hp.com HP’s corporate/product website describes all of

http://itrc.hp.com HP’s IT Resource Center provides a wealth of

H3064S J.00 1-6 http://education.hp.com

http://docs.hp.com HP’s documentation website provides an online,

The HP-UX System Administrator’s Guide,

The equivalent HP-UX 11i v1 and v2 manual is titled

http://software.hp.com/ Visit HP’s software download website to download

http://www.hp.com/education HP Education Services offers a wide variety of

http://education.hp.com 1-7 H3064S J.00

H3064S J.00 1-8 http://education.hp.com

• Launch the SMH GUI and TUI interfaces.

• Enable SMH autostart functionality.

• View hardware status information via the SMH.

• Launch SMH tools.

• Create custom SMH tools.

• Execute SMH tasks.

• View log files via the SMH.

• Configure SMH group access rights.

• Configure SMH authentication.

• Describe SMH/SIM integration possibilities.

http://education.hp.com 2-1 H3064S J.00

2–1. SLIDE: SAM and SMH Overview

SAM and SMH Overview

Feature SAM SMH

H3064S J.00 2-2 http://education.hp.com

HP-UX versions supported

Intuitive Terminal User Interface (TUI)

In 11i v3, the SMH provides a TUI interface, too.

Intuitive Graphical User Interface (GUI)