Re: SSI guest best practice

2016-02-11 Thread Mauro Souza 
We implemented something like DHCP, bound to the guest name, not the MAC
address. It's working for 3 years now, and it's very low maintenance.

We had a USER CONFIG file on a MAINT630 disk, and every guest can link that
disk. The USER CONFIG is a simple text file containing this info:
GUEST  IPADDRESSNETMASK   GATEWAY HOSTNAME
LNX101 192.168.0.10 255.255.255.0 192.168.0.1 lnx101

Every time the guest boots(we have a rc.local entry for this), it looks for
the /etc/sysconfig/network/routes file. If the file is not found, we run
the following script:

chccwdev -e 191 2>&1 > /dev/null
udevadm settle
DISK=/dev/disk/by-path/ccw-0.0.0191
sleep 1
USERID=`vmcp q userid | awk '{print $1}'`
DATA=`cmsfscat -d $DISK -a user.config | grep $USERID`
if ! cmsfscat -d $DISK -a user.config | grep -q $USERID ; then
# request timeout, retry
chccwdev -d 191
sleep 1
chccwdev -e 191 2>&1 > /dev/null
udevadm settle
DISK=/dev/disk/by-path/ccw-0.0.0191
sleep 1
USERID=`vmcp q userid | awk '{print $1}'`
DATA=`cmsfscat -d $DISK -a user.config | grep $USERID`
fi
IP=`echo $DATA | awk '{print $2}'`
NETMASK=`echo $DATA | awk '{print $3}'`
GW=`echo $DATA | awk '{print $4}'`
HOSTNAME=`echo $DATA | awk '{print $5}'`
if [ "X$HOSTNAME" == "X" ] ; then
# hostname not found, abort
exit 1
fi
sed -i /etc/sysconfig/network/ifcfg-eth0 -e "s/^IPADDR=.*/IPADDR='$IP'/" -e
"s/^NETMASK.*/NETMASK='$NETMASK'/"
echo "default $GW - -" > /etc/sysconfig/network/routes
echo $HOSTNAME > /etc/HOSTNAME
reboot


This will run only once, on the first boot. When we create the machine, we
update the USER CONFIG file and xautolog it. Our template does not have the
/etc/sysconfig/routes, so every cloned guest will exec it.

Our automation does this differently. We use xcat (the community one, not
IBM's) and PHP IP Admin (phpipam). We can automatically detect all used IPs
on the network, assign one, and write it direct to the config files during
the provisioning.

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.

2016-01-25 18:13 GMT-02:00 Mark Post :

> All,
>
> Just FYI, but here at SUSE we're contemplating creating a systemd unit
> file and associated scripts so that our systems running on various
> hypervisors can do whatever sort of "cleanup" each one might require to
> exploit the features of that hypervisor.  For example, in the z/VM case,
> one of those things would be to detach all the CMS disks to be eligible for
> LGR.
>
> Of course, whatever we wind up devising would be better with input from
> the people that will ultimately be using it (or not), assuming it actually
> makes it into the product.  (We hope so, but as everyone knows "stuff"
> happens.)
>
> So, if you have any thoughts on what those various items might be for the
> various hypervisors you run, let us know.  We can discuss it here, with
> this thread, start a new one, whatever makes the most sense for the most
> people.
>
>
> Mark Post
>
> --
> 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/

Re: SSI guest best practice

2016-01-25 Thread Robert J Brenneman 
We create a user in the VM directory called '191USER' who's sole purpose is
to be a container for Linux system 191 A disks that get shared read only.
This allows us to keep all the CMS PROFILE EXEC automation in one place and
have it shared by all the Linux systems that need it. Since it is owned by
a regular user, not a Identity, systems LINKed to it are eligible for LGR.

Our shared profile does the following:
  runs MKSWAP,
  checks whether the Linux boot device actually exists,
  SMSGs to automation tools for keeping track of what's going on,
  detaches all CMS disks ( 190, 192-19F ),
  and then IPLs the Linux volume.

The 191 disk for the guest is a LINK to 191USER's ZZZ disk - where ZZZ is
more or less a version number of the PROFILE that resides there. This
allows multiple versions of PROFILE EXEC for 'special snowflake' systems
that require it, without having to manage files for every Linux system.
It's also handy if you want to use CMSFUSE to let Linux read CMS files and
do it's own configuration during init. ( think Cheap and Easy Cloud
Infrastructure as a Service )

