Re: Configuartion question
To test/install a new VM level, I'd use a secondlevel VM system, no need to devote an LPAR to it. I still find it easier that one can use the host level VM; the main reasons:: - to provide the network to be able to log on to the second-level VM: -- no access to the HMC required to start it up -- even if TCP/IP in the secondlevel fails, I have access - the secondlevel system can easily get (R/O) access to selected minidisks of the host VM with a simple CP LINK command what enables fixing errors in the seciondlevel, and facilitates preparing put in production. However, testing Linuxes (or other guests) in a secondlevel VM system, would incur high CPU overhead. I used such a setup the 20 years I spend with my customer, but I didn't have anything else than CMS users, my SW test installation VM system ran as guest under the main VM production system. It never caused problems. All sysprogs used this test system to install SW. -- Kris Buelens, IBM Belgium, VM customer support
Re: Configuartion question
On Friday, 12/05/2008 at 08:34 EST, Rick Troth [EMAIL PROTECTED] wrote: You've already gotten great advice. I would add that you do NOT need to split your workload between the tiers or zones. It was not completely clear to me, but it sounded like that was one of your expected LPAR splits. You can achieve isolation of the zones without having to run yet more VM partitions. You DO want to partionally isolate your production and test/dev, but you don't need that added complexity to defend a multi-tier architecture. VM insulates virtual machines nicely along zone boundaries. HOWEVER, selling this to your directors, developers, and security people might be difficult. (Assumption: Terry was actually referring to EAL5 when he said UAL5) Only LPARs provide that level of separation. EAL 5 is a reference to the quantity and quality of evidence that IBM has provided to evaluators for the separation of LPARs. In the evaluated configuration, that means no HiperSockets, no shared chpids, and no dynamic I/O. If, rather than discussing assurance levels, we move the discussion to capability, then, yes, z/VM is capable of separating the users. However, the issue inevitably turns to enforcement. (It has each time I have had this same discussion with customers.) That is, how do you ENFORCE the rule that you cannot connect the db server directly to the Internet? Or prevent the servers in tier 1 (Apache) to get to the inTRAnet? The only answer I have found that will consistently satisfy the Chief Security Weasel is one that says: 1. Dynamic I/O SHALL NOT be permitted to any z/VM or z/OS LPAR that is running workload. I/O SHALL be managed from a separate partition. The sysprogs may or may not have access to that partition, depending on the policy of Separation of Duties. (E.g. Only the hardware people can change the hardware I/O config) 2. Internet traffic SHALL be on a separate cable (because it goes to a separate switch). You SHALL NOT use VLANs to separate Internet and Intranet traffic. 3. All traffic between zones SHALL travel via a firewall that is under Network Security management control. This will typically preclude the use of IPtables on Linux and the use of HiperSockets for access to the database server. It also means that for an the web server to talk to the app server the traffic leaves the box, goes throught the firewall, and re-enters. (If you feel faint, sit with your head between your knees. Breathe. This is normal. You'll be fine in a few minutes.) It's ok. 4. Resource access (disks, users, spool, networks,...) SHALL be under the control of a security subsystem that implements mandatory access controls with security labels. This is required to avoid accidental authorization or collusion. This establishes the controls needed to stop, for example, User A (color code 'purple') and User B (color code 'mauve') from establishing any unauthorized communications path with each other (e.g. virtual CTC, IUCV, Guest LAN, VSWITCH, VMCF, shared DCSS, spool, secuser, ...) Only users and resources of the same 'color' can be connected. This mechanism (provided by RACF) has been certified on z/VM to EAL 4+. 5. The sysprog MAY (or may not!) be authorized to manage the security subsystem or the LPAR's settings in the HMC (based, again, on Separation of Duties). This is a subject I spoke on at the zExpo, and will be speaking about again at SHARE in March. Look for Security Zones on z/VM. Alan Altmark z/VM Development IBM Endicott
Re: Configuartion question
Hi Alan, Yes, sorry it should have been EAL 5! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, December 05, 2008 9:15 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Configuartion question On Thursday, 12/04/2008 at 09:00 EST, Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] wrote: We are moving toward taking our POC into production. This workload is moving from Solaris running UNIX. The environment is 3 zone architecture. Our client?s business requirements calls for this 3 zone environment to remain separated. It requires UAL5 security level. Did you mean Common Criteria EAL 5? (I can't find any relevant reference to UAL.) If you actually meant UAL5, can you point me to a reference? Alan Altmark z/VM Development IBM Endicott
Re: Configuartion question
Thanks Alan! This is really what I was looking for. The customer has the EAL 5 requirement and is set up with this requirement in mind in the current Solaris environment (Separate servers for each zone). So I guess regardless of what we can do with VM in terms of running multiple guests and such in this case we are bound by the requirement. Thanks for all of the information from everyone I learned some other interesting things from this! As usual the LIST is a great reference for people like me and I appreciate all who take the time to answer so thoughtfully! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, December 05, 2008 11:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Configuartion question On Friday, 12/05/2008 at 08:34 EST, Rick Troth [EMAIL PROTECTED] wrote: You've already gotten great advice. I would add that you do NOT need to split your workload between the tiers or zones. It was not completely clear to me, but it sounded like that was one of your expected LPAR splits. You can achieve isolation of the zones without having to run yet more VM partitions. You DO want to partionally isolate your production and test/dev, but you don't need that added complexity to defend a multi-tier architecture. VM insulates virtual machines nicely along zone boundaries. HOWEVER, selling this to your directors, developers, and security people might be difficult. (Assumption: Terry was actually referring to EAL5 when he said UAL5) Only LPARs provide that level of separation. EAL 5 is a reference to the quantity and quality of evidence that IBM has provided to evaluators for the separation of LPARs. In the evaluated configuration, that means no HiperSockets, no shared chpids, and no dynamic I/O. If, rather than discussing assurance levels, we move the discussion to capability, then, yes, z/VM is capable of separating the users. However, the issue inevitably turns to enforcement. (It has each time I have had this same discussion with customers.) That is, how do you ENFORCE the rule that you cannot connect the db server directly to the Internet? Or prevent the servers in tier 1 (Apache) to get to the inTRAnet? The only answer I have found that will consistently satisfy the Chief Security Weasel is one that says: 1. Dynamic I/O SHALL NOT be permitted to any z/VM or z/OS LPAR that is running workload. I/O SHALL be managed from a separate partition. The sysprogs may or may not have access to that partition, depending on the policy of Separation of Duties. (E.g. Only the hardware people can change the hardware I/O config) 2. Internet traffic SHALL be on a separate cable (because it goes to a separate switch). You SHALL NOT use VLANs to separate Internet and Intranet traffic. 3. All traffic between zones SHALL travel via a firewall that is under Network Security management control. This will typically preclude the use of IPtables on Linux and the use of HiperSockets for access to the database server. It also means that for an the web server to talk to the app server the traffic leaves the box, goes throught the firewall, and re-enters. (If you feel faint, sit with your head between your knees. Breathe. This is normal. You'll be fine in a few minutes.) It's ok. 4. Resource access (disks, users, spool, networks,...) SHALL be under the control of a security subsystem that implements mandatory access controls with security labels. This is required to avoid accidental authorization or collusion. This establishes the controls needed to stop, for example, User A (color code 'purple') and User B (color code 'mauve') from establishing any unauthorized communications path with each other (e.g. virtual CTC, IUCV, Guest LAN, VSWITCH, VMCF, shared DCSS, spool, secuser, ...) Only users and resources of the same 'color' can be connected. This mechanism (provided by RACF) has been certified on z/VM to EAL 4+. 5. The sysprog MAY (or may not!) be authorized to manage the security subsystem or the LPAR's settings in the HMC (based, again, on Separation of Duties). This is a subject I spoke on at the zExpo, and will be speaking about again at SHARE in March. Look for Security Zones on z/VM. Alan Altmark z/VM Development IBM Endicott
Configuartion question
Hi We are moving toward taking our POC into production. This workload is moving from Solaris running UNIX. The environment is 3 zone architecture. Our client's business requirements calls for this 3 zone environment to remain separated. It requires UAL5 security level. To this end we have six LPARS each sharing 7 IFLS with plenty of real memory on each. One of the six LPARS is our test LPAR that will have multiple levels of VM for testing and such. My question: some of our folks believe that this is an excessive number of LPARS and that it defeats the purpose of VM. Now I understand how VM works and its' ability to virtualize reducing the need for large LPAR configurations. I know that we could, lets' say combine our PROD and VAL/DEV environments that are currently running in separate LPARS into one LPAR and run a second LEVEL VM for the VAL/DEV. My contention is that if it is what is needed to fit the business requirements of the client then having six LPARS is not catastrophic. We have plans for another 16 z/Linux guests to run in the existing configuration in the next few months not requiring additional LPARS. I am not an LPAR bigot. Can anyone comment in general on the pros and cons of running LPARS as opposed to running the multiple environments under one LPAR and getting separation logically by having multi levels of VM rather then physical separation by having the environments running under a single level of VM? In the end it probably will not matter if the client insists that we need to proceed as we are. Just trying to get a prospective of those who are more experienced then myself!! Thanks, Terry
Re: Configuartion question
I would not run linux virtual machines under a 2nd level z/VM for production - including VAL/DEV which, to me, is production, albeit lower case. 3rd level linux is not an ideal production environment. I think IBM would say this is not a production environment. LPARs LPARs LPARs. You can achieve your desired separation of say PROD, VAL, and DEV by putting them onto their own vswitches using different OSA ports, or even over the same OSA ports using vlan while remaining in 1 LPAR. Either way you get complete isolation. I support a few production environments where we have over 35 vswitches coming into the same LPAR to achieve isolation. Running 2nd level z/VM systems is invaluable for testing, servicing, patching, but not as a host for linuxen providing any services. On the issue of LPARs, there is a cost to separating out workloads into multiple LPARs as desirable as this may be. The memory assigned to an LPAR is committed; so if you have a lightly used LPAR its memory is unusable by other LPARs. Splitting workloads out on different LPARs can be useful for HA purposes. If you have some sort of broker or workload balancer running on your physical servers, you can take an LPAR down for maintenance, and still provide application availability on a different LPAR. Highly attractive. David Kreuter From: The IBM z/VM Operating System on behalf of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thu 12/4/2008 8:57 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Configuartion question Hi We are moving toward taking our POC into production. This workload is moving from Solaris running UNIX. The environment is 3 zone architecture. Our client's business requirements calls for this 3 zone environment to remain separated. It requires UAL5 security level. To this end we have six LPARS each sharing 7 IFLS with plenty of real memory on each. One of the six LPARS is our test LPAR that will have multiple levels of VM for testing and such. My question: some of our folks believe that this is an excessive number of LPARS and that it defeats the purpose of VM. Now I understand how VM works and its' ability to virtualize reducing the need for large LPAR configurations. I know that we could, lets' say combine our PROD and VAL/DEV environments that are currently running in separate LPARS into one LPAR and run a second LEVEL VM for the VAL/DEV. My contention is that if it is what is needed to fit the business requirements of the client then having six LPARS is not catastrophic. We have plans for another 16 z/Linux guests to run in the existing configuration in the next few months not requiring additional LPARS. I am not an LPAR bigot. Can anyone comment in general on the pros and cons of running LPARS as opposed to running the multiple environments under one LPAR and getting separation logically by having multi levels of VM rather then physical separation by having the environments running under a single level of VM? In the end it probably will not matter if the client insists that we need to proceed as we are. Just trying to get a prospective of those who are more experienced then myself!! Thanks, Terry
Re: Configuartion question
Terry wrote: We are moving toward taking our POC into production. Good job! If I had my druthers and had only 1 box, I would have a systems programmers LPAR (mine mine mine), a LPAR that ran all of test/dev linuxen, and 1 prod LPAR that ran all of prod. If you do have servers that can't go down very often, run 2 prod lpars, make them acquire a server on each (at least) and figure how some failover (active-active or active-standby). Better if that 2nd prod lpar can be on another box entirely, but if it can't, you'll still have all your capacity if you lose 1 VM lpar due to some VM error (or VM person's error). I'm not sure how your EUAL5 requirements fit in, but you can do lots of things with multiple OSAs, VSWITCHs, VLAN tagging, firewalls, etc. Marcy (with too many LPARs) 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. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, December 04, 2008 5:57 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Configuartion question Hi We are moving toward taking our POC into production. This workload is moving from Solaris running UNIX. The environment is 3 zone architecture. Our client's business requirements calls for this 3 zone environment to remain separated. It requires UAL5 security level. To this end we have six LPARS each sharing 7 IFLS with plenty of real memory on each. One of the six LPARS is our test LPAR that will have multiple levels of VM for testing and such. My question: some of our folks believe that this is an excessive number of LPARS and that it defeats the purpose of VM. Now I understand how VM works and its' ability to virtualize reducing the need for large LPAR configurations. I know that we could, lets' say combine our PROD and VAL/DEV environments that are currently running in separate LPARS into one LPAR and run a second LEVEL VM for the VAL/DEV. My contention is that if it is what is needed to fit the business requirements of the client then having six LPARS is not catastrophic. We have plans for another 16 z/Linux guests to run in the existing configuration in the next few months not requiring additional LPARS. I am not an LPAR bigot. Can anyone comment in general on the pros and cons of running LPARS as opposed to running the multiple environments under one LPAR and getting separation logically by having multi levels of VM rather then physical separation by having the environments running under a single level of VM? In the end it probably will not matter if the client insists that we need to proceed as we are. Just trying to get a prospective of those who are more experienced then myself!! Thanks, Terry
