wiki

Ce document décrit les bases de l’AIX et notamment un certain nombre de fonctionnalités utiles. L’AIX est un UNIX un peu particulier car il possède une base de donnée propre contenant les informations du volume manager AIX, des devices … Pour les interventions particulières sur des serveurs AIX pensez à utiliser smitty, car c’est votre ami ; il connaît bien les commandes et évite les erreurs.

Le « System Management Interface Tool » est un utilitaire AIX permettant de simplifier l’administration de serveurs AIX.

L’installation d’un serveur AIX peut se faire de différentes manières :

-	cdrom
-	mksysb sur tape , CD ou DVD bootable : possiblité shrink FS (réduction)
-	server NIM
-	install depuis 1 OS preinstallé sur autre disk
+ serveur nim
+ clone
+ altinst restore mksysb
-	upgrade d’1 clone depuis NIM

Au démarrage du serveur AIX, il faut presser la touche <1> ( ou <F1> sur un écran graphique) , après que le mot keyboard apparaît. Ceci permet d’entrer dans le mode SMS pour modifier la bootlist permettant l’installation.

Le volume manager AIX permet de virtualiser les disques de façon à s’affranchir d’un partitionnement souvent fastidieux à maintenir et offre beaucoup de soupplesse au sytème.

C’est l’élement de base permetant de stocker les donnée : le disque.

lsdev –Cc disk : permet de visualiser les devices disk présents sur le serveur
lspv : permet de lister les volumes disques disponibles
chdev –l hdisk<i> -a pv=yes : attribue un PVID au disk hdisk<i>, pv=clear pour l’opération inverse

L’AIX possède de base un volume manager, obligatoire pour le système (rootvg), permettant de s’affranchir des disques physiques. On peut créer d’autres volume group contenant au minimum un dique. Il est possible à tout moment d’ajouter un disque dans un VG ou d’en retirer un de manière dynamique (extendvg , reducevg). Pour garantir des perfomances correctes, on évite en général de mélanger dans un VG des disk de technologie différente, mais cela reste possible. Il existe différents types de VG :

1. les VG standard
2. les Big VG apparus en AIX 4.3.1
3. les Scalables VG pour AIX 5.3 et plus

Pour créer un VG il faut au minimum un physical volum PV, et ce disque sera découpé en physical partition (PP) qui est l’incrément utilisé lors de la création de Logical Volum (LV). Il est donc nécessaire de choisir la taille des PP de manière optimale, en sachant que pour un VG standard on ne peut pas dépasser 1016 PP par PV. Ex : PP = 8M , 1016*8 = 8128MB (il ne faut pas de disque plus garnd que 8128MB dans le VG.) Il est possible de changer cette limite de 1016PP par PV, en utilisant un facteur puissance 2, cela réduit d’autant le nombre de PV par VG.

[testu57@garde] /home/garde> lsvg testvg
VOLUME GROUP:       	testvg                   	VG IDENTIFIER:  	00cea7cd00004c0000000109f4687988
VG STATE:           		active                   	PP SIZE:        	64 megabyte(s)
VG PERMISSION:      	read/write               	TOTAL PPs:      	544 (34816 megabytes)
MAX LVs:            		256                     	 FREE PPs:       	544 (34816 megabytes)
LVs:                		0                        	USED PPs:       	0 (0 megabytes)
OPEN LVs:           		0                        	QUORUM:         	2
TOTAL PVs:          		1                        	VG DESCRIPTORS: 	2
STALE PVs:         		0                       	STALE PPs:      	0
ACTIVE PVs:        		1                        	AUTO ON:        	yes
MAX PPs per VG:     		32512                                     
MAX PPs per PV:     		1016                     	MAX PVs:        	32
LTG size (Dynamic): 		256 kilobyte(s)          	AUTO SYNC:      	no
HOT SPARE:          		no                       	BB POLICY:      	relocatable 
[testu57@garde] /home/garde>   chvg -t2 testvg
0516-1164 chvg: Volume group testvg changed.  With given characteristics testvg
        can include upto 16 physical volumes with 2032 physical partitions each.
