micro partitioning.

we are distributing the processing capability of one or more physical processor among the partitions

using micro partitioning we can increase the overall utilization of processor resources within the system.


suppose we are having   4 processors  i.e. 4 processing units(PU) and we are having four partitions.you have assigned 1PU to all partitions.you  find that on all the partitions about 50% of processor is un-utilized  now .you want to create some more partitions . options are

1.that you have to add more processors to the server  that will add extra cost or burden to ur's firm.or

2.  you can free some processing units from all the lpar's as they are only 50% utilized atmost. this you can do by DLPAR operation through HMC ,if you don't want to reboot.

you can re-assign the processors according to ur's need :here i have reassigned the processing units so, that i can utilize those processor more efficiently and assign the freed PU to the new partitions that i want to create..

lpar1      minimum  .1      desired .3        maximum. .5
lpar 2     minimum .1       desired .2         maximum .3
lpar3      minimum .1       desired .4         maximum .6
lpar4      minimum .1       desired .3         maximum. .6


PROCESSING UNITS(PU) -  the capability of assigning less than 1 processor to a partition is call ed micro-partitioning.
                          for allocating less than 1 processor ,we use processing units(PU)

1 processor corresponds to  1 PU

** we can assign minimun of 1/10 i.e. 0.1 PU to a  partition.
** minimum granuality for assigning extra PU is .01

what is minimum,desired and maximum ?

minimum --  partition will not start if this much PU is not available
desired------  partition will use this much of PU ,if available
maximum ---  partition can be increased to this amount if using Dlpar.

here click to "advanced"

what is capped and uncapped?

capped---processing capability can never exceed the entitled (assigned) processing capability of partition.

uncapped --  the processing capability can exceed the entitled capacity when resources are available in there shared -processor pool and the partition is eligible to run.

* higher the uncapped weight of partition the more processing units it will receive.
* uncapped weight ranges between 0 to 255. default is 128.

power hypervisor

power hypervisor is the firmware layer sitting between the   hosted operating system and the server hardware.

suppose you are having p570 box in which you have created 4 Logical Partitions. you have assigned logical resources to  each of them. power hypervisor keeps track of the resources allocated to each partition and also take care that partitions don't access the other partition's assigned resources .

**power hypervisor enforces partition integrity by providing security layer between logical partitions.

** it provides VLAN channel between logical partitions that helps to reduce the need of physical ethernet adapter.


** it also monitors the service processor.if there is any loss of SP it will perform reset/reload operation.if it is not corrected it will notify the operating system.

power hypervisor provides following types of virtual I/O adapters.
  1. virtual scsi
   2. virtual ethernet
   3. virtual FC
  4. virtual console

what is virtual scsi?
for virtualization of storage,power hypervisor gives you virtual scsi mechanism.

virtual scsi adapter is needed for this which is defined in vio server partition.


there are two types of virtual scsi adapter
 virtual client scsi adapter
 virtual server scsi adapter

 all the scsi physical storage devices are assigned  to vio server.

how the adapters are connected?

1.using DLPAR operation , you can create  virtual scsi  server adapter if you don't want to reboot the server.
  2.on client partitions also  you define the virtual client scsi adapters. through DLPAR operation. mapping should be correct.

ex. of mapping the adaapters

while defining server adapter, note the following
slot no.  3
remote partition  partition2
remote partition virtual slot number  4

for client adapter
slot no. - 4
remote partition  vios
remote partition slot no.  3

3. after that run#cfgdev on vio server . one virtual host device (vhost) device will be available on vio server that represents that particular partition.

4. you cam map the logical  volume etc  to  a particular partition virtual host device and that will be available as a disk on client partition  after running the #cfgmgr command on that partition.


 vitual scsi can be used as
1. virtual disk
2. virtual optical devices(vtopt)
3. virtual tape.

VIRTUAL ETHERNET

power hypervisor provides a virtual ethernet switch function that allows partitions on the same server to use a fast and secure communication without any need of physical intercconnection.

***virtual ethernet is a part of base system configuration and doesn't need vio server.

creating users in company environment

creating a admin user won

# mkuser -a won

assigning the password to user won

#passwd won

it will not prompt for password when user logs in first time.

#pwdadm -c won

removing a disk from user-defined VG

check the activated volume group.

#lsvg -o

rootvg
datavg
quavg

#lsvg -p datavg

vpath12
vpath13

now using the migratepv command migrate all the  filesystem from vpath13 to vapth12

#migratepv vpath13  vpath12


check that any pp is allocated

#lspv -M vpath13 or # lspv -l vpath13


check whether all the filesytems are available

#lsvg -l datavg

now reduce the disk vpath13 from VG

#reducevg vpath13  datavg

now remove the vpath13 .

#rmdev -Rdl vpath13
vpath13 deleted



note: there is no need to unmount the filesystems or varyoff vg while running migratepv command.

SMIT

