How to find out the vscsi configuration from vio client in aix?

How to trace VSCSI Configuration from vio client in AIX?

Execute the below command on the VIO Client (Lpar) to find out the VIOS and VSCSI information.


#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.

Note:

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.

How to upgrade the adapter's firmware level in aix?

Firmware upgrade for adapter in aix?

1. List the fibre channel adapters installed in the system 

lsdev -C | grep fcsX  where fcsX is the adapter you on which you want to install the microcode


2. Determine the current microcode level on the adapter 

lsmcode -d fcsX 


3. Download the Microcode RPM Package and put it into the temporary directory and Unpacking it using the below command.

rpm -ivh --ignoreos <rpm_package>   (If the microcode package unpacks successfully, the microcode file will be added to the /etc/micrococde directory)


4. Update the adapter's microcode level

"diag -d fcsX -T download" 


5. Confirm the current microcode level.

lsmcode -d fcsX

How to upgrade TL and SP in AIX?

 How to upgrade TL and SP in AIX?

1. Ground work:

oslevel -s                                 --> find out the current os level of the system.

instfix –i|grep –i ml                --> check currently installed ML levels are consistent

lppchk –vm3                           --> check currently installed filesets are consistent

df -g                                         --> check the system has the enough free space.

bootlist -m normal -o             --> check the blv has been created on the rootvg disk
emgr -l                                     --> check the installed ifixes/emergency fixes.
emgr -r -L <ifix label>           --> To removing the ifixes / emergency fixes.

Ensure the latest "mksysb" has been taken.

Download the TL/SP package from IBM fix central and put it to nim server

2. Create the alt_disk (Consider we have hdisk0 & hdisk1 on the rootvg)

sysdumpdev –s /dev/sysdumpnull    --> If secondary dump device resides on hdisk1.

rmlv dump_lv                                    --> Remove the dump lv

unmirrorvg rootvg hdisk1                --> unmirrror (Have to use the hdisk1 for alt_disk)

chpv –c hdisk1                                   --> clear the boot image on the hard disk1.

reducevg rootvg hdisk1                    --> remove the hdisk1 from the rootvg disk.

alt_disk_copy -d hdisk1                    --> Take the alt disk clone on hdisk1

lspv                                                     --> confirm the "altinst_rootvg"  created on hdisk1

3. Perform the TL upgrade

smitty commit                                     --> commit all the old applied filesets

installp -s                                            --> check if any os filesets in applied mode

mount <nim_server>:<package holding directory> /mnt  --> mount directory which hold the TL pkg. 

cd /mnt

smitty update_all                               -- > Do the preview first and commit next, once done follow below

oslevel -s                                            --> Check the new TL level.

lppchk -v                                            --> No output should displayed, only the prompt

bootlist -m normal hdisk0             --> Change the bootlist to hdisk0 - remember alt_dsk reside on hdisk1

shutdown -Fr                                      --> for fast reboot.

4. Validation

oslevel –s                                           --> check the new TL level

instfix –i|grep  ML                            --> confirm the new TL level are consistent.

lppchk –v                                           --> No output should displayed, only the prompt

5. Remove the alt_disk and re-mirror

alt_disk_install -X                            --> Remove the alt_disk

extendvg -f rootvg hdisk1                 --> extend the hdisk1 to the rootvg

mirrorvg rootvg hdisk1                    --> To mirror with the hdisk1

bosboot –ad /dev/hdisk1                   --> Create the boot image

bootlist –m normal  hdisk0 hdisk1  --> Set the boot sequence

bootlist –m normal –o                       --> check the boot sequence order

mklv –y <lvname> -t sysdump rootvg <num of LP’s> hdisk1  --> Create the dump lv on hdisk1 if you have removed during the alt disk clone

sysdumpdev –s /dev/<lv name>        --> Create the secondary dump device on hdisk1

sysdumpdev –l                                   --> confirm the dumplv

How to apply ACL (Access Control List) for a file?

What is ACL (Access Control List)?


We all know that by default every file contains permissions for the owner, group and other(world). If we want to set something like read only for 1 user, read/write for a group, read/write/execute for another set of users for a particular file, then We can use ACL.

We can use the below commands to do the ACL for a file.

aclget  - To display ACL for a file