[testu57@garde] /home/garde> lsvg testvg    
VOLUME GROUP:      	testvg                   	VG IDENTIFIER:  	00cea7cd00004c0000000109f4687988
VG STATE:           		active                  	PP SIZE:        	64 megabyte(s)
VG PERMISSION:      	read/write               	TOTAL PPs:      	544 (34816 megabytes)
MAX LVs:            		256                      	FREE PPs:       	544 (34816 megabytes)
LVs:               		0                        	USED PPs:       	0 (0 megabytes)
OPEN LVs:           		0                        	QUORUM:         	2
TOTAL PVs:          		1                        	VG DESCRIPTORS: 	2
STALE PVs:         		0                        	STALE PPs:      	0
ACTIVE PVs:         		1                        	AUTO ON:        	yes
MAX PPs per VG:    		32512                                     
MAX PPs per PV:     		2032                     	MAX PVs:        	16
LTG size (Dynamic): 		256 kilobyte(s)          	AUTO SYNC:      	no
HOT SPARE:         		no                      	BB POLICY:      	relocatable

La LVM AIX supporte le raid 0, 1 et 0+1 (10). Le raid se fait au niveau des LV (mklvcopy), ou plus globalement au niveau des VG (mirrorvg).

lsvg : liste les VG
lsvg  <vg_name> : donne les caractéristiques du VG
lsvg –p <vg_name> : donne l’état des PV composant le VG
lsvg –l <vg_name> : donne la liste des LV du VG
extendvg <vg_name> hdisk<i> : ajoute un disque au VG
reducevg <vg_name> hdisk<i> : enlève un disque au VG s’il ne contient plus de donner. Il est possible de forcer le retrait, mais c’est à manipuler avec
                              prudence

Pour créer un mirroir entre plusieurs disques, ces derniers doivent tous appartenir au même VG. Alors que Linux créé un raid et y place un volume group dessus, AIX créé un volum group, et mirror les logical volumes contenu dans ce VG.

mirrorvg –S <vg_name> hdisk<dest> : créé un miror sur le ou les disques de destination (3 copies maximum), la source n’a pas besoin d’être précisée
unmirrorvg  <vg_name>  hdisk<dest> : casse le mirroir de hdisk<dest>
mklvcopy <lv_name> <nbr_copies> [<disk_dest>] : créé une copie d’un logical volume
rmlvcopy <lv_name> <nbr_copies> [<disk_dest>] : supprime des copies de LV

Attention lors de l’ajout d’un LV, il faut le créé avec plusieurs copies, si le VG est mirroré, cela n’est pas automatique.

NB : cas particulier d’un miroir avec un rootvg :

extendvg rootvg hdisk<copie2>		met le second disque dans le rootvg
mirrorvg –S rootvg hdisk<copie2>		mirror le rootvg sur le second disque
bosboot –ad hdisk<copie1>	recréé le secteur de boot pour rendre les 2 disques bootables
bosboot –ad hdisk<copie2>	recréé le secteur de boot pour rendre les 2 disques bootables
bootlist –m normal  hdisk<copie1>  hdisk<copie2>	modifie la bootlist pour pouvoir démarrer sur les 2 disques 

Ces opérations ne sont pas valables pour le rootvg. On peut désactiver un VG pour supprimer des disques par exemple, ou bien pour réalouer le VG à un autre serveur. Pour cela tous les filesystems du VG doivent être démontés.

varyoffvg <vg_name> 
varyonvg <vg_name>

L’export d’un VG nécessite que le VG soit vayoff, il supprime toutes les entrées du VG et des FS sur le serveur. Cela n’efface pas les données sur les disques. L’import d’un VG permet de récupérer des disques d’un autre serveur dont le VG a été désactivé préalablement.

exportvg <vg_name>
importvg  –y <vg_name> hdisk<i> : ou hdisk<i> est un des disques du VG

Rq : - Ceci est la seule façon de renommer un VG
- attention à ne pas activer un VG sur 2 serveurs en même temps, cela provoquerai un accès concurrent, qui n’est supporté que en HACMP ou GPFS.

Il est possible de casser une copie mirror afin d’en fait un snapshot : c’est une copie intégrale des données, par simple arrêt de la synchronisation entre les 2 copies mirroir. Ce snapshot peut-être soit monté en local ou sur un serveur distant afin d’effectuer un backup. Le retour en arrière se fait par un resynchronisation de la copie mirror. splitvg , joinvg, recreatevg

[testu21@root] /root> lsvg -p testvg
testvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdiskpower0       active            78          37          06..00..00..15..16
hdiskpower1       snapshotpv        46          5           00..00..00..00..05

