Re: Planning for IFL and z/VM - looking for directions

2004-09-23 Thread Jim Elliott
 Currently we are running OS390/2.10 (64bit) going z/OS in a
 month's time. We just signed the order for z/VM and IFL. The
 fun begins soon. Has anyone got a checklist or planning guide
 for setting up IFL, z/VM and installation of virtual machines?
 Before I put some thought into it, I want to learn from those
 who went before me. I will also be scouring some redbooks.

Ranga:

The Redbooks are a great place to start, just make sure you are
using the most recent. There have been a lot of Redbooks on Linux
on zSeries over the last three+ years.

z/VM V5.1 becomes available tomorrow. I don't know if you are
using that or z/VM V4.4, but there is a great new publication
with this release that tries to put most of what you need to know
in one place. Getting Started with Linux on zSeries covers this
process very well. It should (I would expect) be available for
download tomorrow at http://www.vm.ibm.com/pubs/

Jim

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


Re: Planning for IFL and z/VM - looking for directions

2004-09-23 Thread David Boyes
 Currently we are running OS390/2.10 (64bit) going z/OS in a
 month's time.
 We just signed the order for z/VM and IFL. The fun begins soon.
 Has anyone got a checklist or planning guide for setting up
 IFL, z/VM and
 installation of virtual machines?

Some things we do:

Physical:

0) At least 2-3G main storage
1) Ensure that there is at least some XSTORE defined to the LPAR (min
512M or so)
2) Ensure that you have sufficient disk available for paging at least
double the real storage of the LPAR. Have at least one or two volumes
available for spooling.
3) Have at least 2 network devices available (minimum one for the Linux
VSWITCH, one for the underlying VM system, preferably not on the same
physical card if you can swing it).
4) Consider defining a couple of CTCAs between your z/OS LPAR and the VM
LPAR for RSCS and TCPIP use. NJE is ancient, but it's occasionally very
handy for communicating with z/OS.
5) Define at least one physical hipersocket LAN between the VM and the
z/OS partition. You may not want it immediately, but you'll need it
later on when you get some production stuff up.

VM setup:

0) At minimum, be sure to license Perfkit, DIRMaint, DFSMS/VM and RSCS.
TSM is handy, but optional.  You may want RACF, but that's up to you;
there's not a lot of value to it unless your auditors require it.
1) Remove the paging and spooling areas from the IPL volume as soon as
possible. I've found it's also a good idea to move the CP directory off
the IPL volume as well, but not as important as moving page and spool.
2) If given a choice for sizing a CP area (directory, warmstart, ckpt),
take the maximum size. It doesn't hurt, and it saves a lot of grief
later.
3) Grab a copy of the S5INIT package we posted earlier and use it from
the start. It makes startup processing a lot easier to manage.
3.5) Grab a copy of the SSLSERV enabler system we posted and use it --
makes auditors happy that 3270 sessions are encrypted.
4) Take the PERFSVM startup exec and run it from OPERATOR's PROFILE
EXEC. With some minor tweaks to the PerfKit default confiuguration, the
basic mode Perfkit display makes a terrific scrolling operator console.
One tweak that will save a lot of annoyance:

FC PROCESS CPMSG * 'DVHRLY3886I' DISP CPMSGN

(this tells Perfkit to not treat the hourly DIRMAINT processing messages
as held messages that you have to respond to, but just let them scroll
by)
5) Use the SFS setup option when you install CP. SFS is Good Stuff, and
you might as well get the most benefit out of the CMS side of things you
can.


Networking setup:

1) Use VSWITCHes and guest LANs in QDIO mode. Forget anything else ever
existed, unless you want to use the Linux config as front-end to all
your networking (at which point, you add hipersockets). Avoid IUCV and
CTC networking unless absolutely necessary.

2) Consider using one or more Linux guests as a router between an
external VSWITCH DMZ and the internal LANs. See my VM Advanced Network
Services presentation for a proposed network architecture that lets you
do a lot of nice things that the VM stack alone can't do. It does cost
some cycles, but the functionality increase is substantial, and
remember, those cycles aren't coming out of your standard engine cycle
budget...8-).

3) Either get a large block of network addresses from your networking
people right off the bat (2-3 class Cs or more), or use #2 and do IP
masquerading and/or port forwarding.

4) Start negotiating with the networking people NOW to allow you to send
dynamic routing updates from the Linux routers. They're probably not
going to want to do this, but you really, REALLY need to be able to do
this to avoid annoying them constantly about routing problems.


 Before I put some thought into it, I want to learn from those who went
 before me. I will also be scouring some redbooks.

I'm sure there's more, but those are the big stuff I can think of off
the top of my head.

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


Re: Planning for IFL and z/VM - looking for directions

2004-09-23 Thread Michael MacIsaac
Ranga,

 The Redbooks are a great place to start, just make sure you are
 using the most recent.

I'll put in a shameless plug for some stuff I've worked on.  The Domino
redbook has some (hopefully useful and relatively recent) infrastructure
documentation in chapters 3-6:
  http://www.redbooks.ibm.com/abstracts/sg247021.html?Open

Also, using VSWITCH on z/VM can make Linux networking both more available
and easier:
  http://linuxvm.org/present/misc/vswitch.pdf

If you will be using z/VM 5.1 you'll want to also look into the layer-2
VSWITCH.  I believe a redpaper is coming soon with info on this topic.

Hope this helps.

-Mike MacIsaac, IBM  [EMAIL PROTECTED]   (845) 433-7061


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


Re: Planning for IFL and z/VM - looking for directions

2004-09-23 Thread Marcy Cortes
When you order VM, go ahead and get 5.1 so that you're set for a while.

