content_image/971580.jpg
inode=47 size=3 fd=34 2032030 inode=47 size=3 fd=36 10617192 inode=47 size=3 fd=10 11207164 /aha/cluster/nodeAddress.monFactory/nodeAddressEvent.mon: inode=52 size=3 fd=13 10617192 inode=52 size=3 fd=12 11207164 inode=52 size=3 fd=5 24838578 /aha/cluster/nodeState.monFactory/nodeStateEvent.mon: inode=46 size=3 fd=20 2032030 inode=46 size=3 fd=35 10617192 inode=46 size=3 fd=9 11207164 /aha/disk/repDiskState.monFactory/repDiskStateEvent.mon: inode=57 size=1 fd=36 2032030 /aha/disk/clDiskState.monFactory/clDiskStateEvent.mon: inode=56 size=1 fd=35 2032030 /aha/pool/tier.freespace.monFactory/poolId:000000000A2819F3000000005C420425,tierNa me:SYSTEM,unitName:percentage.mon: inode=58 size=1 fd=40 2032030 /aha/pool/tier.ecLowWaterMark.monFactory/poolId:000000000A2819F3000000005C420425,t ierName:SYSTEM.mon: inode=61 size=1 fd=41 2032030 # ps -o pid,args -p 11207164,24838578,10617192,2032030 PID COMMAND  2032030 /usr/sbin/vio_daemon -d 4 10617192 /opt/rsct/bin/IBM.ConfigRMd 11207164 /usr/sbin/rsct/bin/hagsd cthags 24838578 /usr/sbin/clconfd # 

Table 2-3 presents the documented CAA event types for each of the CAA event producers showing up as configured for the vio_daemon  event consumer in Example 2-92 on page 129. 

<img src='content_image/971580.jpg'>

This whole monitoring framework is extended for KSYS such that vio_daemon  can update the HSDB about received CAA events. When vio_daemon  is notified about a CAA event occurrence, it uses libvio.a  and ultimately libviohealth.a  to update tables in the vios.vioshs  schema. The VIOS state in the vios  table is updated with the received node state from CAA and the trans  table is inserted with CAA event details. To see how some of these event flows happen, we manually perform a shutdown of a non-DBN VIOS node and then start it. 