Il est aussi possible de figer une copie d’un logical volume et le monter directement sur un nouveau filesystem :

[root@nim]/root > chfs -a splitcopy=/newfs_home /home

aussi possible de figer une copie d’un logical volume et le monter directement sur un nouveau filesystem

[root@nim]/root > chfs -a splitcopy=/ newfs_home -a copy=1 /home

Il existe des snapshot pour un filesystem (cf filesystem)

Il est possible de déplacer des données sur un PV (chlv –a <position> <lv_name>) et même de manière plus fine en précisant le bloc disque de destination, mais cela n’est plus très utilisé vu la performance des disques actuels. La seconde methode permet un déplacement sur des disques différents :

migratepv  hdisk<src>  hdisk<dest> : l’option  –l  permet de déplacer un seul LV 

Le logical volum est l’enveloppe permettant de stocker des données dans un VG. Les LV peuvent contenir directement des données (RAW devices : type hd6 , swap), ou contenir des filesystèmes (FS). Les LV peuvent être agrandis ou réduits (extendlv, reducelv), mais pour les LV contenant des FS, il faut éviter cette méthode, car un changement de taille d’un filesystem change automatiquement la taille de l’enveloppe (LV), alors que l’inverse n’est pas vrai.
Chaque LV est créé dans un VG et possède un nom unique. On peut préciser le type (jfs , jfs2, sysdump…), éventuellement un PV ou même un emplacement sur le PV (pour de meilleures performances), le nombre de copies pour des mirroirs (max 3), le stripe size…
Chaque LV contient par défaut un nombre maximum de PP (limite soft), afin d’éviter de créer des LV trop grand ; cette limite est facilement modifiable :

chlv –x <nbr_PP_max> <lv_name> 
chlv –n <new_lv_name> <lv_name> : renomme un LV
lslv <lv_name> : permet de lister les caratéristiques du LV
lslv –l <lv_name> : donne les disques physiques utilisés par le LV

Ils sont de différents types :

1. jfs : filesystem standard Aix pour les versions avant AIX 5.1
2. jfs2 : ou encore Enhanced journaled file system, très performants, non supporté sur un rootvg avec un kernel 32bits
3. nfs : network filesystem
4. cdrom : comme son nom l’indique, permet de monter des CD en read-only

Lors de la création d’un FS, AIX créé le point de montage et ajoute une entrée automatiquement dans /etc/filesystems

chfs –a size=<new_size> <fs_name> : modifie la taille d’un FS. La taille est soit en bloc de 512, ou en K,M,T,P, et il est possible de soit donner la taille définitive, soit augmenter avec + ou diminuer avec – (supporté en AIX 5.3 et plus).
chfs –m <new_name> <fs_name> : renomme un FS
lsfs –a : liste les filesystems contenus dans /etc/filesystems

Pour effectuer un export NFS d’un répertoire : Il faut activer les demons nfs : startsrc –g nfs Mettre les répertoires à exporter avec les attributs nécessaires dans /etc/exports , et lancer exportfs –va qui va valider l’export pour le mettre dans /etc/xtab.

[testu57@garde] /home/garde> cat /etc/exports
/mksysb                                 -rw,root=testu18:testu21
/export/lpp_source/lpp_source530        -ro,root=nim_client64:,access=nim_client64:
/export/spot/spot530/usr                -ro,root=nim_client64:,access=nim_client64:
/export/bosinst_data/bosinst.AIX530     -ro,root=nim_client64:,access=nim_client64:
/export/nim/scripts/nim_client64.script -ro,root=nim_client64:,access=nim_client64:

Pour monter un FS NFS, il est préférable d’utiliser l’option soft plutôt que l’option hard de montage par défaut, sinon en cas de soucis réseau, le FS NFS devient indémontable.

Ex : mount –o soft testu23:/delivery /mnt

Il est possible d’effectuer un snapshot d’un filestem de type jfs2 uniquement. Le snapshot créé doit avoir une taille suffisante pour stocker les données qui seront modifiées sur la source durant un laps de temps. Ce snapshot est quasi immédiat, car une image instantanée est prise et chaque bloc modifié sur la source (et seulement cela) est préalablement copié vers la destination. On peut monter un snapshot, mais il n’est accessible qu’en read-only. Il est possible d’effectuer plusieurs snapshots simultannés, alors seul le dernier est actif. Dans ce cas, on ne peut pas supprimer le dernier snapshot sans effecter le précédant…Les snapshots sont alors chaînés et il faut le denier pour reconstituer le premier. En revanche le premier peut être supprimé sans incidence sur le dernier.

