So, this question might get lengthy, but I'll try to keep it short. We're in the process of upgrading our SVC's to version 5.1.x. In the "Recommended Software Levels for SAN Volume Controller" guide (http://www-01.ibm.com/support/docview.wss?rs=591&uid=ssg1S1003554), there's a section for z/VM. We currently run z/VM 5.4 RSU0903 on a z/890 IFL running 45 or so SLES and Debian Linux guests on it. We use EDEV's for most of the storage on these Linux guests. In the "notes" section for z/VM in the SVC guide (mentioned above), it states "EDEVICE restriction: I/O must be quiesced during Concurrent Code Load (CCL) of a SVC cluster". So now to my 2 part question.
1) Because of the way the SVC performs it's upgrade, usually, one I/O group is taken down while being upgraded, then there is a 30 minute delay, then the second I/O group is taken down, activity is resumed to the first I/O group, then the upgrade is preformed on the second I/O group. Question 1 is, can it be as simple as varying of the CHPID attached to the first I/O Group, wait for it to complete the SVC node upgrade, and then during the 30 minute wait time, vary that CHPID back on and vary off the second CHPID in order to "quiesce the I/O" as mentioned above? 2) Second part to this question is, in the past we've lost one of our paths connected to the SVC. We were able to vary on the CHPID, PATH and Devices, etc., but couldn't figure out how to get the SVC and z/VM to initiate any kind of a handshake. The only way that we could get the path to reestablish activity was to IPL. Does anyone know of a command that can be issued either from VM or from the SVC to let the other one know that it's there again. I would liken it to something like a "ping", just something that says "hey, I'm here now, talk to me". Mark Wiggins University of Connecticut 860-486-2792
