Re: Migrate zLinux off zVM into standalone LPARs?

[Mark Post]

>>> On 11/17/2015 at 10:12 AM, Ray Mansell  wrote: 
> Speaking of disk address changes... how does one cope with that? We have
> a new DS8700 to replace our ancient DS8000s, and I'm wondering what is
> the best way to migrate our LPAR Linux servers to the new box? I'm sure
> this must have been done before, so I'd be very interested to learn how
> others have managed this.

How you cope is going to be determined by how the file systems are referenced 
in /etc/fstab, and whether LVM is being used or not.  What does your setup look 
like?


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: Migrate zLinux off zVM into standalone LPARs?

[Ray Mansell]

Speaking of disk address changes... how does one cope with that? We have
a new DS8700 to replace our ancient DS8000s, and I'm wondering what is
the best way to migrate our LPAR Linux servers to the new box? I'm sure
this must have been done before, so I'd be very interested to learn how
others have managed this.

Ray...

On 7/1/2015 11:51, Stewart, Lee wrote:
> Since you won't have VM to limit which and how many devices each of the 
> Linuxes sees, you may want to consider isolating them from each other via the 
> IOCP.  Also keep in mind that all your addresses will probably change as you 
> move from virtual addresses to real addresses.   And what the Linuxes have 
> created for volsers is probably not unique, and if your DASD is shared with 
> an MVS image, those duplicates will show up there...
>
> Lee Stewart ● VM System Support ● Visa ● Phone:  6(750)4601 - +1-303-389-4601 
> ● lstew...@visa.com
>
>

--
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: Migrate zLinux off zVM into standalone LPARs?

[Alan Altmark]

On Tuesday, 11/17/2015 at 10:14 EST, Ray Mansell  wrote:
> Speaking of disk address changes... how does one cope with that? We have
> a new DS8700 to replace our ancient DS8000s, and I'm wondering what is
> the best way to migrate our LPAR Linux servers to the new box? I'm sure
> this must have been done before, so I'd be very interested to learn how
> others have managed this.

Connect the two together, and let the controllers replicate that data to
the new one, then pull/push.  You obviously need to do this when you can
take the whole environment down.

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: Migrate zLinux off zVM into standalone LPARs?

[Grzegorz Powiedziuk]

If you can't do what Alan said, you can do ddr from z/vm or dd in linux
which have access to both - old and new storage  (the old linux should be
down during the clone process)

There are good chances that it will  ipl fine from new storage.
As Mark mentioned, it might depend how did you set it in fstab. But good
chances are that you use one of these in fstab:

/dev/dasdnx (asking for troubles)
/dev/disk/by-path  (I think most common for non-lvms?)
/dev/mapper/ (if LVM used)
My bet is that you have disk-by-path or/and /dev/mapper/.

If that's the case, no changes to fstab should be needed. It should ipl
without a problem.
When I think about it, disk/by-uuid should also work. Correct me if I am
wrong, but it's just an id of partition which will be cloned with all the
data.

If you use FCP then it's different and longer story.

Gregory Powiedziuk

2015-11-17 13:24 GMT-05:00 Alan Altmark :

> On Tuesday, 11/17/2015 at 10:14 EST, Ray Mansell  wrote:
> > Speaking of disk address changes... how does one cope with that? We have
> > a new DS8700 to replace our ancient DS8000s, and I'm wondering what is
> > the best way to migrate our LPAR Linux servers to the new box? I'm sure
> > this must have been done before, so I'd be very interested to learn how
> > others have managed this.
>
> Connect the two together, and let the controllers replicate that data to
> the new one, then pull/push.  You obviously need to do this when you can
> take the whole environment down.
>
> 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/
>

--
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: Migrate zLinux off zVM into standalone LPARs?

[Marcy Cortes]

It worked for us :)


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ray 
Mansell
Sent: Tuesday, November 17, 2015 1:35 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Migrate zLinux off zVM into standalone LPARs?

Thanks, Marcy - Perhaps I can offload all this effort onto our z/OS admin. I 
rather like the sound of that...

Ray

