I IPL z/VM only when CP maintenance is applied. I used to reboot/IPL my Linux guests at the same time. I no longer do that. I simply move them to another z/VM with LGR and after the z/VM IPL I move them back again. I can't think of the last time I had to reboot/IPL my Linux guests.
On Wed, May 27, 2015 at 11:30 PM, Marcy Cortes < marcy.d.cor...@wellsfargo.com> wrote: > You've gotten a lot of answers and they are worrisome! > > Here's my 5 or 6 cents. > > Yes, z/VM and Linux can go a very long time without being IPL'd/rebooted. > Your applications may or may not. I would argue if they cannot, they need > to solve the problem rather than clean it up with an IPL and/or reboot. > If they need a reboot every weekend to clean up their memory problems, > what happens if their volume doubles? Will they start rebooting every 3.5 > days? We saw an app that started having very intermittent periods of weird > delays after 5 or 6 weeks of uptime that was solved by an app recycle so > they are now searching for a leak. I will add that I don't think I've > ever seen an app leak problem affect Linux itself or for that matter VM > itself - cycling the app or pkill -u appuser has been enough to clear up > any memory issues. If someone asks your to recycle a server to solve an > app problem , just say no ( Or more diplomatically, really??can't we try > just recycling the app first?). The only ones I've seen that that was > actually necessary on was when the OOM killer on Linux shot things, visible > in the console. At that point reboot is inevitable and probably the server > was short on memory to start with) . > > If you go more than a couple months on Linux or even on z/VM these days > (and we all follow IBM ResourceLink Security for z/VM right?) , your patch > policy is very generous or non-existent. > > I would say that we are at probably 5-6 VM IPLs per year to stay current > (RSUs, releases, HW ucode), apply fixes we need (we find bugs, we apply > fixes, we don't wait around to find the bugs that someone else already did) > , and all security fixes. > > Linux is also averaging every other month for a reboot needed for kernel > and/or glibc things that of course will require a reboot. Our challenge > these days is to just coordinate those to same weekends so that there are > change-free holiday weekends and system change free weekends so that those > are available for application changes. > > PS - Our WMB (IIB) doesn't need weekly recycles as far as I've heard and > we've been running that for probably 4 or 5 years. Its supporting some > 70+ applications. > These days when someone brags about uptime I'm not impressed. Watch the > youtube from Share Seattle http://www.share.org/p/bl/et/blogaid=343 > Yeah, it was z/OS, but is your tn3270 running encrypted and not subject to > all the SSL bugs?! > > > PPS to Sir Alan,: i need a card for the security weasel club, thanks :) > > > Marcy > > > > -----Original Message----- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Will, Chris > Sent: Wednesday, May 27, 2015 7:34 AM > To: LINUX-390@VM.MARIST.EDU > Subject: [LINUX-390] Are weekly z/VM IPLs necessary? > > 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/ > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