We have tried out the DHCP static address thing too - it is actually quite
neat, and can permit some nifty stuff if you also couple it with Dynamic
DNS updates to coordinate the GUEST name with the IP address and the
Hostname - but it requires some 'newish' technology in DNS land and very
very close cooperation with the network team to make it legit so you don't
get all fired and stuff.


On Sat, Jan 23, 2016 at 10:55 AM, Quay, Jonathan (IBM) <
jonathan.q...@ihg.com> wrote:

> We have to use static MACIDs because our servers are behind load balancers
> that require it.  But SSI is very convenient and lets us work on hardware
> and zVM without taking application outages.  You do have to remember to do
> the SYSTEM CONFIG work to set up your EQIDs for your VSWITCHes.
> --
> 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/
>



--
Jay Brenneman

--
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/

Re: SSI guest best practice

2016-01-25 Thread Mark Post 
All,

Just FYI, but here at SUSE we're contemplating creating a systemd unit file and 
associated scripts so that our systems running on various hypervisors can do 
whatever sort of "cleanup" each one might require to exploit the features of 
that hypervisor.  For example, in the z/VM case, one of those things would be 
to detach all the CMS disks to be eligible for LGR.

Of course, whatever we wind up devising would be better with input from the 
people that will ultimately be using it (or not), assuming it actually makes it 
into the product.  (We hope so, but as everyone knows "stuff" happens.)

So, if you have any thoughts on what those various items might be for the 
various hypervisors you run, let us know.  We can discuss it here, with this 
thread, start a new one, whatever makes the most sense for the most people.


Mark Post

--
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/

Re: SSI guest best practice

2016-01-23 Thread Quay, Jonathan (IBM) 
We have to use static MACIDs because our servers are behind load balancers that 
require it.  But SSI is very convenient and lets us work on hardware and zVM 
without taking application outages.  You do have to remember to do the SYSTEM 
CONFIG work to set up your EQIDs for your VSWITCHes.
--
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/

Re: SSI guest best practice

2016-01-22 Thread Rich Smrcina 

You can still use CMS to run swapgen. When you IPL Linux, CMS is no longer 
there.

On 01/22/2016 03:39 PM, van Sleeuwen, Berry wrote:

Hi All,

We want to move our Linux environment into an SSI cluster. We have local 
resources that I need to get rid of in order for guests to use LGR. The most 
obvious are the CMS minidisks (190, 19E). Most commands in the PROFILE EXEC are 
CP commands so these can be moved into the directory. But we also use SWAPGEN 
to initialize swap disks and that requires CMS.

