Lesson - 5 Device Management

Device Terminology
    No of hardware and software devices must interact correctly for the device to function properly.

1. Physical devices
2. Ports
3. Device Drivers
4. To put a defined device to available
5. Logical devices (/dev)

Note: Some of the logical devices are accessed only ODM cannot accessed by users

Types of devices

         1.  Primary Devices (RAM,CPU and Motherboard)

         2. Secondary Devices

             Hard disk, floppy disk, tape drive, printers , physical adapters, error special files, null special files etc.,

             a) Block devices: This is the structured random device. Buffering is used to provide a block-at-a-time method of access. This is usually a disk file systems

             b) Character devices: This is the sequential, stream oriented device which does not use buffering

        3. Base devices : Keyboard, Mouse

Examples of block devices

Following are examples of block devices:

cd0                        CD-ROM

fd0, fd0l, fd0h       Diskette

hd1, lv00               Logical volume

hdisk0                   Physical volume

Examples of character (raw) devices

       Following are examples of character (raw) devices:

console, lft, tty0       Terminal

lp0                            Printer

rmt0                         Tape drive

tok0, ent0                 Adapter

kmem, mem, null      Memory

rfd0, rfd0l, rfd0h       Diskette

rhd1, rlv00                Logical volume

rhdisk0                      Physical volume

Note: Most of the block devices have equivalent character device , For ex, /dev/hd1 provides buffered access to a logical volume whereas /dev/rhd1 provides raw access to the same logical volume. (The raw devices are ususally accessed by the kernel)

Major and Minor Number

maj,min dev nums

brw------- 1 root system 32,8192 Nov 03 14:19 hdisk3

brw------- 1 root system 32,8194 Nov 03 14:19 hdisk4

brw------- 1 root system 32,8195 Nov 07 07:08 hdisk5

Major no is 32 and minor no is 8192,8194 ...

Major no refers to the s/w section of code in the kernel which handles that type of device(hard disk). and minor no to the particular device of that type.

Device Configuration Database

     The predefined and customized databases store information of all the logical devices in the system and their attributes. It is managed by ODM.

Predefined Database (PdDv) List all the Supported Devices

• Contains all the possible devices supported by the system.s
• Devices in Undefined state
• Output contains column like

Class - what the device does

Type - what model

subclass – Where it is attached

 Using “lsdev -P” command can list the devices supported by the system

Customized Database (CuDv) – List Defined Devices

• List the actual devices used (configured) by the system.
• Displays name,status, Location and description.
• “lsdev -CH” provides information about the Customized devices.
  
  The status column contain 2 states

            Available – Device ready to use

            Defined -- Device is unavailable

     Note: Devices may appear in the Defined state after restart the server, the reason is either the corresponding device is powered off or removed from the server.

• Devices with location code are physical devices. Devices without location codes are logical devices. Location codes depend on type of device and the adapter to which the device is connected.
• “lsattr -E -l <resource-name> command provides detailed effective attributes of currently configured devices.
• “lscfg -v” - important Customized database command in which displays complete information about the device in ODM. display vital product data (VPD) such as part no, serial nos, Model architecutre, FRU, part number etc., for all the devices present on the system                            

Device Status

       The most common devices states are as follows.

       1. Undefined

       The device is supported device but not configured. Devices reside in the Predefined Database not customized database.

      2. Defined

      The device is configured but unavailable to use. Devices reside in Customized databases

are in defined state.

     3. Available

     The device is available and ready to use.

Configuring Devices

     1. “cfgmgr” configure all self-configuring devices.

     2. While configuring the devices, cfgmgr checks whether the device is support on your AIX system by checking the PdDv.

    3. Once the information is found in PD DB, it uses complete information to complete entries into the customized devices database CuDv.

     4. It also loads the appropriate device driver into the AIX kernel and makes the logical devices under /dev directory.

     5. Finally makes the device to available state (ODM).

The above 3 &4 steps are performed by mkdev command

Changing Device State

i. To put a defined device to available

        #mkdev -l <dev>

 ex.,#mkdev -l hdisk1

ii. To put a available device to defined

        #rmdev -l <device>

 ex.,#rmdev -l hdisk1

iii. To permanently remove from ODM. 

        #rmdev -dl <device>

  ex.,#rmdev -dl hdisk1

                                                                                                            

