AFAIK a FORCE will kill the guest immediately instead of let it shutdown nicely. So when the linux guest is rebooted you will get a filesystemcheck for sure. And perhaps even file system errors that need to be fixed (manually).
I would suggest: pipe cp q signals | locate /Enabled/ | specs /SIGNAL SHUTDOWN/ 1 w1 nw /WITHIN 300/ nw | cons Still no guarantee for a proper shutdown of guests though. When they haven't finished shutdown themselves they will get forced after the timer expires. We have a 'SHUTSYS' script that has the option to shutdown everything except VM itself. Perhaps an idea to add this to the shutdown script, option (NOIPL or something like that to prevent a VM IPL. Afterwards you can use the AUTOLOG1/2 machine to restart all services. Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van Sleeuwen -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Scott Rohling Sent: Wednesday, May 27, 2015 5:06 PM To: [email protected] Subject: Re: Are weekly z/VM IPLs necessary? This could help next time? pipe cp q signals | locate /Enabled/ | specs /FORCE/ 1 w1 nw | cons You can issue this safely to see what I'm talking about Change the 'cons' to 'CP' .... and each guest who has signal enabled (usually Linux and SFS) will get forced (signalled). Wait for them to come down and then autolog AUTOLOG1/2 or whatever to restart things. 'CP SHUTDOWN' essentially does the above and then brings z/VM down.. so this way you can bring down the guests and not z/VM itself.. Scott Rohling On Wed, May 27, 2015 at 7:55 AM, Duerbusch, Tom <[email protected]> wrote: > The last time we have IPL'ed either of our VM systems was due to a air > conditioner failure (thermal shutdown of the z/890 box) 590 days ago. > > The only problem we had was with the zLinux side starting up. > We got the messages: > /dev/system/home has gone 1537 days without being checked, check forced. > /dev/dasda1 has gone 931 days without being checked, check forced. > /dev/dasda1 has gone 1075 days without being checked, check forced. > > Since check disk was being run, and the time they run varies by disk > size (or disk used, or number of files or....) the guests came up out of > order. > > To fix it, we did the dumbest (ok easiest...requires no thinking) > thing to do.... > > Wait for all 27 images to come up and go idle. > Issue the shutdown script. > IPL z/VM again and let AUTOLOG bring up all guests in the proper order. > > So, for some of us, the only time we need to IPL VM, is for a box > swap, LPAR reconfiguration (add memory), maintenance to CP or > installation of a new CP. > > It will be interesting to here what others had issues with. > > Tom Duerbusch > THD Consulting > > On Wed, May 27, 2015 at 9:33 AM, Will, Chris <[email protected]> wrote: > > > We have gotten in the habit of IPLing our z/VM and zLinux guests > > every Sunday during our standalone window. With the window > > shrinking and the need for 24/7 availability is it really necessary > > to IPL every week? If not what potential problems could we run into > > by not doing the IPL > (memory > > leaks, logs filling etc.). This is in comparison to the Intel side > > of > the > > shop (Red Hat, Windows) where they go months between IPLs. The only > > benefit I see is the opportunity to recycle WMB execution groups. > > > > Chris Will > > > > > > > > The information contained in this communication is highly > > confidential > and > > is intended solely for the use of the individual(s) to whom this > > communication is directed. If you are not the intended recipient, > > you are hereby notified that any viewing, copying, disclosure or > > distribution of this information is prohibited. Please notify the > > sender, by electronic mail or telephone, of any unintended receipt > > and delete the original message without making any copies. > > > > Blue Cross Blue Shield of Michigan and Blue Care Network of > > Michigan are nonprofit corporations and independent licensees of the > > Blue Cross and > Blue > > Shield Association. > > > > -------------------------------------------------------------------- > > -- For LINUX-390 subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO > > LINUX-390 or visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > -------------------------------------------------------------------- > > -- For more information on Linux on System z, visit > > http://wiki.linuxvm.org/ > > > > > > -- > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, Atos’ liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request.