What would be the best practice to configure the guests? I have seen both ways. 
Either detach the CMS disks once a linux guest is booted or leave out CMS 
entirely and format the swap disks within the *.local scripts. Are there any 
requirements with the various provisioning products such as ICM or Wave?

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven
• +31 (0)6 22564276
  [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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.

--

Richard Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 

Signature

*Follow us:*
facebook  LinkedIn 
 twitter 
 Xing 


--

Richard Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 

Signature

*Follow us:*
facebook  LinkedIn 
 twitter 
 Xing 



--
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/

Re: SSI guest best practice

2016-01-22 Thread Rich Smrcina 
Regarding the last part of your message, zPro has no restrictions on directory entry 
contents. What ever is in the directory is replicated to the destination server.


On 01/22/2016 03:39 PM, van Sleeuwen, Berry wrote:

Hi All,

We want to move our Linux environment into an SSI cluster. We have local 
resources that I need to get rid of in order for guests to use LGR. The most 
obvious are the CMS minidisks (190, 19E). Most commands in the PROFILE EXEC are 
CP commands so these can be moved into the directory. But we also use SWAPGEN 
to initialize swap disks and that requires CMS.

What would be the best practice to configure the guests? I have seen both ways. 
Either detach the CMS disks once a linux guest is booted or leave out CMS 
entirely and format the swap disks within the *.local scripts. Are there any 
requirements with the various provisioning products such as ICM or Wave?

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven
• +31 (0)6 22564276
  [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]


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.

--

Richard Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 

Signature

*Follow us:*
facebook  LinkedIn 
 twitter 
 Xing 


--

Richard Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 

Signature

*Follow us:*
facebook  LinkedIn 
 twitter 
 Xing 



--
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/

Re: SSI guest best practice

2016-01-22 Thread Alan Altmark 
On Friday, 01/22/2016 at 10:10 GMT, "van Sleeuwen, Berry" 
 wrote:
> So the question is what would be the best way to configure the new 
setup.
> Either remove CMS dependency altogether or detach the disks after we 
don't need
> CMS anymore (in the PROFILE EXEC or after Linux IPL has been completed). 
It
> might depend on the requirements in other (provisioning) products.

"Best" is a point in time assessment, Berry.  The good news is that it's 
easy to switch from CMS boot to Linux boot, and vice versa, as your needs 
change.

o If you IPL CMS first, DETACH the disks before you IPL Linux.
o If you IPL Linux first, then make sure you don't have the CMS disks in 
the directory.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
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/

Re: SSI guest best practice

2016-01-22 Thread Alan Altmark 
On Friday, 01/22/2016 at 10:29 GMT, Marcy Cortes 
 wrote:
> 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.

I am wondering if people are looking at using persistent DHCP for this. To 
make it work you have to use layer 2 VSWITCHes and you have to manage 
MACIDs on the NICDEFs.   Your automation tools have to "manufacture" a new 
MACID for every new NICDEF and put it there or on COMMAND DEFINE NIC. 
(I've created such automation for DIRMAINT.)

It means that the network people can operate the DHCP server, whether its 
onboard as a Linux guest or outboard, and take responsibility for changing 
things (home, DR, IP changes, etc.) 

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
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/

Re: SSI guest best practice

2016-01-22 Thread van Sleeuwen, Berry 
"best" is also a point of view (or a religion perhaps). I was raised with CMS 
so I do like CMS a lot. The CP commands in the directory remove a lot of the 
need for executing command within a PROFILE EXEC. So far I have dismissed this 
configuration because I am (too much?) accustomed to CMS.

I'm just curious if sticking to CMS would be indeed the "best" way to configure 
our guests in future environments. Especially when provisioning products might 
not handle the CMS configuration for a guest PROFILE EXEC or AUTOLOG1 
configuration.

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 Alan 
Altmark
Sent: Friday, January 22, 2016 11:37 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SSI guest best practice

On Friday, 01/22/2016 at 10:10 GMT, "van Sleeuwen, Berry"
<berry.vansleeu...@atos.net> wrote:
> So the question is what would be the best way to configure the new
setup.
> Either remove CMS dependency altogether or detach the disks after we
don't need
> CMS anymore (in the PROFILE EXEC or after Linux IPL has been completed).
It
> might depend on the requirements in other (provisioning) products.

"Best" is a point in time assessment, Berry.  The good news is that it's easy 
to switch from CMS boot to Linux boot, and vice versa, as your needs change.

o If you IPL CMS first, DETACH the disks before you IPL Linux.
o If you IPL Linux first, then make sure you don't have the CMS disks in the 
directory.

Alan Altmark

Senior Managing z/VM and Linux Consultant Lab Services System z Delivery 
Practice IBM Systems & Technology Group ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
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/
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.

Re: SSI guest best practice

2016-01-22 Thread van Sleeuwen, Berry 
I know, just as CMS is no longer available after we IPL a VSE guest. But as 
long as the CMS disks are linked in the guest that will prevent LGR. Granted, 
we might build a shared CMS for our Linux guests but I don't like a second, 
separate CMS.

So the question is what would be the best way to configure the new setup. 
Either remove CMS dependency altogether or detach the disks after we don't need 
CMS anymore (in the PROFILE EXEC or after Linux IPL has been completed). It 
might depend on the requirements in other (provisioning) products.

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 Rich 
Smrcina
Sent: Friday, January 22, 2016 10:48 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SSI guest best practice

You can still use CMS to run swapgen. When you IPL Linux, CMS is no longer 
there.

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.

Re: SSI guest best practice

2016-01-22 Thread van Sleeuwen, Berry 
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.

Re: SSI guest best practice

2016-01-22 Thread Rich Smrcina 

As Dennis mentioned, do the detach. I do that as well.

On 01/22/2016 04:08 PM, van Sleeuwen, Berry wrote:

I know, just as CMS is no longer available after we IPL a VSE guest. But as 
long as the CMS disks are linked in the guest that will prevent LGR. Granted, 
we might build a shared CMS for our Linux guests but I don't like a second, 
separate CMS.

So the question is what would be the best way to configure the new setup. 
Either remove CMS dependency altogether or detach the disks after we don't need 
CMS anymore (in the PROFILE EXEC or after Linux IPL has been completed). It 
might depend on the requirements in other (provisioning) products.

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 Rich 
Smrcina
Sent: Friday, January 22, 2016 10:48 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SSI guest best practice

You can still use CMS to run swapgen. When you IPL Linux, CMS is no longer 
there.

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.

--

Richard Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com <mailto://r...@velocitysoftware.com>

Signature
<http://www.velocitysoftware.com/>
*Follow us:*
facebook <http://www.facebook.com/pages/Velocity-Software/356098274460840> LinkedIn 
<http://www.linkedin.com/company/1798379?trk=tyah> twitter 
<https://twitter.com/VelocitySoftw> Xing 
<https://www.xing.com/companies/velocitysoftwaregmbh>

--

Richard Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com <mailto://r...@velocitysoftware.com>

Signature
<http://www.velocitysoftware.com/>
*Follow us:*
facebook <http://www.facebook.com/pages/Velocity-Software/356098274460840> LinkedIn 
<http://www.linkedin.com/company/1798379?trk=tyah> twitter 
<https://twitter.com/VelocitySoftw> Xing 
<https://www.xing.com/companies/velocitysoftwaregmbh>


--
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/

Re: SSI guest best practice

2016-01-22 Thread van Sleeuwen, Berry 
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.

Re: SSI guest best practice

2016-01-22 Thread Marcy Cortes 
/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.

Re: SSI guest best practice

2016-01-22 Thread Marcy Cortes 
You're welcome.

Our prod servers can be brought up in any of 3 data centers.  And they could 
come up different host names and IPs for testing recovery scenarios.  Our 
dev/test servers can come up in 2 data centers.
It's just easier to have one spot in CMS to carry this info.

Liberally stolen from James/Rick at NW :)
It's good to SHARE.

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:58 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SSI guest best practice

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

Re: SSI guest best practice

2016-01-22 Thread Marcy Cortes 
Alan wrote:

>I am wondering if people are looking at using persistent DHCP for this. To 
>make it work you have to use layer 2 VSWITCHes and you have to manage 
>MACIDs on the NICDEFs.   Your automation tools have to "manufacture" a new 
>MACID for every new NICDEF and put it there or on COMMAND DEFINE NIC. 
>(I've created such automation for DIRMAINT.)

>It means that the network people can operate the DHCP server, whether its 
>onboard as a Linux guest or outboard, and take responsibility for changing 
>things (home, DR, IP changes, etc.) 

I'm not.  I don't want to have to involve another group involved.   Right now 
DR is entirely automated and operations staff does the whole thing.   Our VM 
ids map to IP addresses (not hostnames) and I can relate the 2 without looking 
at a spreadsheet all the time.   On servers with more than one interface their 
IPs end in the same octet.  I don't want network people sticking other devices 
in our subnets and messing with the scheme :)  And i don't want to have to 
submit (more) paperwork!  VM provided MACIDs are fine with us.

Marcy

--
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/

Re: SSI guest best practice

2016-01-22 Thread Eduardo Oliveira 
Hi,

Once SSI is up and running you can do LGR using IBM Wave by dragging a server 
from one node  and dropping it to another node of the same SSI cluster, all 
graphically. You can get the pre-requisites for IBM Wave from the latest 
Redbook available publicly.  A simple search on IBM Wave Redbook will bring it 
up. 
Tks,
Eduardo C. Oliveira

Sent from IBM Verse via Smartphone


   van Sleeuwen, Berry --- SSI guest best practice --- 
From:"van Sleeuwen, Berry" 
To:LINUX-390@VM.MARIST.EDUDate:Fri, Jan 22, 2016 
3:41 PMSubject:SSI guest best practice
  
Hi All,We want to move our Linux environment into an SSI cluster. We have 
local resources that I need to get rid of in order for guests to use LGR. The 
most obvious are the CMS minidisks (190, 19E). Most commands in the PROFILE 
EXEC are CP commands so these can be moved into the directory. But we also use 
SWAPGEN to initialize swap disks and that requires CMS.What would be the best 
practice to configure the guests? I have seen both ways. Either detach the CMS 
disks once a linux guest is booted or leave out CMS entirely and format the 
swap disks within the *.local scripts. Are there any requirements with the 
various provisioning products such as ICM or Wave?Met vriendelijke groet/With 
kind regards/Mit freundlichen Grüßen,Berry van SleeuwenFlight Forum 3000 5657 
EW Eindhoven• +31 (0)6 22564276 [cid:image001.jpg@01CE3508.E10AE080]
[cid:image002.jpg@01CE3508.E10AE080]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.

--
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/

Re: SSI guest best practice

2016-01-22 Thread Marcy Cortes 
What Dennis said.

Running DHCP on servers may even be prohibited by security policy.  I haven't 
checked, but I wouldn't be surprised if it was.



-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of O'Brien, 
Dennis L
Sent: Friday, January 22, 2016 6:51 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] SSI guest best practice