The page/spool are no longer on the res pack with it so you don't have
to worry about that.

Don't let your storage hw folks stick you on escon if you can help it.
FICON is the way to go. 


Marcy Cortes

This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.


-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
David Boyes
Sent: Thursday, September 23, 2004 6:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Planning for IFL and z/VM - looking for
directions

 Currently we are running OS390/2.10 (64bit) going z/OS in a month's 
 time.
 We just signed the order for z/VM and IFL. The fun begins soon.
 Has anyone got a checklist or planning guide for setting up IFL, z/VM 
 and installation of virtual machines?

Some things we do:

Physical:

0) At least 2-3G main storage
1) Ensure that there is at least some XSTORE defined to the LPAR (min
512M or so)
2) Ensure that you have sufficient disk available for paging at least
double the real storage of the LPAR. Have at least one or two volumes
available for spooling.
3) Have at least 2 network devices available (minimum one for the Linux
VSWITCH, one for the underlying VM system, preferably not on the same
physical card if you can swing it).
4) Consider defining a couple of CTCAs between your z/OS LPAR and the VM
LPAR for RSCS and TCPIP use. NJE is ancient, but it's occasionally very
handy for communicating with z/OS.
5) Define at least one physical hipersocket LAN between the VM and the
z/OS partition. You may not want it immediately, but you'll need it
later on when you get some production stuff up.

VM setup:

0) At minimum, be sure to license Perfkit, DIRMaint, DFSMS/VM and RSCS.
TSM is handy, but optional.  You may want RACF, but that's up to you;
there's not a lot of value to it unless your auditors require it.
1) Remove the paging and spooling areas from the IPL volume as soon as
possible. I've found it's also a good idea to move the CP directory off
the IPL volume as well, but not as important as moving page and spool.
2) If given a choice for sizing a CP area (directory, warmstart, ckpt),
take the maximum size. It doesn't hurt, and it saves a lot of grief
later.
3) Grab a copy of the S5INIT package we posted earlier and use it from
the start. It makes startup processing a lot easier to manage.
3.5) Grab a copy of the SSLSERV enabler system we posted and use it --
makes auditors happy that 3270 sessions are encrypted.
4) Take the PERFSVM startup exec and run it from OPERATOR's PROFILE
EXEC. With some minor tweaks to the PerfKit default confiuguration, the
basic mode Perfkit display makes a terrific scrolling operator console.
One tweak that will save a lot of annoyance:

FC PROCESS CPMSG * 'DVHRLY3886I' DISP CPMSGN

(this tells Perfkit to not treat the hourly DIRMAINT processing messages
as held messages that you have to respond to, but just let them scroll
by)
5) Use the SFS setup option when you install CP. SFS is Good Stuff, and
you might as well get the most benefit out of the CMS side of things you
can.


Networking setup:

1) Use VSWITCHes and guest LANs in QDIO mode. Forget anything else ever
existed, unless you want to use the Linux config as front-end to all
your networking (at which point, you add hipersockets). Avoid IUCV and
CTC networking unless absolutely necessary.

2) Consider using one or more Linux guests as a router between an
external VSWITCH DMZ and the internal LANs. See my VM Advanced Network
Services presentation for a proposed network architecture that lets you
do a lot of nice things that the VM stack alone can't do. It does cost
some cycles, but the functionality increase is substantial, and
remember, those cycles aren't coming out of your standard engine cycle
budget...8-).

3) Either get a large block of network addresses from your networking
people right off the bat (2-3 class Cs or more), or use #2 and do IP
masquerading and/or port forwarding.

4) Start negotiating with the networking people NOW to allow you to send
dynamic routing updates from the Linux routers. They're probably not
going to want to do this, but you really, REALLY need to be able to do
this to avoid annoying them constantly about routing problems.


 Before I put some thought into it, I want to learn from those who went

 before me. I will also be scouring some redbooks.

I'm sure there's more, but those are the big stuff I can think of off
the top of my head.

--
For LINUX-390 subscribe / signoff / archive access instructions, send

Re: Planning for IFL and z/VM - looking for directions

2004-09-23 Thread David Boyes
 The page/spool are no longer on the res pack with it so you don't have
 to worry about that.

Woohoo! Hooray!

 Don't let your storage hw folks stick you on escon if you can help it.
 FICON is the way to go.

Particularly the Linux guests -- if you can do FCP disk for those, it's
another Good Thing. Linux really, really, really likes disks in big
chunks that don't have the 390 I/O device size limitations. Putting your
Linux data on SAN-attached FCP disk is a big political plus to adoption
(one could actually make a case that putting *all* the 5.1 system on
non-390 disk would be a political win, but there are some known
configuration recommendations that should be followed if you do this.)

-- db

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


Re: Planning for IFL and z/VM - looking for directions

2004-09-22 Thread Alan Altmark
On Wednesday, 09/22/2004 at 02:30 MST, Ranga Nathan
[EMAIL PROTECTED] wrote:
 Currently we are running OS390/2.10 (64bit) going z/OS in a month's
time.
 We just signed the order for z/VM and IFL. The fun begins soon.
 Has anyone got a checklist or planning guide for setting up IFL, z/VM
and
 installation of virtual machines?
 Before I put some thought into it, I want to learn from those who went
 before me. I will also be scouring some redbooks.

On Friday, go to the VM website and look for some new information.  Among
that information will be a new book Getting Started with Linux on
zSeries that addresses the basics of VM system planning and operation for
the purpose of running Linux guests.

Alan Altmark
Sr. Software Engineer
IBM z/VM Development

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