Power on rapide d'une partition en ligne de commande :

Lister les Pseries :
lssyscfg -r sys -F name

Lister les partitions d'un pseries :
lssyscfg -m Nomdemonpseries -r lpar

Lister les caracteristiques d'une partition précise :
lssyscfg -m Nomdemonpseries -r lpar --filter "lpar_names=nomdemalpar"

Power on de la partition :
chsysstate -r lpar -m Nomdemonpseries -o on -n nomdemalpar  -f profile_du_profile_nomdemalpar -b normal

Ouverture d'un terminal : 
mkvterm -m Nomdemonpseries -p nomdemalpar

Changing queue depth in the ODM

Prendre un disque USPV :

lsdev -Ccdisk
...
hdisk6  Available 04-01-02 Hitachi MPIO Disk USP V (Fibre)
...


reperer le type d'un disque :

odmget -q name=hdisk6 CuDv
CuDv:
        name = "hdisk6"
        status = 1
        chgstatus = 2
        ddins = "scsidisk"
        location = "04-01-02"
        parent = "fscsi1"
        connwhere = "W_1"
        PdDvLn = "disk/fcp/htcuspvmpio"


récuperer l'objet odm correspondant :

odmget -q "uniquetype=disk/fcp/htcuspvmpio and attribute=queue_depth" PdAt

PdAt:
        uniquetype = "disk/fcp/htcuspvmpio"
        attribute = "queue_depth"
        deflt = "2"
        values = "1-32,1"
        width = ""
        type = "R"
        generic = "UD"
        rep = "nr"
        nls_index = 30

Pour récupérer l'odm :

odmget -q "uniquetype=disk/fcp/htcuspvmpio  and attribute=queue_depth" PdAt |sed s/deflt\ =\ \"2\"/deflt\ =\ \"XX\"/g > /tmp/change_qd

Pour le changer

odmchange -o PdAt -q "uniquetype=disk/fcp/htcuspvmpio and attribute=queue_depth" /tmp/change_qd

Save current profiles via command line on the HMC

to save and make it the default profile :

for i in $(lssyscfg -r lpar -m P570 -F name);
 do
    echo $i
    mksyscfg -r prof -m P570 -o save -p $i  -n ${i}_A_JOUR_AU_211010  
    chsyscfg -r lpar -m P570 -i "name=$i,default_profile=${i}_A_JOUR_AU_211010"
 done


to validate :

lssyscfg -r lpar  -m P570 -F name,default_profile

Vio commands : list VTD/vsa on same line :

lsmap -all -field vtd backing -fmt :

vhost4:hdisk55:hdisk11
vhost5:hdisk53:hdisk54:hdisk12
vhost6:hdisk58:hdisk59:hdisk60:hdisk61:hdisk62:hdisk63:hdisk64:hdisk65:hdisk66:hdisk13

lsmap -all -field vtd svsa -fmt :

vhost0:dapart1d1:dapart1d2:dapart1r1
vhost1:dapart2d1:dapart2r1
vhost2:dapart3d1:dapart3d2:dapart3d3:dapart3r1

For virtual SCSI (default), the following fields are supported:

svsa

Server virtual adapter.

physloc

The physical location code of the server virtual adapter.

clientid

Client partition ID.

vtd

Virtual target device.

lun

Logical unit number.

backing

Backing device.

bdphysloc

The physical location code of the backing device.

status

Virtual target device status

useful for shells

MERCI  CHRISTOPHE !

public key on hmc

key=`cat /.ssh/id_rsa.pub`
ssh hmc -l hscroot mkauthkeys -a \"$key\"

mksysb on one copy

If you have a system mirrored on two or three disks, and you want to restore it on a single disk system :
first create the image.data :
mkszfile
edit image.data to remove all hdisk1 and hdisk2 occurences


vi /image.data