>Managing MACIDs is actually way *less* complicated than IPs since you 
>don't have to worry about global uniqueness or subnet boundaries.

The network people worry about global uniqueness and subnet boundaries, and 
they give us an IP address range to use.  We have to make sure that the guest 
gets the right address.  I don't see how doing that with MACID's is any less 
complicated than what we're doing now.  Perhaps it comes down to what you're 
comfortable with.  I'm most comfortable in CMS, so using a Linux guest as a 
DHCP server, with all the patch management and everything else that comes with 
Linux, seems a lot more complicated than a few CMS files.


    Dennis

"I'm not a football expert."  -- San Francisco 49ers CEO Jed York


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Alan 
Altmark
Sent: Friday, January 22, 2016 18:29
To: LINUX-390@vm.marist.edu
Subject: Re: SSI guest best practice

On Saturday, 01/23/2016 at 01:13 GMT, "O'Brien, Dennis L" 
<dennis.l.o'br...@bankofamerica.com> wrote:
> Like Marcy said, I don't see anything to gain by involving the DHCP
people.
> Managing MACID's is no less complicated than managing IP addresses.

Managing MACIDs is actually way *less* complicated than IPs since you don't 
have to worry about global uniqueness or subnet boundaries.  For those with a 
liberal attitude about DHCP, you don't have to use the MACID. 
 You can pass the VM user ID to the DHCP server instead.

