AIX is short for Advanced Interactive eXecutive. AIX is the UNIX operating system from IBM for RS/6000, pSeries and the latest p5 & p5+ systems. Currently, it is called "System P". AIX/5L the 5L addition to AIX stands for version 5 and Linux affinity. AIX and RS/6000 was released on the 14th of February, 1990 in London. Currently, the latest release of AIX is version 6. AIX 7 beta will be released in Aug 2010, along with the new POWER7 hardware range.
Multi-platform UNIX systems consultant and administrator in mutualized and virtualized environments
I have 4.5+ years experience in AIX system Administration field. This site will be helpful for system administrator in their day to day activities.Your comments on posts are welcome.This blog is all about IBM AIX Unix flavour. This blog will be used by System admins who will be using AIX in their work life. It can also be used for those newbies who want to get certifications in AIX Administration. This blog will be updated frequently to help the system admins and other new learners. DISCLAIMER: Please note that blog owner takes no responsibility of any kind for any type of data loss or damage by trying any of the command/method mentioned in this blog. You may use the commands/method/scripts on your own responsibility.
If you find something useful, a comment would be appreciated to let other viewers also know that the solution/method work(ed) for you.
1. Find the lpar which is currently holding the cdrom:
Login to the HMC, Select the Managed System and open "Properties", Look for
the I/O device with the description "Other Mass Storage Controller" and read the "Owner" field. This will show the
LPAR currently owning that device.
Login to the HMC Go to lpar (select) Dynamic lpar (select) Physical Adapters (select) Move or remove
Now one box will open, on there you have to select the (cdrom) adapter to remove and provide the destination server details on the "Move to partition" option.
4: Verfication on the target lpar:
Now login to the target lpar and verfiy the cdrom has been moved successfully, with the help of below steps.
#cfgmgr #lsdev -Cc cd0 ("cd0 available" -Here we have to confirm that the cdrom has been moved) #mkdir /cdrom #mount -v cdrfs -o ro /dev/cd0 /cdrom #umount /cdrom
Here I have provided the steps in simplest
way in the Interview perspective. If you are familiar with AIX and NIM,
you can understand the below steps very easily. 1. Need Nim Master server with the 6.1 version --> "oslevel -s" 2. Master having alt_disk package installed --> "lslpp -l bos.alt....' 3. LPP and SPOT should be in high level (OS ver = 6.1) --> "lsnim -c resources" 4. NIMADMVG should create on the NIM master server --> "lsvg -l nimadmvg" 5. Nim master should have the space --> "check space = df -gt" 6. Client needs to define with the master --> "smitty nim" 7. Take mksysb backup of the target client server --> "mksysb" 8. RSH should be working --> "chsubserver -a -v shell -p tcp6 -r inetd" 9. Addtional disk needs to be there --> "lspv" 10. Build /etc/niminfo on the client
server using --> "niminit -a master= -a
name= 11. nimadm –j -c
-s -l -d -Y FYI- The below steps are occurred while we executing the "nimadm" command 11.a) Alt disk created on the target server. 11.b) Cache FS has been created on the Nim server. 11.c) RSH has been enabled. 11.d) System config has been saved. 11.e) Migrating the package (lpp) to the new higher version. 11.f) Post Migration has been checked. 11.g) Boot logical volume has been created. 11.h) Sync the migrated higher version package from NIM server to target server. 11.i) Remove the cache filesystem on the nim server. 11.j) Bootlist has been initiated. 11.k) Clean up process has been initiated. 12. change bootlevel --> "bootlist" and reboot --> shutdown -Fr and confirm --> "oslevel -s" 13. disable the RSH --> "chsubserver -d -v shell -p tcp6 -r inetd"
Using two commands/steps we can easily find out the vhost information of the particular disk.
login to the vio client, and find out the disk's slot number ( for ex: hdisk1) Command:> lscfg|grep hdisk1 Output:> hdisk1 U9133.55A.065040H-V21-C19 Virtual SCSI Server Adapter
login to the vio server and execute the below command to find out the vhost information of the particular disk.
Command:> lsdev -slots|grep C19 Output:> vhost3 Using the above output we can confirm that the vhost3 is assigned to the hdisk1.
New method:
Using
kdb, we can easily trace the vscsi configuration in aix. This command
will save much time when we compare with the old method to do the same. In
the old method, We can find out the slot number (like C13 or C14) of
vscsi in the client server, after that login to the vio server and find
out the appropriate vhost information for the vscsi. #echo "cvai" | kdb | grep vscsi read vscsi_scsi_ptrs OK, ptr = 0x59A03C0 vscsi0 0x000007 0x0000000000 0x0 vios1->vhost8 vscsi1 0x000007 0x0000000000 0x0 vios2->vhost8 Using
above command from the client server to find out the appropriate VHOST
information for our VSCSI and the name of the VIO servers as well.
Method One:
Login to the VIO client and get into the VG and make note of the PVID of
the disk. Now login to the VIO Server and run "lsmap -all | more" and
search the pvid of our VIO Client, now we can able to get the
appropriate vhost name with the corresponding PVID.
Method Two:
As per Target's standard VTD naming convention, VTD name will contain the VIO client name & LUN IDof the disk used for backing device. So we can run a lsmap -all | more and find the VTD with VIO Client we are searching for. Below output shows that vhost3 is the Server SCSI adapter for VIO Client "testmachine"
$ lsmap -all | more
Physloc U7311.D20.067DDBB-P1-C02-T1-L23
VTD esvdevcmsweb-42e
Status Available
LUN 0x9500000000000000
Backing device hdiskpower16
Physloc U7311.D20.067DDBB-P1-C02-T1-L19
In the above output make a note of the third column of the Hardware
location code. C15 & C16, this is referred as Virtual Slot/ Adapter
ID.
* Login to both VIO servers and collect the hardware location codes of all virtual SCSI Server adapters (vhost#)
VIOS 1:
# lsdev -Cc adapter | grep vhost
vhost0 Available Virtual SCSI Server Adapter
vhost1 Available Virtual SCSI Server Adapter
vhost2 Available Virtual SCSI Server Adapter
vhost3 Available Virtual SCSI Server Adapter
vhost4 Available Virtual SCSI Server Adapter
vhost5 Available Virtual SCSI Server Adapter
# lscfg -vl vhost*
vhost5 U9133.55A.065040H-V21-C19 Virtual SCSI Server Adapter
# lsdev -Cc adapter | grep vhost
vhost0 Available Virtual SCSI Server Adapter
vhost1 Available Virtual SCSI Server Adapter
vhost2 Available Virtual SCSI Server Adapter
vhost3 Available Virtual SCSI Server Adapter
vhost4 Available Virtual SCSI Server Adapter
vhost5 Available Virtual SCSI Server Adapter
# lscfg -vl vhost*
vhost5 U9133.55A.065040H-V22-C20 Virtual SCSI Server Adapter
Same as VIO Client, third column of the Hardware location code of vhost
represent the virtual slot in the VIO Server. Usually Devices will be
mapped as per slots. That is, devices at the same slot will be connected
together virtually. So any physical devices (physical disks, logical
volumes, etc) mapped to a Virtual SCSI Server adapeter (vhost) will be
accessible from the Virtual SCSI Client adapter in the same slot.
As per above Example outputs, vscsi0 has same slot as vhost3 of VIOS 1
and vscsi1 has same slot as vhost3 of VIOS 2. So the VIO client's vhost
in VIO servers are, vhost3 in both VIO 1&2.
The
Hardware Management Console (HMC) runs a modified Linux operating
system and system management software. Technical support for the HMC is
provided by IBM's pSeries support center. The HMC is a closed system.
Only IBM-approved software is allowed to run on the HMC. Normal Linux
errata (including security APAR's) should not be installed on the HMC.
Custom configurations and Linux system settings cannot be altered.
Therefore, it is not possible to meet the IBM Security requirements that
are documented in the technical specification for Linux. To ensure
warranty and contract adherence, do not install any non-IBM-approved
software or make any configuration changes that are not documented in
the HMC users guide.
Version 3 is specific to Power 4+ pseries frames, p690, p670, p650, etc
Version 4 is specific to Power 5 pseries frames all p5##.
Security
While
the HMC is considered to be somewhat of a hardware appliance by IBM,
the following security controls have been put into place by the UNIX
support team to ensure the basic security controls as prescribed by
ITCS104 are covered.
HMC Registration and system activation: As
the HMC requires a network connection in most cases for the purpose
of remote pSeries support and hardware management, the HMC should
always be connected to the IBM Blue Zone Intranet. HMC systems should
not be connected to any customer, private, DMZ, or Internet facing
network. The HMC should be registered in the MaD database and scanned
periodically to ensure that network security vulnerabilities are made
known.
HMC Security Fixes:
The IBM pSeries support center releases corrective service and
security advisories periodically. System administrators and HMC users
can subscribe to the IBM Fix Central security advisory center via the
HMC website listed above. The Security Administrator within the
department as long as the HMC expert subscribe to the Advisory mailing
list. Corrective servive and security patches are installed on the
HMC's systems supported by the department as needed. Changes to the
HMC's are tracked using the IBM America's change and problem
management process just like other systems supported by the
department. The CIRATS database is used to keep track of resolvable
security noncompliance issues for the HMC systems.
HMC root and hscroot userid passwords: Are managed via the same process for managing the root password for other systems supported by the department.
HMC through firewalls (via WebSM) uses a number of ports
port 22 for ssh
port 80
port 9090 for initial connection
from 1 to 3 ephemeral ports in the range 1024-65535 for ongoing communication
Note: In the 520 release, we added the capability to change both the initial connect port and the secondary port. If you are using WebSM behind a firewall, you will most likely need to change the secondary port range to be a fixed range.
To set the range for the secondary port, you need to run the comand:
This would make the secondary communication port come from the inclusive range 20000-20010 instead of being a random port.
Changing the secondary port does not affect the initial connection port of 9090. To change the initial connection port, you would have to use the command:
If
you want to change both the initial connection port and the secondary
connection ports, you have to set both with the same wsmserver
command. For example:
One
important thing to remember is that if you change the initial
connection port to be something other than 9090, you need to change
the
way you specify hosts in the WebSM console. When the initial connection port is different, you must specify the hostname as hostname:port. For example:
mysystem:10000
If you just specify the host as 'mysystem', the WebSM client will attempt to connect to port 9090. So it is best to not change the
initial connection port if you don't have to. Just open port 9090 in the firewall so you don't have to give the port number with the host.
So
the best thing to do if you are running WebSM behind a firewall is to
just set the port range with -portstart and -portend and open that
port
range in the firewall along with 9090.
For
HMC, since the WebSM server is a service started under xinetd, the
/etc/xinetd.d/websm file will need to modified to apply the port
configuration settings.
Remote Accessto the HMC via WebSM and SSH is not enabled by default at the time of Install.
At the HMC console login with hscroot and enable both WebSM and SSH by selecting;
HMC Management
HMC Configuration
Customize Network Settings
LAN Adapters tab, select the adapter configured for the Blue Zone / 9. net, for version 4 HMCs this will be eth1 and select Details
Firewall tab select WebSM, Secure Shell and the Allow Incoming button.
Install WebSMon your Windows or UNIX workstation.
Using your web browser of choice (Internet Explorer or Netscape)
Access a HMC using the address format: http://hmchostname/remote_client.html
Replace the above 'hmchostname' with the actual HMC hostname or IP address.
Select WebSM installation of your choice and follow the instructions.
Remote Access via WebSM
Launch the WebSM application.
Enter the FQDN of the HMC followed by the tab key on the Log On Panel.
Allow the handshake to complete before continuing.
Enter your userid userid and password.
The password for the userid 'hscroot' should be the same as our root user standard.
Remote Access via SSH
# ssh -l your_userid@hmchostname/ip/dns entry.
Notes: hscroot password MUST be changed in the gui, command line change does not update the object database.
In our database under the Server By Account view, HMCs are listed with the OS type as Linux and the version as RedHat HMC
All of the typical frame management functions are available through the single HMC desktop or WebSM.
Cross-certify ssh from root@codeman to hscroot@HMC
For automation, we cross-certify ssh from root@codeman to hscroot on each HMC:
On codeman:
mykey=`cat $HOME/.ssh/codeman.pub`
ssh hscroot@YOURHMC mkauthkeys -a \"$mykey\"
respond to the hscroot password prompt
Now ssh from root to hscroot@YOURHMC and it should not prompt you for a password
Set up time sync
chhmc -c xntp -s add -a
hhmc -c xntp -s enable
Web SM / GUI
Login to the HMC at console or with WebSM.
Drill into and right click on the specific Partition and select Open Terminal Window - be patient.
Note: If
the terminal window opens but is not displaying anything like the usual
SMS screens or a login prompt then AIX has locked up like it would when
running out of paging space.
The terminal window will identify which partition it is for in the top bar of the window.
The State and Operator Panel Value (LCD) do indicate the state of the partition on the Server Management screen
Right click the partition, select Operating System / Reset. Be sure you right click the correct partition.
crtl-Ins # cuts in vterm
shft-Ins # pastes in vterm
HMC / SSH
SSH into the HMC using the hscroot userid
# ssh hscroot@hmchostname or ip address
$ /opt/hsc/bin/vtmenu
The tool will retrieve and display a list of the LPARS.
Select the # of the one you need and you will be presented with a console login prompt.
After you exit the LPAR;
~. to close vtmenu, (ends your ssh session into the HMC also)
vtmenu # lists all the lpars select # of the console you want ~. to exit
~. closes Secure IT
~~. closes the conection to the HMC
~~~. closes the terminal to the lpar / returns you to vtmenu
Note: The below is as provided by support but has not been confirmed.
~. above should only kill the vtmenu session
mkvterm -m -p might fix it.
/opt/hsc/bin/query_cecs will return the managed systems
/opt/hsc/bin/query_partition_names -m will return partition names.
In order for dynamic allocation to work you must have network connectivity between the HMC and the LPAR. If
the HMC and the LPAR are separated by a firewall, you must have port
657 open bi-directionally from any effemeral port on either the HMC or
the LPAR. You must also be at AIX level5.2 or greater.
Dynamically Allocate Resources
Log into the HMC at the console or via WebSM
Select Server and Partition - Server Management and select the desired "Running" partition.
Select "Selected" on the tool bar.
If Dynamic Logical Partitioning is grayed out the daemons are not running on the selected LPAR.
Or right mouse button click on the partition name.
If Dynamic Logical Partitioning is not present the daemons are not running on the selected LPAR.
Select Adapters, Processors or Memory
Adjust as needed and select OK.
The Working window should appear and indicate Success when complete in less than a couple of minutes.
If this fails you may need to rmdev the parent and child devices, error text from the above will tell you which parent to rmdev.
You may need to run cfgmgr on the LPAR.
Check the DLPAR Daemons
On the LPAR, start as needed.
# lssrc -a |grep rsct should list
ctrmc rsct 53618 active
IBM.ERRM rsct_rm 97566 active
IBM.ServiceRM rsct_rm 105374 active
IBM.CSMAgentRM rsct_rm 102772 active
IBM.AuditRM rsct_rm 35260 active
IBM.HostRM rsct_rm 58914 active
IBM.DRM rsct_rm 77616 active
ctcas rsct 31122 active
This requires a recovery CD to boot from of the intended version. Current versions must be requested on CD, see the below section Obtain HMC Recovery CDs
You will need to reboot the HMC and have the cd in the HMC so all these steps are at the console.
Login with hscroot at the HMC console and select Licensed Internal Code Maintenance, HMC Code Update, Save Upgrade Data, Hard drive. Allow this to complete.
Place HMC Recovery CD #1 , Exit and select Reboot.
The upgrade panel will come up and ask about a new install or upgrade, F1 - upgrade, F1 a second time.
The upgrade will continue and take several minutes, DVD drive will open and it will reboot when complete.
and there are some more prompts to answer...I'll get them on the next upgrade.
Note: If
the HMC comes up and does not know itself, (hscroot password at the
default abc123, no network, no profiles) and you are sure you did the
"Save Upgrade Data, Hard drive" above then your upgrade suffered a known
problem. You will have to call support to get a temporary
password and tell them the correct / system reported serial number from
the given HMC. On a command line do # lshmc -v and see the SE# line. Support will have you do something like this;
Login as hscroot
Create a hscpe userid and set it's password, same as our root standard works here.
Logout and back in as hscpe
Right the desktop, select Termial, rshterm
# pesh of the hmc as provided to support and returned from the lshmc -v>
# su - (su - root with root's pw)
# mount /mnt/upgrade (look for a doRestore file zero bytes, likely isn't there)
# touch /mnt/upgrade/doRestore (might pay to look for this file before touching.
# shutdown -r now (make sure there is nothing in the DVD drive)
There
will prompts to answer about keeping the NIC config for eth0 and others
if present, be sure to answer these prompts correctly.
This is Corrective Service Installation only if you are upgrading you will need to do the Software Upgrade first
Log into the HMC either at the console or via WebSM and select
v3 Software Maintenance, HMC (note the current version)
v4 Licensed Internal Code Maintenance, HMC Code Update (note the current version), Install Corrective Service
With a writeable DVD in the the HMC's DVD drive select
v3/4 Backup Critical Console Data. This will take a while, just let it complete.
On the same menu, select
v3/4 Save Upgrade Data, and follow prompts to save the data to the hard drive.
Failure to do this step could cause the loss of your Network, Async and Service Agent configuration. This data will be retrieved and reapplied after the upgrade completes.
On the same menu, select
v3/4 Install Corrective Service
Select the radio button Download the corrective service file from a remote system, and then apply the downloaded service file.
Remote site resposity_server
Patch file /inst.images/HMC/v#/maintfile..zip
User ID userid must have ftp read access to the /inst.images/HMC suddirs and files.
Passwordpassword must be valid for the given user.
Note: The above is FTP based and you will not be given any chance to drill into the correct directory or file, so be accurate.
If
you choose the cdrom option you will need to burn the contents of the
.zip file onto a CDRW, do not put the contents of the .zip in a
subdirectory on the CD, you will not be given the option to drill into
the cd.
Select OK.
A working window will appear and you can watch the progress. Successful completion and the need for a reboot should appear.
STOP/READ Version 4.4.2 has 2 update zip files, it is bad mojo to boot between them go back now and do the 0_2 file.
v4 has a update completion panel that allows for a automatic reboot, select the option and OK
To reboot the HMC;
At the HMC console as you exit, the last panel you are presented with by default references Logout, change this to reboot and select ok.
If you are remote, WebSM does not offer any option to reboot, on exit or anywhere in the tool. With SSH enabled you can SSH into the HMC and reboot it.
# ssh -l hscroot@hmchostname
$ hmcshutdown -r -t 1 shutdown
with restart in 1 minute, you will get the command line back and have
the option to exit, the -t option is not required.
$ hmcshutdown -t now -rShutdown and reboot immediately.
$ exit
Frequent Question:
How can I turn off the amber Attention Light in the
operator panel? (I am assuming that you've already
verified that there are no actionable and outstanding
service events.)
Using the HMC: (Recommended)
> Service Applications
> Service Focal Point
> Service Utilities
> Highlight the Managed System name
Selected
System Attention LED
Action
Or; if HMC-less, from the command-line of the LPAR
w/Service Authority
# /usr/lpp/diagnostics/bin/usysfault -s normal
Or; if HMC-less, from the command-line of the LPAR
w/Service Authority
# diag
> Task Selection
> Log Repair Action
> Select sysplanar0
Or; if HMC-less, from the command-line of the LPAR
w/Service Authority
# diag
> Task Selection
> Identify and Attention Indicators
> Set System Attention Indicator to NORMAL
Hardware Configuration
You
may want to create a account specific document to keep track of the
CPU, Memory and Adapter allocation. The WebSM does not provide a single
view of all the hardware. Use this template as a starting point. (1)
Dealing with the GUI
1. To change from GUI login to command line login on the HMC press control alt F1.
2. To get back to the GUI from a command line login type control alt F2.
3. To reboot the HMC from a command line, su to root and type /sbin/reboot.
Collecting LPAR info from the HMC
Typically; access the HMC via a putty session,
turn-on logging of the session to a file and
then copy/paste the code:
for MANAGEDSYS in `lssyscfg -r sys -F type_model*serial_num`
do
echo "============MANAGED SYSTEM --> ${MANAGEDSYS}"
for LPAR in `lssyscfg -r lpar -m ${MANAGEDSYS} -F name`
do
echo " ============LPAR --> ${LPAR} --> CPU resources"
Example 1: To retrieve the HMC Code Level, run the following command:
lshmc -V
Example 2: To retrieve the Managed Systems names, run the following command:
lssyscfg -r sys -F name
Example 3: To retrieve the HMC user profiles available, run the following command:
lshmcusr
Example 4: To retrieve the command usage/help for the lshwinfo HMC command, run the following command:
man lshwinfo
Example 5: To retrieve the current LIC levels for a given Managed System, run the following command:
Note:tttt is the machine type, mmm is the model, and sssssss is the serial number of the managed system. The tttt-mmm*sssssssform must be used if there are multiple managed systems with the same user-defined name.