acledit - To edit the ACL for a file

aclput  - To set the ACL for a file using a ACL control file

Few examples,

Let us take file1 as the target file.

To display the current ACL values for file1,

# aclget file1

To edit the ACL for a file,  (How to apply acl for a file)

# acledit file1

This will open a editor with ACL values showing some values like below

attributes: SUID

base permissions:

   owner  (frank): rw-

   group (system): r-x

   others        : ---

extended permissions:

   disabled

If you want to enable and set ACL values, just change the stanza "extended permissions" like below

attributes: SUID

base permissions:

   owner  (frank): rw-

   group (system): r-x

   others        : ---

extended permissions:

enabled

       permit    rw-    u:user1

       deny      r--    u:user2, g:group1

       permit    rw-    g:user3, g:group2

How to perform the VIO Migration using NIM?

How to perform the VIO Migration using NIM? 

The key prerequisites to perform the migration are:

•        The system must be managed by HMC version 7 or later

•        The virtual IO server must be at least at version 1.3.

•        The physical volume for rootvg must be assigned to the VIO

Below steps can be done at anytime before VIOS Migration:

          #mount nim_master:/images /mnt/

          #backupios -file /mnt/<hostname>/`hostname`.mksysb_date -mksysb

          #viosbr -backup –file /mnt/<hostname>/`hostname`.viosbr

          

Take the configuration files like lsmap,lspv,lspath ....for our future reference. 

Create the resource for your VIO on NIM Server

         

          VIOS_MIG_21_lpp          resources       lpp_source

          VIOS_MIG_21_spot         resources       spot

Define the machine using ---> "smitty nim_mkmac"

Prepare the nim master for installaiton ---> "smitty nim_bosinst"

Steps to Migrate the VIOS:

Note: Make sure all the client LPAR related to the VIOS are shutdown.

Step 1: Shutdown the VIOS Partition and Activate the VIOS Partition in SMS mode via HMC.

Step 2: From the SMS menu on the console, follow this procedure:

SMS - SYSTEM MANAGEMENT SERVICES -

1. Select Language
2. Change Password Options
3. View Error Log
4. Setup Remote IPL (RIPL (Remote Initial Program Load))
5. Change SCSI Settings
6. Select Console
7. Select Boot Options


4. Setup Remote IPL (RIPL (Remote Initial Program Load))

Next you’ll have a selection of adapters to use. Select your adapter that corresponds to the adapter/host you defined in NIM. You will not see “ent0/ent1...etc” options. You will however see the hardware addresses and slots.

We then are brought to 3 options :
1. IP Parameters
2. Adapter Configuration
3. Ping Test

Chose the option 1 to set the IP Parameters