On 11/17/2015 15:55, Marcy Cortes wrote:
> Changing devices numbers is generally not a problem unless you have lots of 
> dedicated devices.
> SSI needs a bit of work as well if you have that.
>
> DDR is very slow.
> If you have z/OS, any of its utilities are way better.   DFDSS, zDMF (TDMF), 
> or FDR all beat the pants off of DDR.
> Just have to take down your VM & Linux first though.
>
>
>

--
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: Migrate zLinux off zVM into standalone LPARs?

[Ray Mansell]

Thank you Mark, and Alan, and Gregory...

I think our problem is going to be more one of boredom rather than
encountering insurmountable problems, as DDR plods its way through
several hundred volumes. Originally I thought we were going to have to
cope with changing device numbers on the new system, which I believe
would have posed a much more interesting problem, but I think I've
managed to persuade the storage admin that this simply isn't practical.
In any case, it looks as though I will have plenty to occupy my time
between now and the new year.

Thanks again,
Ray

On 11/17/2015 11:07, Mark Post wrote:

On 11/17/2015 at 10:12 AM, Ray Mansell  wrote:

Speaking of disk address changes... how does one cope with that? We have
a new DS8700 to replace our ancient DS8000s, and I'm wondering what is
the best way to migrate our LPAR Linux servers to the new box? I'm sure
this must have been done before, so I'd be very interested to learn how
others have managed this.

How you cope is going to be determined by how the file systems are referenced 
in /etc/fstab, and whether LVM is being used or not.  What does your setup look 
like?


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: Migrate zLinux off zVM into standalone LPARs?

[Marcy Cortes]

Changing devices numbers is generally not a problem unless you have lots of 
dedicated devices.
SSI needs a bit of work as well if you have that.

DDR is very slow.
If you have z/OS, any of its utilities are way better.   DFDSS, zDMF (TDMF), or 
FDR all beat the pants off of DDR.
Just have to take down your VM & Linux first though.


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ray 
Mansell
Sent: Tuesday, November 17, 2015 12:38 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Migrate zLinux off zVM into standalone LPARs?

Thank you Mark, and Alan, and Gregory...

I think our problem is going to be more one of boredom rather than encountering 
insurmountable problems, as DDR plods its way through several hundred volumes. 
Originally I thought we were going to have to cope with changing device numbers 
on the new system, which I believe would have posed a much more interesting 
problem, but I think I've managed to persuade the storage admin that this 
simply isn't practical.
In any case, it looks as though I will have plenty to occupy my time between 
now and the new year.

Thanks again,
Ray

On 11/17/2015 11:07, Mark Post wrote:
>>>> On 11/17/2015 at 10:12 AM, Ray Mansell <r...@mansell.org> wrote:
>> Speaking of disk address changes... how does one cope with that? We 
>> have a new DS8700 to replace our ancient DS8000s, and I'm wondering 
>> what is the best way to migrate our LPAR Linux servers to the new 
>> box? I'm sure this must have been done before, so I'd be very 
>> interested to learn how others have managed this.
> How you cope is going to be determined by how the file systems are referenced 
> in /etc/fstab, and whether LVM is being used or not.  What does your setup 
> look like?
>
>
> 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: Migrate zLinux off zVM into standalone LPARs?

[Rick Troth]

I see two kinds of ECKD DASD in what you're describing: disk with one
partition used as a filesystem, and disk with one partition used as a
"PV" to LVM.

Assuming CDL ("compatible" disk layout) you probably have the device
number prefixed with "0X" as the volser. If you simply DDR from virtual
to physical, you may have duplicates in the complex.

Alternatives to mounting by device number include mounting by Linux
filesystem label or mounting by Linux filesystem UUID. You'll likely
have duplicates with Linux FS labels too, but you almost certainly will
*not* get duplicate UUIDs.

LVM *always* recognizes PVs by UUID and a PV cannot be mounted as a
filesystem. (You have to mount the LV on the other side of the LVM
magic.) The UUID of a filesystem on LV is completely independent of the
UUID of any PVs which provide its backing store.