Ex :

snapshot -o snapfrom=/volumes/space1 -o size=2000M
snapshot -q /volumes/space1
mount -o snapshot /dev/fslv02 /fs/fs/volumes/space1
snapshot –d <lv_snap_name> : supprime le snapshot

En AIX les devices sont définis dans la base ODM. Cette base n’est pas accessible facilement pour des raisons de sécurité.

lsdev –C : liste tous les devices de la machine
lsdev –Cc adapter : pour les cartes PCI
lsdev –Cc disk ; lsdev –Cc tape ….
lsdev –Cc if : liste les interfaces réseau
lsslot –c slot  ou lsslot –c pci : donne l’emplacement physique des cartes dans un serveur

Ex :

[testu56@garde] /home/garde> lsdev -Cc disk
hdisk0      Available 04-08-00-3,0 16 Bit LVD SCSI Disk Drive
hdisk1      Available 04-08-00-4,0 16 Bit LVD SCSI Disk Drive
hdisk2      Available 0C-08-02     EMC Symmetrix FCP Raid1
hdisk3      Available 0C-08-02     EMC Symmetrix FCP Raid1
hdiskpower0 Available 07-08-02     PowerPath Device
[testu56@garde] /home/garde> lsdev -Cc adapter
ent0      Available 05-08 2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)
ent1      Available 05-09 2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)
fcs0      Available 0C-08 FC Adapter
fcs1      Available 07-08 FC Adapter
fcs2      Available 08-08 FC Adapter
sisscsia0 Available 04-08 PCI-X Ultra320 SCSI Adapter
vsa0      Available       LPAR Virtual Serial Adapter
[testu56@garde] /home/garde> lsslot -c slot
# Slot                    Description       Device(s)
U7311.D20.659E55A-P1-C06  Logical I/O Slot  pci8 fcs2 
U7879.001.DQD19AP-P1-C1   Logical I/O Slot  pci7 fcs1 
U7879.001.DQD1BHA-P1-C4   Logical I/O Slot  pci12 fcs0 
U7879.001.DQD19AP-P1-T6   Logical I/O Slot  pci5 ent0 ent1 
U7879.001.DQD19AP-P1-T14  Logical I/O Slot  pci4 sisscsia0 
U9117.570.65EA7CD-V2-C0   Virtual I/O Slot  vsa0

Le disk hdisk2 est sur la carte FC fcs0 qui se trouve dans le slot PCI du serveur dans l’IO drawer n° DQD1BHA à l’emplacement P1-C4

lsattr –El <device_name> : donne les attributs des devices
chdev –l <device_name>  -a <parameter>=<value> : permet de modifier des paramètres, il faut parfois désactiver le device fils pour modifier le père.
rmdev –l <dev_name> : passe le device de l’état available vers defined, il est possible d’utiliser l’option -R récurcif
rmdev –dl <dev_name> : supprime le device (-R)
mkdev –l <dev_name> : remet un device available

En AIX on utilise pas la commande mkdev pour créer un device, mais cfgmgr. Cette commande configure tous les devices présents sur le serveur.

lscfg –vp : liste les caractéristiques du serveur : serial number, firmware, mac adresses, WWN… L’option –l permet de spécifier un device en particulier. Cette commande est plus complète que prtconf –v 
lsmcode –A : liste tous les éléments possédant un firmware

Particularité des devices réseaux et FC Les cartes réseaux ent<x> sont utilisées avec une émulation ethernet standard en<x>, l’émulation et<x> n’est jamais à utiliser (ancien protocole US). Les cartes FC fcs<x> ont une emulation SCSI fscsi<x> , et une autre pour des protocoles éthernet fcnet<x>. Tous les devices de même type ont un nom identique, avec un incrément. Attention lors des installations en mode automatique car le 1° disk scanné sera le disk d’installation, peu importe qu’il soit sur des disques SCSI ou fibre. Ex : 1° disk de la machine qui est scanné sera toujours hdisk1, puis hdisk2…

Détermination des drivers utilisés par des devices