And you don't have to turn over operations to The Network People if you don't 
want to.  I was just being a troll.  :-)  Use a Linux guest and control IP 
address assignment based on DHCP config, all in a single 
location.   That eliminates CMS from the Linux guests, avoiding any 
CMS/LGR "entanglements", and dead relocation is good enough for the DHCP server.

Alan Altmark

Senior Managing z/VM and Linux Consultant Lab Services System z Delivery 
Practice IBM Systems & Technology Group ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
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/

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.

--
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/

Re: SSI guest best practice

2016-01-22 Thread Alan Altmark 
On Saturday, 01/23/2016 at 01:13 GMT, "O'Brien, Dennis L" 
 wrote:
> Like Marcy said, I don't see anything to gain by involving the DHCP 
people.
> Managing MACID's is no less complicated than managing IP addresses.

Managing MACIDs is actually way *less* complicated than IPs since you 
don't have to worry about global uniqueness or subnet boundaries.  For 
those with a liberal attitude about DHCP, you don't have to use the MACID. 
 You can pass the VM user ID to the DHCP server instead.

And you don't have to turn over operations to The Network People if you 
don't want to.  I was just being a troll.  :-)  Use a Linux guest and 
control IP address assignment based on DHCP config, all in a single 
location.   That eliminates CMS from the Linux guests, avoiding any 
CMS/LGR "entanglements", and dead relocation is good enough for the DHCP 
server.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
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/

