Just one tongue in cheek comment.

"Given our static environment..."

Has anyone ever known a "static environment" that has remained static?


Mike Wawiorko
 Please consider the environment before printing this e-mail

-----Original Message-----
From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Morris, 
Kevin J. (RET-DAY)
Sent: 01 July 2015 03:19
To: [email protected]
Subject: Migrate zLinux off zVM into standalone LPARs?

We currently have 22 zLinux guests (all running RHEL 6.4) on 7 zVM (v6.2) LPARs 
spread across 6 CECs (29 IFLs in total) all to support numerous environments 
for a single application.
Here is our current zVM LPAR / zLinux guest configuration:
1. Sandbox zVM LPAR - 3 zLinux systems only for Systems Programming use/testing.
2. Test/Dev zVM LPAR - 2 zLinux systems for application development and testing.
3. Prod#1 zVM LPAR - 5 zLinux systems for cert/prod 4. Prod#2 zVM LPAR - 4 
zLinux systems for cert/prod 5. Prod#3 zVM LPAR - 1 zLinux system for prod 6. 
Prod#4 zVM LPAR - 1 zLinux system for prod 7. DR zVM LPAR - 6 zLinux systems 
for prod DR.

At one point we had an additional ~12 zLinux systems throughout these zVM 
LPARs, but they have since been retired.

As a sizeable software cost-savings effort (zVM, RACF, Perfkit, Operations 
Manager), we are planning to migrate these 22 zLinux systems into standalone 
LPARs and eliminate zVM altogether.

I know that we will lose the capability to overcommit/share memory between 
zLinux systems, but the application running in this environment is very 
response-time critical/sensitive so we actually dedicated memory resources to 
our production zLinux systems anyways.  Additionally, after retiring the ~12 
servers, we now have a memory excess on all of our zVM LPARs.
VSWITCH is nice with its automatic failover, etc; however, we have tested the 
linux "bonding driver" and feel it is an adequate replacement.  We are not a 
zVM SSI user.

Also, let me state that the business has no future plans to grow/expand the 
zVM/zLinux environment (including as a virtualization platform for traditional 
x86 workloads).

Given our static environment, can anyone provide any glaringly obvious 
caveats/downfalls to migrating from zVM to standalone zLinux LPARs that we 
might be missing?

Thanks!

Kevin Morris
Reed Elsevier - Technology Services
zOS Systems Engineering


----------------------------------------------------------------------
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
----------------------------------------------------------------------
For more information on Linux on System z, visit http://wiki.linuxvm.org/

This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

Reply via email to