[wnru03] root /root> lsdev -C -Ftype,name | grep fcs
df1000f9,fcs0
df1000f9,fcs1
[wnru03] root /root> lsdev -C -Ftype,name | grep ent
1410ff01,ent0
1410ff01,ent1
ibm_ech,ent2
[wnru03] root /root> lslpp -l | grep df1000f9
  devices.pci.df1000f9.diag
  devices.pci.df1000f9.rte  5.2.0.75  COMMITTED  64-bit PCI FC Adapter Device
[wnru03] root /root> lslpp -l | grep 1410ff01
  devices.pci.1410ff01.diag
  devices.pci.1410ff01.rte  5.2.0.85  COMMITTED  10/100 Mbps Ethernet PCI
  devices.pci.1410ff01.rte  5.2.0.30  COMMITTED  10/100 Mbps Ethernet PCI

  - TL (technology level) : c’est un ensemble de packages offrant de nouvelles fonctionnalités software avec un support pour du nouveau harware, ainsi que des 
    correctifs. Anciennement appelé maintenance level (ML), le TL ne parait que 2 fois par an et nécessite d’être installé de façon complète (contrairement au 
    ML). C’est un niveau stable.
    oslevel -r
  - SP (service pack) : il fournit un niveau intermédiaire au TL. Apporte des correctifs de securités et critiques. (disponibles tous les 6-8 semaines)
    oslevel –s

Il existe un SP appelé Concluding Service Pack (CSP), qui est le dernier avant un nouveau Technology Level (abandonné).

  - APAR : correctif pour un problème déterminé, composé de 1 ou plusieurs filesets. Les niveau précédents sont composés de plusieurs APARSs
    instfix –i 
  - Fileset : package de base en AIX (ou encore ptf, si c’est une mise à jour)
    lslpp –l 
  - Bundle : ensemble de packages regroupant une application particulière Ex : X11

oslevel –r/s –l <level> : donne les packages manquants pour atteindre un SP ou TL
instfix –ci ¦ grep :- :     : donne l’ensemble des APAR incomplets (y compris SP et TL)
lslpp –f <fileset> : liste les fichiers contenus dans le fileset
lslpp –w <command> : donne le fileset contenant la commande ou fichier

En AIX, on peut mettre l’ensemble des packages ci-dessus dans un répertoire et le système gère les dépendances et met à jour tout ce qui est possible. On peut créer le fichier .toc par : inutoc . , afin de créer la « table of content ». Smitty créé automatiquement ce fichier s’il n’est pas présent dans le répertoire des packages d’installation. Pour les mises à jour, on peut upgrader un système online, tant que l’on ne change pas de niveau majeur (oslevel). Sinon on procède à une migration du système, qui se fait offline, en bootant sur CD ou NIM.

On a la possibilité d’upgrader l’AIX : smitty update_all

- INPUT device / directory for software . * SOFTWARE to update _update_all

PREVIEW only? (update operation will NOT occur)     	no
COMMIT software updates?                            		yes                                     
SAVE replaced files?                                			no                             
AUTOMATICALLY install requisite software?           	yes                  
EXTEND file systems if space needed?                		yes                  
VERIFY install and check file sizes?                		no                   
DETAILED output?                                    			no                
Process multiple volumes?                           		yes              
ACCEPT new license agreements?                      		no                           
Preview new LICENSE agreements?                     		no                   
                 

On peut appliquer simplement les mises à jour sans les valider définitivement en mode APPLIED, contrairement au mode COMMIT par défaut. Ceci permet un retour en arrière de façon propre en cas de problème. Il n’est pas conseillé d’abuser de ce mode de façon permanente, car cela consomme de l’espace dans /usr. Le filesystem /usr est agrandi automatiquement par défaut pour les installations. L’option ACCEPT license agrement est nécessaire pour openssh, java… lppchk –v : détecte les corruptions de filesets. L’option –c est plus précise encore (checksum)

lssrc –a : liste tous les démons AIX
lssrc –s <démon>
lssrc –ls <démon> : vue détaillée d’un démon
lssrc –g <group_démons>
startsrc –s/g <démons> : démarre un démon
stopsrc –s/g <démon> : stoppe un démon

AIX est un UNIX particulier possédant une base de données interne, ceci empèche d’effectuer un backup système au moyen d’une commande tar.

