install maintenance level 1

[RMGBELGIUM]

Hi Guys,

just wanted to get some info about the following :

When you install a maintenance level on AIX , various subsystems on the AIX box are restarted.As our production machines run on SAN storage, we surely don't want the pcmserv subsystem that controls the IO to the storage to be restarted.This is the first time I have to install a ML with our new storage, and I don't wanna find out if my storage goes down when installing Has anyone encountered sth like that , is there a possibility that the above scenario could happen , or can I go ahead and upgrade knowing my storage is likely to remain untouched.The machines are P630, AIX5.2 ML6, attached to DS6800 through FC, and upgrading to AIX52 ML8

tia,

rgds,

R.

 

[khalidaaa]

I did this on one of our machine (on an LPAR) which is connected to SAN. I didn't have to restart the SAN for that. I just restarted the LPAR!!!

Regards,
Khalid

 

[victorv]

Hi,
the SAN lives a own life, and upgrading OS on your machine
may (at maximum) lead your host to not connect to it.
SAN fw and data will not be touched.

Before making an OS or Application SW upgrade, perform a mksysb, (in AIX is almost easy and of secure effect on restore) and then the upgrade. I belive you will not have problems. You have only to choose the appropriate moment to do it, to reststart machine and in in the worse, to restore mksysb.

bye

 

[RMGBELGIUM]

thx guys for the answers ! I feared at first that during the ML upgrade, the pcmserv subsystem on AIX would be restarted , causing the machine to loose connection to the SAN. Normally I install an ML on development first, if that crashes, it isn't a big deal , but development is still on SSA storage, while production is on SAN,so I can predict the behaviour...

rgds,

R.

 

[p5wizard]

The pcmserv is not necessary for your SAN disks to operate. IMHO pcmserv runs in the background to keep an eye on all your SAN LUNs' multiple paths and it tries to restart paths that have become offline due to whatever problem.

SDDPCM server daemon The SDDPCM server daemon (pcmsrv) component consists of a UNIX application daemon that is installed in addition to the SDDPCM path control module. The pcmsrv daemon only provides the path-reclamation function for SDDPCM. It regularly tests and recovers broken paths that have become operational. It tests OPEN_FAILED paths when healthcheck is turned off. It also tests CLOSE_FAILED paths for devices that are in the CLOSED state. The daemon “sleeps” for one-minute intervals between consecutive executions. If the test succeeds, then pcmsrv reclaims these paths and changes the states of these paths according to the following characteristics: 336 Multipath Subsystem Device Driver User’s Guide
v If the state of the device is OPEN, and healthcheck function is turned off, then pcmsrv changes the states of OPEN_FAILED paths of that device to OPEN. v If the state of the device is CLOSE, then pcmsrv changes the states of CLOSE_FAILED paths of the device to CLOSE.pcmsrv does not bind to any TCP/IP port by default but allows port binding to be dynamically enabled or disabled. The SDDPCM package ships a template file of pcmsrv.conf that is named as sample_pcmsrv.conf. The sample_pcmsrv.conf file is located in the /etc directory. You must use the sample_pcmsrv.conf file to create the pcmsrv.conf file in the /etc directory by simply copying sample_pcmsrv.conf and naming the copied file pcmsrv.conf. You can then dynamically change port binding by modifying parameters in pcmsrv.conf. The trace for pcmsrv is saved in pcmsrv.log and pcmsrv_bak.log files. These are wrap-around files and each is a maximum of 4 MB in size. Trace files are located in the /var/adm/ras directory.

That said, I would not update ML with applications running and SAN volumes being accessed. You need to reboot afterward anyway...


HTH,

p5wizard