Re: SSI guest best practice

2016-01-22 Thread O'Brien, Dennis L 
>Managing MACIDs is actually way *less* complicated than IPs since you 
>don't have to worry about global uniqueness or subnet boundaries.

The network people worry about global uniqueness and subnet boundaries, and 
they give us an IP address range to use.  We have to make sure that the guest 
gets the right address.  I don't see how doing that with MACID's is any less 
complicated than what we're doing now.  Perhaps it comes down to what you're 
comfortable with.  I'm most comfortable in CMS, so using a Linux guest as a 
DHCP server, with all the patch management and everything else that comes with 
Linux, seems a lot more complicated than a few CMS files.


    Dennis

"I'm not a football expert."  -- San Francisco 49ers CEO Jed York


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Alan 
Altmark
Sent: Friday, January 22, 2016 18:29
To: LINUX-390@vm.marist.edu
Subject: Re: SSI guest best practice

On Saturday, 01/23/2016 at 01:13 GMT, "O'Brien, Dennis L" 
<dennis.l.o'br...@bankofamerica.com> wrote:
> Like Marcy said, I don't see anything to gain by involving the DHCP 
people.
> Managing MACID's is no less complicated than managing IP addresses.

Managing MACIDs is actually way *less* complicated than IPs since you 
don't have to worry about global uniqueness or subnet boundaries.  For 
those with a liberal attitude about DHCP, you don't have to use the MACID. 
 You can pass the VM user ID to the DHCP server instead.

And you don't have to turn over operations to The Network People if you 
don't want to.  I was just being a troll.  :-)  Use a Linux guest and 
control IP address assignment based on DHCP config, all in a single 
location.   That eliminates CMS from the Linux guests, avoiding any 
CMS/LGR "entanglements", and dead relocation is good enough for the DHCP 
server.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
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/

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.

--
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/

Re: SSI guest best practice

2016-01-22 Thread O'Brien, Dennis L 
Our setup is similar to Marcy's.  Each SSI cluster has a master list of guest 
userids and IP addresses in a CMS file.  Each entry contains production and DR 
test IP addresses.  We used to have separate addresses for real DR, but those 
are now the same as production.  The IP addresses are already registered in DNS.

The program that builds guests takes the next available name from the master 
list, updates the list to show that the name is in use, and builds the VM 
userid.  It also builds a "guestname CONFIG" file on the shared 191 minidisk 
that all guests use.  When Linux boots, it reads this configuration file from 
its 191 and configures the network.  When a z/VM system is IPLed in DR test 
mode, a program updates the guest configuration files with IP addresses from 
the master list.

Like Marcy said, I don't see anything to gain by involving the DHCP people.  
Managing MACID's is no less complicated than managing IP addresses.


    Dennis

"I'm not a football expert."  -- San Francisco 49ers CEO Jed York

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Marcy 
Cortes
Sent: Friday, January 22, 2016 15:52
To: LINUX-390@vm.marist.edu
Subject: Re: SSI guest best practice

Alan wrote:

>I am wondering if people are looking at using persistent DHCP for this. To 
>make it work you have to use layer 2 VSWITCHes and you have to manage 
>MACIDs on the NICDEFs.   Your automation tools have to "manufacture" a new 
>MACID for every new NICDEF and put it there or on COMMAND DEFINE NIC. 
>(I've created such automation for DIRMAINT.)

>It means that the network people can operate the DHCP server, whether its 
>onboard as a Linux guest or outboard, and take responsibility for changing 
>things (home, DR, IP changes, etc.) 

I'm not.  I don't want to have to involve another group involved.   Right now 
DR is entirely automated and operations staff does the whole thing.   Our VM 
ids map to IP addresses (not hostnames) and I can relate the 2 without looking 
at a spreadsheet all the time.   On servers with more than one interface their 
IPs end in the same octet.  I don't want network people sticking other devices 
in our subnets and messing with the scheme :)  And i don't want to have to 
submit (more) paperwork!  VM provided MACIDs are fine with us.

Marcy

--
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/

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.

--
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/