Device Addressing

• Location codes are used for device addressing
• Where exactly the device is connected to your m/c.
• Location code is made up of 4 fields of information. Useful in troubleshooting scenarios, referred on LED hardware troubleshooting.
• Devices which are having location code are physical deviecs, not having location code are called logical devices.
• Location codes depend on the type of the device and adapter to which it connects.
• Location code is another way of identifying Physical device.

Format for ex;

AB-CD-EF-GH for non SCSI/PCI devices

AB-CD-EF-G,H for SCSI devices

Commands for displaying Location codes are as follows

         #lsdev -Cc adapter

         #lscfg -vl <name of device>

          “lscfg” list the vital product data including h/w serial no.type, model and part numbers.

Important Commands

1. lsdev --> List all the devices (Predefined and Customized)
2. lsattr --> List attributes of the devices
3. lscfg --> List the VPD information of the configured (customized) devices

Options  for Device Commands

LSDEV

-P --> Predefined devices

-C --> Customized devices

-c --> Class type

-H --> Header information

-l --> Specify logical device name

-p --> child devices of parent deviecs

-F --> parent device of particular child device (use “lsparent -Cl hdisk0)

LSATTR

-E --> Effective attributes of the devices

-l --> Specify the logical device name

RMDEV

-l --> logical device name

-d --> completely removes from ODM.

-SR --> removes all child devices from the parent device.

LSCFG

#lscfg -vp --> all h/w information

#lscfg -vl --> for particular logical device

Network Installation Manager (NIM) -- Part 1 Introduction & Concepts

Introduction

       NIM (Network Installation Manager) is a IBM AIX  Service used for remote unattended installation similar to the Sun/Oracle Jumpstart and RedHat Kickstart or PXE without DVD/CD used to install AIX in many servers at a time in an Infra. Now, the installation of VIO and Linux can also be performed using NIM. Apart from installation, upgradation and maintainig AIX softwares/filesets the management activities like backup and restore of mksysb can be performed via NIM. By using NIM Master to store mksysb can reduce usage of tape device and time duration.

Activities performed by NIM
        1) New Installation (Pull method)
        2) TL/SP upgradation
        3) OS Migration/Upgradation
        4) mksysb backup/restore
        5) Provide boot CD image for maintenance activities
        6) Centralized repository for Filesets
        7) Used to restore missed files in the mksysb backup

Components of NIM
     The following are the important components involved in NIM installation, confiugration and managment.
   1. Master (NIM Master)
   As named NIM Master server is the repository of all the softwares, OS images, mksysb backup which serves the same to its clients for the corresponding operations.
   2. Client (NIM Client)
    Systems which are managed by NIM Master server for the operations like installation, backup and restoration 
   3. Resources (NIM Resources)
    This can be a single file or up to a whole filesystem that is used to provide some sort of information to, or perform an operation on a NIM client. Resources are allocated to NIM clients using NFS and can be allocated to multiple clients at the same time. The NIM resources are lpp_source,SPOT,mksysb,bosinst_data and image_data
   4. Resource Server 
     Server where resources are available. NIM client can also act as Resource Server. But in most cases NIM Master server will be the resource server. Briefly discuss types of  resources in consecutive sections.
   5. NIMSH Daemon (NIM Service Handler)
     For environments where the standard "rsh" protocol are not enough secure, at the time "nimsh". Using the port nos 3901 and 3902
   6. Allocate/Allocation :
      This process is what allows your NIM client to access resources in NIM. The master uses NFS to perform the allocation process. Resources can be allocated to one or more NIM clients at the same time

NIM RESOURCES

a) lpp_source
           It is just a directory which acts as source of installation which contains the following
                     *  OS image cd/dvd
                     *  filesets/packages
                     *  TL/SP updates
            These type of resources can be used for all NIM clients.
b) SPOT (Shared Processor Object Tree)
           It is similar to boot cd, we can boot the nimclient using the SPOT. It contains the "/usr" part i.e., kernel, filesets, device drivers and BOS install programs.
           There are 2 types of SPOT i) lppspot and ii) mksysbspot and these types of SPOT are specific to particular NIM client or can be used  for all NIM clients.