VG_SOURCE_DISK_LIST= hdisk0 hdisk1
...
LV_SOURCE_DISK_LIST= hdisk0 hdisk1
in each lv step, you must have copie=1

divide all PP per 2 or 3 (depends on the original copy number)  "PP= XX" ( PP number must be LV numbers)
Do a mksysb with
Generate new /image.data file? à NO
Disable software packing of backup? à YES <= there is a bug in aix 5.2 which prevent reinstall sometimes, when packing is done...

Question
Why is my Shared Ethernet Adapter (SEA) failover delayed?

Cause
Spanning tree is turned on at the switch port with portfast disabled.

Answer
SEA failover, from primary to backup, the delay is sometimes due to Spanning Tree Protocol being enabled on the switch ports.
To ensure prompt recovery times when you enable the Spanning Tree Protocol on the switch ports connected to the physical adapters of the Shared Ethernet Adapter, you can also enable the portfast option on those ports. The portfast option allows the switch to immediately forward packets on the port without first completing the Spanning Tree Protocol. (Spanning Tree Protocol blocks the port completely until it is finished.)

On SEA failback, from backup to primary, there is an additional issue:

The switches are sometimes not ready to read transmit and receive packets even after declaring the link as up. Hence, it leads to packet loss. This type of problem can be avoided or reduce failback time by disabling Spanning Tree Protocol all together.

Here are the 5 supported methods to test SEA failover:

Scenario 1, Manual SEA Failover
On VIO server:
$ 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.

NOTE: When we force a manual failover in Scenario 1, we bring down the link to the switch connected to VIO1, thus asking the switch to modify its MAC tables accordingly. The backup VIOS is able to take over immediately since it is up and running but was just not being used as yet. Now, during failback, the same situation occurs. Less delay happens because we forced the failover while the primary VIOS is up and running.

In Scenario 2, when primary VIO1 is shutdown, the failover is also immediate. However, the failback to VIO 1 takes more time because the switch connected to VIO1 takes more time to start requeing packets.

The fact that the delay is shorter for manual failover and longer for VIOS shutdown, implies that the delay is happening because some switches don't start transmitting and receiving packets for some time even after declaring that the link as up. From IBM's side, if the link is up when TCPIP is started, then we assume the switch is ready to start sending and receiving packets even though it may not actually be ready.

Related information
How to Setup SEA Failover on DUAL VIO Servers
Other SEA Related Links

removing end of a variable

export TOTO=fssam0sv
echo ${TOTO%%sv}

ca retire le sv de la fin de la variable

which ipc is holding a file open

If you cant unmount a fs due to an ipc :

Problem:
server DB2 unmount file system
IPCS process still running ID instance is owned by DB2
ipcrm 0515-020 shmid ( was not found idnumber)
m 2097169 0xffffffff D-rw-rw-rw- udbpd030 db2iadm1

[root@mbhop5pdb2]/> ipcrm -m 2097169
ipcrm: 0515-020 shmid(2097169) was not found.


1) Use the new -S option on ipcs to obtain the shared memory segment ID.

# ipcs -mS

m 131075 0x00001a4c --rw------- root system
SID :
0x2b85

2) Verify that the svmon command is installed on the system. If not,install from the AIX installation CDs.

$ lslpp -l perfagent.tools

3) Use the svmon command to find all processes attached to the shared memory segment.

# svmon -S 0x2b85 -l

Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual
2b85 3 work shared memory segment - 656 0 0 656
pid(s)=10862

This shared memory segment has only one process attached.

To remove this shared memory segment, you must first kill the process that is attached to the segment.
# kill 10862
# ipcrm -m 131075

unix time

Pour savoir à quelle date correspond 1254407497:

perl -e "print scalar(localtime(1254407497))"



et inversement:


perl -e "use POSIX ; print (mktime(10,45,11,31,4,107));"

avec comme syntaxe
mktime(sec, min, hour, mday, mon, year, wday = 0, yday = 0, isdst = 0)