Thanks. It's nice to see what you do within CMS. We currently have some guests that test a shared minidisk in an CSE environment to see if they are already started. Obviously that has to be changed in an SSI configuration.
Actually, when searching for what I should/could do I already copied your configuration for boot.local to my test machine. (yes, I know, I'm lazy, copy-paste saves from inventing it myself ;-)). We are on SUSE so indeed the boot.local could be used in our system. Our Linux systems are internally configured so within CMS we don’t handle stuff like IP and hostname. Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van Sleeuwen -----Original Message----- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Friday, January 22, 2016 11:28 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: SSI guest best practice /etc/init.d/boot.local has this in it for the swap disks (if you are RH rather than SUSE that might be a different file) : /sbin/mkswap /dev/disk/by-path/ccw-0.0.ff00-part1 /sbin/mkswap /dev/disk/by-path/ccw-0.0.ff01-part1 /sbin/mkswap /dev/disk/by-path/ccw-0.0.ff02-part1 /sbin/mkswap /dev/disk/by-path/ccw-0.0.ff03-part1 /sbin/swapon /dev/disk/by-path/ccw-0.0.ff00-part1 -p 4 /sbin/swapon /dev/disk/by-path/ccw-0.0.ff01-part1 -p 3 /sbin/swapon /dev/disk/by-path/ccw-0.0.ff02-part1 -p 2 /sbin/swapon /dev/disk/by-path/ccw-0.0.ff03-part1 -p 1 We don’t do anything with them from CMS. We do other necessary stuff from CMS. Mainly checking of where we are and writing various parms that a linux boot script uses to configure IP, hostname, etc. Marcy -----Original Message----- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van Sleeuwen, Berry Sent: Friday, January 22, 2016 2:20 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] SSI guest best practice Thanks, That's indeed helpful. In the past we tested a provisioning tool that couldn't handle our CMS setup (both Linux PROFILE EXEC and AUTOLOG1 PROFILE EXEC) so I will take such items into account when redesigning our environment. We currently don't use any tools other than our own processes to build new guests. I would expect cloning guests from the directory would be easier than have to deal with the various CMS setups that could exist. So if I understand correctly, you configure the swap disks regardless of what has been done in the CMS part? Yes, vswitches should indeed be the same on all LPARs, provided the tools will grant guests on the VM systems. Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van Sleeuwen -----Original Message----- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Marcy Cortes Sent: Friday, January 22, 2016 11:05 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: SSI guest best practice That's what we do. But we also still mkswap and swapon on the Linux side. That way if changes are made to the swap signature info there, no worries. Also we had to change the vdisk in the directory to COMMAND DEFINE VFB-512 .... in order to support LGR. Also had to add OPTION CHPIDV ONE Be sure your vswitches are defined the same as well or you won't be able to relocate. Wave didn't deal with CMS in the directory entry in November. I think that has been fixed, but I haven't retested yet. 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. 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.