On 11/17/2015 03:38 PM, Ray Mansell wrote:
> Thank you Mark, and Alan, and Gregory...
>
> I think our problem is going to be more one of boredom rather than
> encountering insurmountable problems, as DDR plods its way through
> several hundred volumes. Originally I thought we were going to have to
> cope with changing device numbers on the new system, which I believe
> would have posed a much more interesting problem, but I think I've
> managed to persuade the storage admin that this simply isn't practical.
> In any case, it looks as though I will have plenty to occupy my time
> between now and the new year.
>
> Thanks again,
> Ray
>
> On 11/17/2015 11:07, Mark Post wrote:
> On 11/17/2015 at 10:12 AM, Ray Mansell  wrote:
>>> Speaking of disk address changes... how does one cope with that? We
>>> have
>>> a new DS8700 to replace our ancient DS8000s, and I'm wondering what is
>>> the best way to migrate our LPAR Linux servers to the new box? I'm sure
>>> this must have been done before, so I'd be very interested to learn how
>>> others have managed this.
>> How you cope is going to be determined by how the file systems are
>> referenced in /etc/fstab, and whether LVM is being used or not.  What
>> does your setup look like?
>>
>>
>> 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: Migrate zLinux off zVM into standalone LPARs?

[Ray Mansell]

Thanks, Marcy - Perhaps I can offload all this effort onto our z/OS
admin. I rather like the sound of that...

Ray

On 11/17/2015 15:55, Marcy Cortes wrote:

Changing devices numbers is generally not a problem unless you have lots of 
dedicated devices.
SSI needs a bit of work as well if you have that.

DDR is very slow.
If you have z/OS, any of its utilities are way better.   DFDSS, zDMF (TDMF), or 
FDR all beat the pants off of DDR.
Just have to take down your VM & Linux first though.





--
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: Migrate zLinux off zVM into standalone LPARs?

[Ejnar Z Rath]

A few comments.

My primary client has 2 ELS's configured with a mix of zVM LPAR's and 
native LPAR's all running RHEL and primarily Oracle RAC.

The Linux admins say that it is difficult to install RHEL in a native 
LPAR without a master/cloner setup in zVM. In addition we are using zVM 
when we want to see performance stats at LPAR level. Apart from that I 
would say we are doing well with the native LPAR's.

Regards,
-- 
Ejnar Zacho Rath
Infrastructure Architect, GTS Next Generation Delivery 
IBM Danmark ApS
Sivlandvænget 29, 2., DK-5260 Odense S, Denmark



From:   Morris, Kevin J. (RET-DAY) kevin.mor...@reedelsevier.com
To: LINUX-390@VM.MARIST.EDU
Date:   01/07/2015 13:56
Subject:Migrate zLinux off zVM into standalone LPARs?
Sent by:Linux on 390 Port LINUX-390@VM.MARIST.EDU



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



Medmindre andet er angivet ovenfor: / Unless Otherwise Stated Above:
IBM Danmark ApS
Kongevejen 495 B
2840 Holte, Danmark
CVR nr.: 65305216

--
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: Migrate zLinux off zVM into standalone LPARs?

[Richard J Moore]

you will forego some facilities afforded by the extra virtualization
layer: live guest relocation, performance monitoring and debugging
capabilities are a few that come to mind. It's configuration flexibility
you give up. Whether this matters to you depends on how static your
environment is and how important these features are to you.

Richard
- -
Z  millicode  zVM development
Ext: (M) 37264807/ (L) 37247072;  Cell: (+44) (0)7739-875237  Office:
(+44) (0)1962-817072
IBM Academy Member -  http://www-03.ibm.com/ibm/academy/index.html
Linkedin Profile
http://uk.linkedin.com/pub/richard-j-moore-fiet-fbcs-ceng-citp/4/4b1/748

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 01/07/2015 03:18:45:

 From: Morris, Kevin J. (RET-DAY) kevin.mor...@reedelsevier.com
 To: LINUX-390@VM.MARIST.EDU
 Date: 01/07/2015 12:56
 Subject: Migrate zLinux off zVM into standalone LPARs?
 Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU

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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
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: Migrate zLinux off zVM into standalone LPARs?

[Berthold Gunreben]

On Wed, 1 Jul 2015 02:18:45 +
Morris, Kevin J. (RET-DAY) kevin.mor...@reedelsevier.com wrote:

 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?