Now we need to set our IP Parameters.
1. Client IP Address [###.###.###.###]
2. Server IP Address [###.###.###.###]
3. Gateway IP Address [###.###.###.###]
4. Subnet Mask [###.###.###.###]

After setting the IP Addresses use ‘M’ to return to the main menu. You typically do not want to go into the “Adapter Parameters” (option 2 on the previous screen) to change the adapter parameters or disable spanning tree.

Also, with the Ping Test.... 

With our IP Parameters set we should now be back at the main menu. 

SMS - SYSTEM MANAGEMENT SERVICES - 
1. Select Language 
2. Change Password Options 
3. View Error Log 
4. Setup Remote IPL (RIPL (Remote Initial Program Load)) 
5. Change SCSI Settings 
6. Select Console 
7. Select Boot Options 

Now we’re ready to select our boot device. 
7. Select Boot Options 

The next menu should come up : 
1. Select Install or Boot Device 
2. Configure Boot Device Order 
3. Multiboot Startup 

You can take either option 1 which will make this a 1 time boot device selection,

.
1. Select Install or Boot Device

Select Device Type :
1. Diskette
2. Tape
3. CD/DVD
4. IDE
5. Hard Drive
6. Network
7. List all Devices

select : 

7. List all Devices

The system will go out for you and scan itself to determine which devices are available to boot from. All of your available boot devices will be displayed here. The menu can be a little tricky here. If you have a device pre-selected it will have a 1 next to it under the “Current Position” column. Use the “Select Device Number” listing to choose the device you want to boot from.

The next screen will offer you three choices :
1. Information
2. Normal Mode Boot
3. Service Mode Boot

Select :
2. Normal Mode Boot 

It shouldn’t really matter if you select normal or service mode, I always select normal mode.  Finally it asks if you’re sure you want to exit from SMS. Select ‘yes’ and let the boot go.

What you SHOULD see :
You’ll likely see a brief splash screen then the bootp request attempt.
Ideally you’ll see something like :
BOOTP : S=1 R=1

Which indicates it sent and received a request successfully. 

once the migration done, you will get a login prompt.  Follow the below for confirm the successful VIO migration.

$ ioslevel   

$ lsmap -all 

$ lstcpip

-------------------------------------------------------------------------------------

For updating the VIO server (For example: 2.1 to 2.2)

$ updateios –commit    (To confirm that there are no uncommitted updates)

$ updateios -accept -install -dev /vio_update_package    (To update the vio)

How to Setup SEA Failover on DUAL VIO servers?

What needs to be done?

Each SEA must have at least one virtual Ethernet adapter with the “Access external network” flag (previously known as “trunk” flag) checked. This enables the SEA to provide bridging functionality between the two VIO servers.

Note:  SEAs has the same PVID, but will have a different priority value.

Control Channel:

An additional virtual Ethernet adapter , which belongs to a unique VLAN on the system, is used to create the control channel between the SEAs, it must be specified in each SEA when configured in ha_mode. 

The purpose of this control channel is to communicate between the two SEA adapters to determine when a fail over should take place

Limitation:

SEA Failover was introduced with Fixpack 7 (Virtual I/O server version 1.2), so both Virtual I/O Servers need to be at this minimum level.

Steps:

Create the Virtual ethernet adapter with the following option on the VIOS1.

virtual adapter a unique (Port Virtual LAN ID) VLAN ID (PVID): "1"

Check the box "access external network".

Give the virtual adapter a low trunk priority. EX: "1"

mkvdev -sea ent0 -vadapter ent2 -default ent2 -defaultid 1 -attr ha_mode=auto ctl_chan=ent3

Create the Virtual ethernet adapter with the following option on the VIOS2

virtual adapter the same VLAN ID (PVID) as VIOS1. EX: "1"

Check the box "access external network".

Give the virtual adapter a higher trunk priority. EX: "2"

mkvdev -sea ent0 -vadapter ent2 -default ent2 -defaultid 1 -attr ha_mode=auto ctl_chan=ent3

Create the Virutal ethernet adapter for control channel with the following option on the both VIOS1 and VIOS2.

Give this new virtual adapter another unique VLAN ID (PVID) EX: "99"

Do NOT check the box "access external network".

Shutdown, Activate VIOS2 or run cfgdev from VIOS command line if created with DLPAR.

Manual SEA Failover On VIO server:

Scenario 1:

$ lsdev -type adapter

or 

$ oem_setup_env 

# lsdev -Cc adapter |grep ent --> Note which ent is the SEA 

# entstat -d entX | grep State --> Check for the state (PRIMARY, or BACKUP)

Set ha_mode to standby on primary VIOS with chdev command:

# chdev -l entX -a ha_mode=standby

or

$ chdev -dev -attr ha_mode=standby

Reset it back to auto and the SEA should fail back to the primary VIOS:

# chdev -l entX -a ha_mode=auto

or

$ chdev -dev -attr ha_mode=auto

Scenario 2, Primary VIOS Shutdown

Reboot the primary VIOS for fail over to backup SEA adapter.

When the primary VIOS is up again, it should fail back to the primary SEA adapter.

Scenario 3, Primary VIOS Error

Deactivate primary VIOS from the HMC for fail over to backup SEA adapter.

Activate the primary VIOS for the fail back to the primary SEA adapter again.

Scenario 4, Physical Link Failure

Unplug the cable of the physical ethernet adapter on primary VIOS for the failover to the backup VIOS.

Replug the cable of the physical ethernet adapter on primary VIOS for the failback to the primary VIOS.

Scenario 5, Reverse Boot Sequence

Shut down both the VIO servers.

Activate the VIOS with backup SEA until the adapter becomes active.

Activate the VIOS with primary SEA. The configuration should fail back to

the primary SEA.