c) mksysb
         In general, rootvg backup is the mksysb backup which may be specific to particular NIM client.
         Important advantages are quick restoration of crashed OS and can create customized (hardened) mksysb backup of particular which could be installed/resotred in other servers to avoid fresh installation and performing hardening.
d) bosinst_data
       Customized Installation Procedure (bosinst.data) which is used in non-interactive installation, mainly POST installation changes.
e) image_data
        image.data (rootvg architecture) layout of LV,VG,PP information and its architecture.

Daemons Required

  a) bootp protocol (BOOTPD)

   This is the initial communication made between NIM master and client during network boot. 

  b) Trivial File Transfer Protocol (TFTPD)

  It is used to transfer lppsource,SPOT and other resources from NIM server to NIM client during the NIM client booting.

Check the services are running, 

#lssrc -ls inetd
bootps    /usr/sbin/bootpd   bootpd /etc/bootptab     active
tftp         /usr/sbin/tftpd        tftpd -n                    active
#grep bootps /etc/services
bootps                  67/tcp          # Bootstrap Protocol Server
bootps                  67/udp        # Bootstrap Protocol Server
#grep tftp /etc/services
tftp                    69/udp          # Trivial File Transfer
tftp                    69/tcp          # Trivial File Transfer
If the above services are not enabled, start the same.
#chubserver -v bootp -p udp -a 
#chubserver -v tftpd  -p udp -a
#refresh -s inetd

   Also, ensure NFS group related services are  also enabled.

#startsrc -g nfs

Important Directories and Files

   a) /tftpboot

     When we create SPOT, kernel is copied into /tftpboot directory . All kernles of NIM clients are in the direcotry

root@aixnim1: /etc # ls -l /tftpboot
lrwxrwxrwx    1 root     system           34 Dec 19 18:36 aix21.domain.com -> /tftpboot/spot_5200-08.chrp.mp.ent
-rw-r--r--    1 root     system         1276 Dec 19 18:36 aix21.domain.com.info
-rw-r--r--    1 root     system      9379964 Dec  8 15:31 spot_5200-08.chrp.64.ent
-rw-r--r--    1 root     system      9260943 Dec  8 15:31 spot_5200-08.chrp.mp.ent

   b) /etc/bootptab

      File which authenticate nim client for remote boot up for nim operations like bos installation, restoration & maintenance boot. Based on the NIM operation, nim client info update and once the NIM operation completed, entry also removed automatically from this file.

      In simple words, authenticates NIM client for remote boot up.

#tail /etc/bootptab

aix21.domain.com:bf=/tftpboot/aix21.domain.com:ip=10.200.50.56:ht=ethernet:sa=50.20.100.48:gw=10.200.50.1:sm=255.255.255.0:

The fields are separated with colon (:) and attributes are separated with equal sign (=):

    first field  - NIM client name

           bf       - boot file name

           ip       - NIM client IP address

           ht       - hardware type

          sa       - TFTP server address for the boot file

          gw      - gateway used by client to reach the server

          sm      - subnet mask for the nim client

  c) /etc/niminfo

       The file always exists on the NIM master and client. contains information about who is master and client, port no, protocol informations.

        This is automatically generated when master was created and client was registered to master. This file was not manually edited. If any corrupted, want to be removed and recreated.

 1)Rebuild on Master

        #nimconfig -r

 2)Rebuild on Client

        #nimint -a master=<MASTER_HOSTNAME> -a name=<CLIENT_NIM_NAME>

Filesets Required

   bos.sysmgt.nim.master

   bos.sysmgt.nim.spot

Useful NIM Basics Link

http://www.youtube.com/watch?v=UBbhoSUnCwE

Lesson-4 Object Data Manager (ODM)

What is ODM ?

• ODM – Object Data Manager  is the database for storing system information.
• Physical and logical devices  information are stored and  maintained as objects in ODM.
• It is in binary format hence can't view or edit.
• Whenever we add, delete and configure the devices in OS, the entries will be added in ODM

System Data Managed by  ODM

1) Device Configuration information (Predefined and Customized Devices )

2) Software Vital Product Data (SVPD)

3) System Resource Controller

4) TCP/IP configuration information

5) SMIT menus and commands

6) NIM  information

7) Error Log and dump information.

  

Data Not Managed by ODM

            The Filesystem information, User/Security information and  Queues & its devices are not manged by ODM.