This is not that easy to answer. Things that I would consider are:
- what disk type do you use (minidisks and EDEV might be interesting to
  migrate, new installations are of course always possible)
- what bonding mode do you want to use on linux? With z/VM on z13 you
  will be able to use LACP shared over different z/VM systems. On Linux
  LPAR, if you want to use LACP, the ports must be reserved for the
  LPAR.
- are your DR and backup procedures relying on z/VM?
- Do you use OSA with multiple ports, and do you have requirements that
  a system should not see the other port of the same adapter? On z/VM,
  this can be done, on LPAR it will probably be difficult. 

I don't know the details about cost etc. but I personally would keep at
least one z/VM system to be more flexible with upcoming demands.

Berthold

-- 
--
 Berthold Gunreben  Build Service Team
 http://www.suse.de/ Maxfeldstr. 5
 SUSE Linux GmbHD-90409 Nuernberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton
 HRB 21284 (AG Nürnberg) 

--
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: Migrate zLinux off zVM into standalone LPARs?

[Alan Altmark]

On Wednesday, 07/01/2015 at 07:56 EDT, Morris, Kevin J. (RET-DAY)
kevin.mor...@reedelsevier.com wrote:
 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.

The VSWITCH also provides the security controls to keep a guest from VLAN
hopping.  (Assume Linux has been hacked.)  As long as you have
compensating controls, removing the VSWITCH shouldn't pose any obstacle.

 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?

As long as you remove all z/VM dependencies from the guests (mindisks,
VDISKS, DIAG250 driver, EDEVs, DR, etc.) before you migrate them to their
own LPARs, then you should be fine.  For example, minidisks allowed the
virtual machines to share an I/O configuration.  Your IOCDS will need to
be changed to create limited I/O configurations for each LPAR.

Speaking of IOCDS, how do you plan to manage it?  Standalone IOCP?  Or is
z/OS on these boxes, too?

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: Migrate zLinux off zVM into standalone LPARs?

[Dave Jones]

Hello, Kevin.

That's an interesting direction for your company to take. Can you
elaborate a bit on what drove the decision to not exploit virtualization?

As far as the move from z/VM to bare metal LPARs, I don't see any
potential problems, as long as the LPARs are defined with enough
physical resources to support the zLinux workloads.

Good luck.
DJ

On 06/30/2015 09:18 PM, Morris, Kevin J. (RET-DAY) wrote:
 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 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/


--
Dave Jones
Houston, TX
281.578.7544

--
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: Migrate zLinux off zVM into standalone LPARs?

[Mike Wawiorko]

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:LINUX-390@VM.MARIST.EDU] On Behalf Of Morris, 
Kevin J. (RET-DAY)
Sent: 01 July 2015 03:19
To: LINUX-390@VM.MARIST.EDU
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 
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 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).

Migrate zLinux off zVM into standalone LPARs?

[Morris, Kevin J. (RET-DAY)]

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 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: Migrate zLinux off zVM into standalone LPARs?

[Offer Baruch]

As usually LPARs have a lot of devices connected to them you might want to
start using cio_ignore if you are not already using it.
Not using cio_ignore can really slow down linux startup when the LPAR has a
lot of devices connected to it.
On Jul 1, 2015 5:32 PM, Alan Altmark alan_altm...@us.ibm.com wrote:

 On Wednesday, 07/01/2015 at 07:56 EDT, Morris, Kevin J. (RET-DAY)
 kevin.mor...@reedelsevier.com wrote:
  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.

 The VSWITCH also provides the security controls to keep a guest from VLAN
 hopping.  (Assume Linux has been hacked.)  As long as you have
 compensating controls, removing the VSWITCH shouldn't pose any obstacle.

  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?

 As long as you remove all z/VM dependencies from the guests (mindisks,
 VDISKS, DIAG250 driver, EDEVs, DR, etc.) before you migrate them to their
 own LPARs, then you should be fine.  For example, minidisks allowed the
 virtual machines to share an I/O configuration.  Your IOCDS will need to
 be changed to create limited I/O configurations for each LPAR.

 Speaking of IOCDS, how do you plan to manage it?  Standalone IOCP?  Or is
 z/OS on these boxes, too?

 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/