Un backup système se décompose en 4 parties : - image de boot dans le prmier secteur, créé avec la commande bosboot - 2 fichiers de définition du système : o Image.data que l’on peut créér avec la commande mkszfile : contient la structure des LV et FS du rootvg o Bosinst.data permettant d’automatiser l’installation (disk de boot , console, langages…) une copie de ce fichier est dans /var/adm/ras/bosinst.data - table of content - données au format backup (backup –xvf)

Les backup système sur disques ne sont pas bootables, contrairement aux mksysb sur tape ou CD/DVD. La commande : mksysb –e –i <dev_name> le device name peut être un nom de fichier ou un nom de device. Le fichier /etc/exclude.rootvg (syntaxe : /mnt/ ) permet d’exclure des données du rootvg. Le mksysb ne contiendra pas les filesystèmes non montés, ni les raw devices (logical volumes sans point de montage). En cas de restauration il est possible de customizer les fichiers bosinst.data, et image.data, afin de réinstaller le système dans un minimum de place (Ex shrink=yes)

savevg –f <dev_name> -i –e : effectue un backup complet d’un volume group au format backup / restore, ainsi que la structure du VG. Il est possible d’exclure des données en créant un fichier /etc/exclude.<vg_name>

Depuis l’ AIX4.3.3 il est possible de créer un second disque (voir plus) bootable. Ce sera un « alternate rootvg ». On peut soit cloner un disque existant, pour cela il faut un disque non utilisé, soit restaurer un mksysb d’un autre système si un backup a été fait dans un fichier :

alt_disk_install –C <disk_destination> : clone le rootvg existant sur le disque de destination
alt_disk_install –d <file_mksysb>  <disk_destination> : restore le mksysb sur le disque de destination
alt_disk_install –W : activer le clone (wake-up)
alt_disk_install –S : desactiver le clone (sleep) 
alt_disk_install –X : supprimer le clone

Les options –i : image_data et –e : exclude sont admises pour modifier la strucure du rootvg ou exclude des répertoires ou fichier du clone. En AIX 5.3 cette commande a été séparée en 3 commande :

alt_disk_copy -d <disk_destination> 
alt_disk_mksysb -d <disk_destination>  -m <mksysb_file>
alt_rootvg_op : opérations sur un alternate rootvg

Les options sont : -S : sleep -X : delete -C :customize, avec la possibilité d’ajouter des filesets, d’upgrader l’image… [-I installp_flags] [-l images_location] [-f fix_bundle] [-F fixes] [-w filesets] [-DV] -W –t : active l’image et reconstruit son boot logical volum (hd5)

Pour être à même de booter sur une image ou une autre il suffit de modifier la bootlist: bootlist –m normal <hdiskx> et bootlist –m normal –o pour la lister

Avec le nouvel utilitaire multibos pour AIX il est possible d’avoir 2 images bootables sur un même disque. A tout moment il est possible de supprimer une image inactive, de la mettre à jour…

multibos –Xs : créé une seconde image sur le même disk

Les filesystemes / , /usr , /var et /opt sont clonés par défaut et on peut en ajouter d’autres avec –L , ou bien encore définir une nouvelle structure avec –i (image.data)

multibos –Xm : mount des FS 
multibos –Xu : umount des FS
multibos –RX : delete de l’image inactive (que ce soit l’originale ou la copie)
multibos -Xac -l /update : ugrade les filesets avec les packages dans /update
multibos –S : effectue un chroot et ouvre un shell

Pour pouvoir booter sur une image ou une autre il faut modifier la boot list :

bootlist –m normal hdisk0 blv=bos_hd5 hdisk0 blv=hd5

Workload manager est un outil installé de base depuis AIX 4.3.3. Celui-ci permet de gérer les ressources d’un OS de façon optimale. On peut créer des classes, qui sont définies d’après leur user, leur group, l’application, le type d’application… Ces classes permettent de donner une plage d’utilisation (rules) CPU, mémoire, IO disk en pourcentage, et un nombre maximum de logins, threads, processes. On peut changer dynamiquement chaque valeur et stopper ou démarrer workload manager sans incidence. Rq : en power5 il existe un workload manager capable de gérer dynamiquement l’allocation de ressources entre partitions : PLM (Partition Load Manager)

L’ODM est une database propre à l’AIX. On ne doit pas la modifier ou l’éditer, même si c’est possible. Elle se situe dans le répertoire /etc/objrepos et on peut lister les principaux composants par : odmget CuAt