How ODM is compared with Rational Database?

            ODM  is more or less similar  to  Relational Database.

1. Object Class is equivalent  to the database file.

2. Objects are  equivalent are to the row of the database.

3. Object descriptors are equivalent to the column of the database

                   OC   --  datafiles

                     O   --  records

                    OD  --  fields 

Where the ODMDIR environment variable declared?

            ODMDIR environment variable is declared  in /etc/environment. The default ODMDIR variable is /etc/objrepos. 

Types of ODM Components & Commands associated with them

            ODM have 3 components, they are Object Classes, Objects and Descriptors

 

 Object Classes: (odmcreate, odmdrop)

            The ODM contains many database files.  Each file is called  Object Class.

            Commands Used

            #odmcreate desc_file.cre  (Create ODM class file)

            #odmdrop -o desc_file.cre (Delete entire ODM class)

Objects:  (odmadd,odmdelete,odmget,odmchange)

            Each  object class contains of  objects. Each object is one record in an object class

            Commands Used

            #odmget -q name=hdisk0  CuDv

                        The above command is used to display the object  hdisk0 in the CuDV

          #odmdelete –o CuDv –q name=hdisk0

                        The above command is used to delete the specified object hdisk0 in ODMe

           

Descriptors: (odmshow)

            It describes layout of the object. They determine the name and datatype of the fields that are part of the object classes.

            #odmshow  object_class_name

            #odmshow PdDv

            #odmshow CuDv

Device Configuration Summary

What are Device Database aka Object Class files?

            There are 2 important  device database or Object class files are there in ODM, they are Predefined device and Customized  device

 

1. Predefined device information describes all supported devices.  (PdDv,PdAt,PdCn). If  the device to be configured, it must be the part of  PdDv class, it is not possible to configure a device without defined in the corresponding Pd classes.

2. Customized device information describes all  the devices that are attached to the system. (CuDv, CuAt, CuDep, CuDvDr, CuVPD, Config_Rules). If the device is in defined state, it should have entry in CuDv.

 

What are the states of  devices in the  ODM?

            There are 2 important states of devices in the ODM, they are  Defined and Available

    Defined State  (device status will be 0 )

•  If a device is in the defined state there is an entry in ODM class CuDv.
• A device can be either defined by cfgmgr or mkdev command . Both methods use “define method” (cfgmgr) to generate instance in the class CuDv. 
•  Suppose that installed device is removed from server or hdd has failed. This case that device is moved to defined state. i.e. that device configuration is available in server but currently device is not accessible.

           

    Available State (device status will be 1)

•  When the device is in available, the device driver has been loaded and special device file is configured under  /dev  directory and the device is ready for accessible. 
•   The "configure method" is used to load the device driver and add an entry in the /dev directory

 In addition to the above the following state also availble                     

     Undefined

    The device is supported device but not configured. Devices reside in the Predefined Database  not customized database.

Note

        The difference between Defined and Available state is that no device driver loaded into the kernel.

What are the commands used to get device informations?

• lsdev command  to get information about PdDv and CuDv. 
• lsattr command  to get information about PdAt and CuAt.  

 SWVPD (Software Vital Product Data)

• VPD is the Vital Product data which is the subset of ODM. 
• Using  lscfg  can find the VPD data of the hardware devices.

   The following are objects of VPD

  

1)      LPP  (Contains information about the product)

2)      Inventory ( contains files associated with s/w product)

3)      Product ( information of the prdt)

4)      History (Historical info about software)

Object Class Repositories

 
     There are 3 repositories, in which ODM  data are stored.

i) /etc/objrepos

• This is the main repository file. Data that is specified to the system is stored. 
• /(root) part of the s/w contains the part of the product that cannot be shared through networks. 
• Customized Devices object classess (CuDv,CuAt)

ii) /usr/lib/objrepos

• Predefined device object classess  (PdDv.PdAt) 
• Platform specific data that can be shared across the network.
• SMIT menu objectclasses and /usr part of the SWVPD. 
• The four object classes used by SWVPD for the /usr part of installable s/w prdt sofw installed in /usr part can be  shared among the h/w arch

iii) /usr/share/lib/objrepos

• /usr/share part of the SWVPD (history, inventory,lpp,product). 
• Platform independent data can be shared across the systems.