--
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: Migrate zLinux off zVM into standalone LPARs?

[Stewart, Lee]

Since you won't have VM to limit which and how many devices each of the Linuxes 
sees, you may want to consider isolating them from each other via the IOCP.  
Also keep in mind that all your addresses will probably change as you move from 
virtual addresses to real addresses.   And what the Linuxes have created for 
volsers is probably not unique, and if your DASD is shared with an MVS image, 
those duplicates will show up there...

Lee Stewart ● VM System Support ● Visa ● Phone:  6(750)4601 - +1-303-389-4601 ● 
lstew...@visa.com

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Morris, 
Kevin J. (RET-DAY)
Sent: Tuesday, June 30, 2015 8:19 PM
To: LINUX-390@VM.MARIST.EDU
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 
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: Migrate zLinux off zVM into standalone LPARs?

[Morris, Kevin J. (RET-DAY)]

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

We have had zVM for 10 years, and in the last 8 years we have only retired 
zLinux systems.
Also, our largest zVM LPAR only has 6 zLinux guests with two zVM LPARs only 
having 1 zLinux guest -- almost no point in running zVM in those cases.

 - what disk type do you use (minidisks and EDEV might be interesting to
   migrate, new installations are of course always possible)

Under zVM we use full-volume ECKD minidisks for zLinux storage.  We will simply 
use full-volume ECKD for the LPARs as well.

 - what bonding mode do you want to use on linux? With z/VM on z13 you
   will be able to use LACP shared over different z/VM systems. On Linux
   LPAR, if you want to use LACP, the ports must be reserved for the
  LPAR.

We are planning to use bonding mode 0 (active-backup) with primary reselect.
Can you recommend a preferred mode for load balancing and failover?

 - are your DR and backup procedures relying on z/VM?

Nope. We use Netbackup and a nightly rsync for DR (both at the Linux level).

 - Do you use OSA with multiple ports, and do you have requirements that
   a system should not see the other port of the same adapter? On z/VM,
   this can be done, on LPAR it will probably be difficult.

Yes, we use OSA w/multiple ports but we do not have the visibility requirement.

 That's an interesting direction for your company to take. Can you
 elaborate a bit on what drove the decision to not exploit virtualization?

Yes, we realize that this direction is generally against the normal flow. 
However, the overall business direction is to migrate off of the mainframe 
entirely, and we are under constant pressure to reduce costs in the meantime.
Numerous years ago when the architects were looking at virtualization platforms 
for x86 workloads, the Z solution had a higher TCO, and several of our staple 
products did not have a s390 binary and refused to work with us or IBM to 
release one.

 As long as you remove all z/VM dependencies from the guests (mindisks,
 VDISKS, DIAG250 driver, EDEVs, DR, etc.) before you migrate them to their
 own LPARs, then you should be fine.  For example, minidisks allowed the
 virtual machines to share an I/O configuration.  Your IOCDS will need to
 be changed to create limited I/O configurations for each LPAR.

We set aside a pool of DASD/UCBs for the zVM environment and only gen that 
range to the zVM LPARs.  We will give that same pool to the zLinux LPARs and 
carefully manage access via cio_ignore and /etc/dasd.conf.

 Speaking of IOCDS, how do you plan to manage it?  Standalone IOCP?  Or is
 z/OS on these boxes, too?

Yes, we are primarily a zOS shop (so HCD).  Actually, the application that we 
run on zLinux is CPU-intense assembly code that we cross-assemble with 
Tachyon390 to run in zLinux.  We greatly reduced our zOS software costs by 
moving this CPU-expensive workload onto IFLs.

 As usually LPARs have a lot of devices connected to them you might want to
 start using cio_ignore if you are not already using it.
 Not using cio_ignore can really slow down linux startup when the LPAR has a
 lot of devices connected to it.

We have cio_ignore=all specified in zipl.conf. We add all system-specific 
non-root DASD devices and HyperPAV aliases to /etc/dasd.conf

We have already migrated our Sandbox, DR, and test zLinux systems into 
standalone LPARs.  So far we haven't seen any technical limitations or really 
any negatives to this setup.  Actually, our list of pros is much longer 
than the cons.
I appreciate everyone's responses so far.

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