The System Management Interface Tool (SMIT) provides a menu-driven interface that
provides access to most of the common system management functions within one
consistent environment.
                   SMIT is managed by ODM.It also contains all of the menus, screens and
commands that SMIT uses.


..........Special symbols on the screen are used to indicate how data is to be entered:

*              A required field
#              A numeric value is required for this field.
/               A pathname is required for this field.
X             A hexadecimal value is required for this field.
?              The value entered will not be displayed.
+              A pop-up list or ring is available.


                                                    log files

$HOME/smit.log 
this log files keeps records all the menus and dialog box visited and also all the commands runwith the output.it also records any errors during the SMIT session.




 $HOME/smit.script 
shell script containing all aix commands executed through SMIT.

performance monitoring.

Introduction to service processor

on P -series servers , there is an extra processor known as the service processor.
                             In reality ,service processor is a firmware that is not a part of AIX OS.

The purpose of service processor is to continuously monitor the system from failure and allow for system re-configuration.

funtions of service processors

1.  access the local or remote ASCII terminals.
2.  console mirroring for dual support.
3.remote power on
4.unattended start after power failure

HMC management

introduction to inittab file

differences between aix5.3,aix6.1

aix boot sequence

STEP-1          POST(power on self test)

it's purpose is to verify that the basic hardware is in functional state.
     the memory,communication and audio devices are all initialized.

STEP 2           System ROS (Read only storage)

system ROS is necessary for AIX 5L version 5.3 to boot, but it doesn't built the data structures required for booting.

it will locate the bootstrap code.

system ROS contains generic boot information and is OS independent.

STEP 3             SOFTWARE ROS(also called bootstrap)

Software ROS forms an IPL(initial program load) block ,that takes control and builds AIX5L specific boot information.

A special filesystem called RAMFS filesystem is created in memory.


softwareROS locates and loads Boot logical volume(BLV)in ram.

• contents of BLV

               1. AIX 5L kernel
               2. reduced version of ODM
               3. rc.boot script
               4. boot commands called during boot process like bootinfo,cfgmgr.

AIX 5L kernel is loaded. the kernel will complete the boot process and starts the init process.

  LED =0299

now, rc.boot script will be called three times,and is passed through different parameters each time.


BOOT PHASE 1

Init process started from RAMFS execute the boot script rc.boot1

if init fails LED will display c06

"restbase "command  -- copies partial image of ODM  from BLV to ramfs.

LED =548 if successful

"cfgmgr -f" command

Reads the config-rules class from the reduced ODM.
                                             in this class, devices with attribute phase=1 are considered base devices
base devices are all devices that are necessary to access rootvg.

"bootinfo -b" command

determines the last boot device

LED =511 ,if successful

 BOOT PHASE 2




in this phase,the rc.boot script is passed  with parameter 2.

"ipl-varyonvg rootvg" command

rootvg is activated.

LED =517 ,if sucessfull
LED =552,554 or 556 ,if boot process is halted.

root(/) filesystem (hd4) is checked using  "fsck -f"  to verify whether the filesystem was unmounted clearly before the last shutdown.

/dev/hd4 is temporarly mounted in RAMFS


LED=557,if fails

/user,/var are verified using  " fsck -f"  command and then mounted temporarily
LED =518 ,if /usr fails tomount 

"copycore" command

checks if a dump occurred. if it is copied ffrom default dump device /dev/hd6 to the default copy directory/var/adm/ras/

afterward /var and /usr are unmounted.

the primary paging space from rootvg ,/dev/hd6 is activated.


"mergedev " process is called and all /dev files from REAMFS are copied to disk

All customized ODM files RAMFS are copied to disk.
                                                   both ODM versions from hd4 and hd5 are synchronized.

finally root file system from rootvg is mounted over the original mountpoint from RAMFS.

/var and /usr are also mounted to their mount-point.

BOOT PHASE 3

After boot phase 2, rootvg is activated.

Init process is started . it reads the/etc/inittab file and calls rc.boot with arguement 3
/tmp filesystem is mountd.

"syncvg" command  - rootvg is synchronized . it runs as backgroundprocess. it checks all stale partitions from rootvg and updates it.
LED =553,if successfull.

"cfgmgr" command

if booted in
  normal mode - option is p2
 service boot - option is p3.

it reads the config-rules class from ODM and calls all methods correponding to either phase=2 or phase=3

all other devices ,that are not base devices are configured this time

"cfgcon "command

console is configured by calling the cfgcon command.
     after the configuration of the console,boot messages are sent to the consoleif no STDOUT direction is made.
         all missed messages can be found in /var/adm/ras/conslog


LED C31 - console not yet configured.
        C33 - console is tty.
        C34 - console is a file on disk.

"savebase" command

synchronization of ODM  in BLV wiith the ODM  in root filesystem is done.

syncd daemon and errdaemon are started.
LED display is turned off.

if /etc/nologin exists,it is removed.