Re: Moving LUNs using z/VM

[Martha McConaghy]

Just an update - I was able to move the 5 servers and their SAN LUNs over to 
the DS8910 using the EDEV trick.   Thanks for the tip!

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Rick Barlow 

Sent: Tuesday, April 5, 2022 7:30 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

I moved LUNs from a DS8880 in CA to a new DS8910 in OH. I defined EDEVs on
both ends and used PIPEDDR  to send it across TCPIP  most of the way across
the country. I can probably share more details if you need them. a 4G LUN
took about 10 minutes depending on how much real data was there. I even
moved a 400G LUN.

Rick Barlow
Velocity Software, Inc

On Tue, Apr 5, 2022 at 5:47 PM Martha McConaghy 
wrote:

> That's also a good idea.  Thanks, Dave, Alan and Rick!  I think, while I'm
> at it, I could DDR them to file images so I have a back up too.
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of David
> Kreuter 
> Sent: Tuesday, April 5, 2022 5:41 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> Hi Martha
> I did this successfully some years back. Make the input a “full pack “
> mini on edev link it read only to reduce stress.
> Good luck
> Dave
> 
> From: Linux on 390 Port  on behalf of Martha
> McConaghy 
> Sent: Tuesday, April 5, 2022 5:34:22 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> OK, I want to make sure I am understanding it clearly.  Its an interesting
> idea, but I really can't afford to blow away the original disks, so want to
> be really sure.
>
> The existing disks are used by the virtual machine by having LOADDEV
> statements in the directory for the vm and then IPLing the raddr of the
> NPIV port on the FC channel, i.e.:
>
> LOADDEV PORT 500507630628D700
> LOADDEV LUN 40014009
> IPL 2000
>
> Now, the idea is to define an EDEV to VM that points to the same LUN, as
> well as one that points to the new LUN on the DS8910.  Attach both edev
> devices to my machine and then use DDR to copy from the old one to the new
> one.  Very interesting idea.  As long as I don't try to write to the
> original LUN, define a minidisk on it, etc, it should be OK, in theory.
> Has anyone ever tried this?
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of Rick Troth
> 
> Sent: Tuesday, April 5, 2022 5:27 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> What I mean is:
> define them even temporarily as EDEVs for the DDR and go for it.
>
>
>
> On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:
>
> > If they're defined as EDEVs then you can use DDR.
> >
> > FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> > include the boot partition. (Partition tables are not really needed on
> > fixed block disks, even laptop SSDs, but don't get me started.) Any
> > "partition table", and all partitions, would be included in the DDR copy.
> >
> >
> >
> > On Tue, Apr 5, 2022, 17:19 Martha McConaghy  >
> > wrote:
> >
> >> I have a few RHEL servers that run on z/VM but boot off of a direct
> >> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870
> and I
> >> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a
> way
> >> that I could use VM to copy these LUNs to the new storage?   I was
> looking
> >> at DDR, but wasn't sure if the FB-512 type would work for these.  They
> >> aren't CMS format disks, obviously, so that isn't an option.  I'm
> trying to
> >> avoid having to attach them to a Linux server to do the work, but will
> if
> >> that is the only option.  Since these are boot volumes, I have to copy
> the
> >> boot partition and boot record, not just the filesystems.  So, a
> physical
> >> copy would be the best.
> >>
> >> Any ideas?
> >>
> >> Martha
> >>
> >>
> >> Martha McConaghy
> >>
> >> Marist:  System Architect/Technical Lead
> >>
> >> SHARE Association:  Secretary
> >>

Re: Moving LUNs using z/VM

[Christian Borntraeger]

Am 06.04.22 um 17:48 schrieb Rick Troth:

Use 'dd' to copy block device to block device. (The name reminds me of DDR
every time I use it!)


Right. The syntax is a bit odd, but for most things
dd if= of= bs= count=
works.

For disk copy
dd if=/dev/disk/by-id/ of=/dev/disk/by-id/new

should be all that you need.
Then you can even mount,chroot and fixup things when necessary. Before that you 
should then also do blockdev --rereadpt on the target disk so that your LPAR 
understands the new partion table. 1







On Wed, Apr 6, 2022, 11:44 Martha McConaghy 
wrote:


Christian,
Looks like I have a couple of Linux LPARs that I'm going to have to move
to the new storage too.  (I was hoping to be able to retire them, but no
such luck.)  The trick with the EDEV isn't going to work for them (LUNs are
too big).

What would be a good tool to use in Linux to do physical copies of LUNs?
My colleagues usually only deal with copying filesystems, like rsync, which
would not do the trick for me.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Christian
Borntraeger 
Sent: Wednesday, April 6, 2022 1:56 AM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

Am 05.04.22 um 23:19 schrieb Martha McConaghy:

I have a few RHEL servers that run on z/VM but boot off of a direct

attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
that I could use VM to copy these LUNs to the new storage?   I was looking
at DDR, but wasn't sure if the FB-512 type would work for these.  They
aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
avoid having to attach them to a Linux server to do the work, but will if
that is the only option.  Since these are boot volumes, I have to copy the
boot partition and boot record, not just the filesystems.  So, a physical
copy would be the best.

I think your last resort (using a Linux server) is actually  not a bad
idea as direct attached FCP is usually faster than EDEV.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Martha McConaghy]

Certainly makes it easy for us to remember.  

Thanks, I will check it out.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Rick Troth 

Sent: Wednesday, April 6, 2022 11:48 AM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

Use 'dd' to copy block device to block device. (The name reminds me of DDR
every time I use it!)




On Wed, Apr 6, 2022, 11:44 Martha McConaghy 
wrote:

> Christian,
> Looks like I have a couple of Linux LPARs that I'm going to have to move
> to the new storage too.  (I was hoping to be able to retire them, but no
> such luck.)  The trick with the EDEV isn't going to work for them (LUNs are
> too big).
>
> What would be a good tool to use in Linux to do physical copies of LUNs?
> My colleagues usually only deal with copying filesystems, like rsync, which
> would not do the trick for me.
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of Christian
> Borntraeger 
> Sent: Wednesday, April 6, 2022 1:56 AM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> Am 05.04.22 um 23:19 schrieb Martha McConaghy:
> > I have a few RHEL servers that run on z/VM but boot off of a direct
> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
> that I could use VM to copy these LUNs to the new storage?   I was looking
> at DDR, but wasn't sure if the FB-512 type would work for these.  They
> aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
> avoid having to attach them to a Linux server to do the work, but will if
> that is the only option.  Since these are boot volumes, I have to copy the
> boot partition and boot record, not just the filesystems.  So, a physical
> copy would be the best.
>
> I think your last resort (using a Linux server) is actually  not a bad
> idea as direct attached FCP is usually faster than EDEV.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Rick Troth]

Use 'dd' to copy block device to block device. (The name reminds me of DDR
every time I use it!)




On Wed, Apr 6, 2022, 11:44 Martha McConaghy 
wrote:

> Christian,
> Looks like I have a couple of Linux LPARs that I'm going to have to move
> to the new storage too.  (I was hoping to be able to retire them, but no
> such luck.)  The trick with the EDEV isn't going to work for them (LUNs are
> too big).
>
> What would be a good tool to use in Linux to do physical copies of LUNs?
> My colleagues usually only deal with copying filesystems, like rsync, which
> would not do the trick for me.
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of Christian
> Borntraeger 
> Sent: Wednesday, April 6, 2022 1:56 AM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> Am 05.04.22 um 23:19 schrieb Martha McConaghy:
> > I have a few RHEL servers that run on z/VM but boot off of a direct
> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
> that I could use VM to copy these LUNs to the new storage?   I was looking
> at DDR, but wasn't sure if the FB-512 type would work for these.  They
> aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
> avoid having to attach them to a Linux server to do the work, but will if
> that is the only option.  Since these are boot volumes, I have to copy the
> boot partition and boot record, not just the filesystems.  So, a physical
> copy would be the best.
>
> I think your last resort (using a Linux server) is actually  not a bad
> idea as direct attached FCP is usually faster than EDEV.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Martha McConaghy]

Christian,
Looks like I have a couple of Linux LPARs that I'm going to have to move to the 
new storage too.  (I was hoping to be able to retire them, but no such luck.)  
The trick with the EDEV isn't going to work for them (LUNs are too big).

What would be a good tool to use in Linux to do physical copies of LUNs?  My 
colleagues usually only deal with copying filesystems, like rsync, which would 
not do the trick for me.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Christian 
Borntraeger 
Sent: Wednesday, April 6, 2022 1:56 AM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

Am 05.04.22 um 23:19 schrieb Martha McConaghy:
> I have a few RHEL servers that run on z/VM but boot off of a direct attached 
> SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I need to 
> move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way that I 
> could use VM to copy these LUNs to the new storage?   I was looking at DDR, 
> but wasn't sure if the FB-512 type would work for these.  They aren't CMS 
> format disks, obviously, so that isn't an option.  I'm trying to avoid having 
> to attach them to a Linux server to do the work, but will if that is the only 
> option.  Since these are boot volumes, I have to copy the boot partition and 
> boot record, not just the filesystems.  So, a physical copy would be the best.

I think your last resort (using a Linux server) is actually  not a bad idea as 
direct attached FCP is usually faster than EDEV.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Christian Borntraeger]

Am 05.04.22 um 23:19 schrieb Martha McConaghy:

I have a few RHEL servers that run on z/VM but boot off of a direct attached 
SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I need to move 
them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way that I could use 
VM to copy these LUNs to the new storage?   I was looking at DDR, but wasn't 
sure if the FB-512 type would work for these.  They aren't CMS format disks, 
obviously, so that isn't an option.  I'm trying to avoid having to attach them 
to a Linux server to do the work, but will if that is the only option.  Since 
these are boot volumes, I have to copy the boot partition and boot record, not 
just the filesystems.  So, a physical copy would be the best.


I think your last resort (using a Linux server) is actually  not a bad idea as 
direct attached FCP is usually faster than EDEV.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Martha McConaghy]

Thanks, Rick.  That is very cool.  I don't think I'll need PIPEDDR right now, 
since it will be pretty easy for me to have both EDEVs on the same VM system.  
But that is a good trick to keep in mind.  Luckily, none of these LUNs are very 
big, only 120G each.  (Gosh, I remember when I would have thought that was 
huge.)

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Rick Barlow 

Sent: Tuesday, April 5, 2022 7:30 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

I moved LUNs from a DS8880 in CA to a new DS8910 in OH. I defined EDEVs on
both ends and used PIPEDDR  to send it across TCPIP  most of the way across
the country. I can probably share more details if you need them. a 4G LUN
took about 10 minutes depending on how much real data was there. I even
moved a 400G LUN.

Rick Barlow
Velocity Software, Inc

On Tue, Apr 5, 2022 at 5:47 PM Martha McConaghy 
wrote:

> That's also a good idea.  Thanks, Dave, Alan and Rick!  I think, while I'm
> at it, I could DDR them to file images so I have a back up too.
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of David
> Kreuter 
> Sent: Tuesday, April 5, 2022 5:41 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> Hi Martha
> I did this successfully some years back. Make the input a “full pack “
> mini on edev link it read only to reduce stress.
> Good luck
> Dave
> 
> From: Linux on 390 Port  on behalf of Martha
> McConaghy 
> Sent: Tuesday, April 5, 2022 5:34:22 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> OK, I want to make sure I am understanding it clearly.  Its an interesting
> idea, but I really can't afford to blow away the original disks, so want to
> be really sure.
>
> The existing disks are used by the virtual machine by having LOADDEV
> statements in the directory for the vm and then IPLing the raddr of the
> NPIV port on the FC channel, i.e.:
>
> LOADDEV PORT 500507630628D700
> LOADDEV LUN 40014009
> IPL 2000
>
> Now, the idea is to define an EDEV to VM that points to the same LUN, as
> well as one that points to the new LUN on the DS8910.  Attach both edev
> devices to my machine and then use DDR to copy from the old one to the new
> one.  Very interesting idea.  As long as I don't try to write to the
> original LUN, define a minidisk on it, etc, it should be OK, in theory.
> Has anyone ever tried this?
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of Rick Troth
> 
> Sent: Tuesday, April 5, 2022 5:27 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> What I mean is:
> define them even temporarily as EDEVs for the DDR and go for it.
>
>
>
> On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:
>
> > If they're defined as EDEVs then you can use DDR.
> >
> > FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> > include the boot partition. (Partition tables are not really needed on
> > fixed block disks, even laptop SSDs, but don't get me started.) Any
> > "partition table", and all partitions, would be included in the DDR copy.
> >
> >
> >
> > On Tue, Apr 5, 2022, 17:19 Martha McConaghy  >
> > wrote:
> >
> >> I have a few RHEL servers that run on z/VM but boot off of a direct
> >> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870
> and I
> >> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a
> way
> >> that I could use VM to copy these LUNs to the new storage?   I was
> looking
> >> at DDR, but wasn't sure if the FB-512 type would work for these.  They
> >> aren't CMS format disks, obviously, so that isn't an option.  I'm
> trying to
> >> avoid having to attach them to a Linux server to do the work, but will
> if
> >> that is the only option.  Since these are boot volumes, I have to copy
> the
> >> boot partition and boot record, not just the filesystems.  So, a
> physical
> >> copy would be the best.
> >>
> >> Any ideas?
> >>
> >> Martha
> >

Re: Moving LUNs using z/VM

[Alan Altmark]

Yes, there’s a limit.   1 TB.

Regards,
Alan

Alan Altmark
IBM Systems Lab Services
Endicott, NY USA

> On Apr 5, 2022, at 6:02 PM, Neale Ferguson  wrote:
> 
> Is there a maximum edev size?
> 
> 
> 
> You can copy the LUNs with DDR, but you have to first define an EDEVICE for 
> them.
> 
> Regards,
> Alan
> 
> Alan Altmark
> Senior Managing z/VM Consultant
> IBM Systems Lab Services
> 1 607 321 7556 Mobile
> alan_altm...@us.ibm.com
> 
>> -Original Message-
>> From: Linux on 390 Port  On Behalf Of
>> Martha McConaghy
>> Sent: Tuesday, April 5, 2022 5:20 PM
>> To: LINUX-390@VM.MARIST.EDU
>> Subject: [EXTERNAL] [LINUX-390] Moving LUNs using z/VM
>> 
>> I have a few RHEL servers that run on z/VM but boot off of a direct attached
>> SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I need to
>> move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way that I
>> could use VM to copy these LUNs to the new storage?   I was looking at DDR,
>> but wasn't sure if the FB-512 type would work for these.  They aren't CMS
>> format disks, obviously, so that isn't an option.  I'm trying to avoid 
>> having to
>> attach them to a Linux server to do the work, but will if that is the only
>> option.  Since these are boot volumes, I have to copy the boot partition and
>> boot record, not just the filesystems.  So, a physical copy would be the 
>> best.
>> 
>> Any ideas?
> 
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390 
> 
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Rick Barlow]

I moved LUNs from a DS8880 in CA to a new DS8910 in OH. I defined EDEVs on
both ends and used PIPEDDR  to send it across TCPIP  most of the way across
the country. I can probably share more details if you need them. a 4G LUN
took about 10 minutes depending on how much real data was there. I even
moved a 400G LUN.

Rick Barlow
Velocity Software, Inc

On Tue, Apr 5, 2022 at 5:47 PM Martha McConaghy 
wrote:

> That's also a good idea.  Thanks, Dave, Alan and Rick!  I think, while I'm
> at it, I could DDR them to file images so I have a back up too.
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of David
> Kreuter 
> Sent: Tuesday, April 5, 2022 5:41 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> Hi Martha
> I did this successfully some years back. Make the input a “full pack “
> mini on edev link it read only to reduce stress.
> Good luck
> Dave
> 
> From: Linux on 390 Port  on behalf of Martha
> McConaghy 
> Sent: Tuesday, April 5, 2022 5:34:22 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> OK, I want to make sure I am understanding it clearly.  Its an interesting
> idea, but I really can't afford to blow away the original disks, so want to
> be really sure.
>
> The existing disks are used by the virtual machine by having LOADDEV
> statements in the directory for the vm and then IPLing the raddr of the
> NPIV port on the FC channel, i.e.:
>
> LOADDEV PORT 500507630628D700
> LOADDEV LUN 40014009
> IPL 2000
>
> Now, the idea is to define an EDEV to VM that points to the same LUN, as
> well as one that points to the new LUN on the DS8910.  Attach both edev
> devices to my machine and then use DDR to copy from the old one to the new
> one.  Very interesting idea.  As long as I don't try to write to the
> original LUN, define a minidisk on it, etc, it should be OK, in theory.
> Has anyone ever tried this?
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of Rick Troth
> 
> Sent: Tuesday, April 5, 2022 5:27 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> What I mean is:
> define them even temporarily as EDEVs for the DDR and go for it.
>
>
>
> On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:
>
> > If they're defined as EDEVs then you can use DDR.
> >
> > FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> > include the boot partition. (Partition tables are not really needed on
> > fixed block disks, even laptop SSDs, but don't get me started.) Any
> > "partition table", and all partitions, would be included in the DDR copy.
> >
> >
> >
> > On Tue, Apr 5, 2022, 17:19 Martha McConaghy  >
> > wrote:
> >
> >> I have a few RHEL servers that run on z/VM but boot off of a direct
> >> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870
> and I
> >> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a
> way
> >> that I could use VM to copy these LUNs to the new storage?   I was
> looking
> >> at DDR, but wasn't sure if the FB-512 type would work for these.  They
> >> aren't CMS format disks, obviously, so that isn't an option.  I'm
> trying to
> >> avoid having to attach them to a Linux server to do the work, but will
> if
> >> that is the only option.  Since these are boot volumes, I have to copy
> the
> >> boot partition and boot record, not just the filesystems.  So, a
> physical
> >> copy would be the best.
> >>
> >> Any ideas?
> >>
> >> Martha
> >>
> >>
> >> Martha McConaghy
> >>
> >> Marist:  System Architect/Technical Lead
> >>
> >> SHARE Association:  Secretary
> >>
> >> Marist College IT
> >>
> >> Poughkeepsie, NY 12601
> >>
> >>
> >> --
> >> For LINUX-390 subscribe / signoff / archive access instructions,
> >> send email to lists...@vm.marist.edu with the message: INFO LINUX-390
> or
> >> visit
> >> http://www2.marist.edu/htbin/wlvindex?LINUX-390
> >>
> 

Re: Moving LUNs using z/VM

[Rick Troth]

If you have the space, YES, copy them also to file images. Good idea.

This is the beauty of FBA. There's nothing out of band, just the bytes. No
track and record structure to maintain.



On Tue, Apr 5, 2022, 17:46 Martha McConaghy 
wrote:

> That's also a good idea.  Thanks, Dave, Alan and Rick!  I think, while I'm
> at it, I could DDR them to file images so I have a back up too.
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of David
> Kreuter 
> Sent: Tuesday, April 5, 2022 5:41 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> Hi Martha
> I did this successfully some years back. Make the input a “full pack “
> mini on edev link it read only to reduce stress.
> Good luck
> Dave
> 
> From: Linux on 390 Port  on behalf of Martha
> McConaghy 
> Sent: Tuesday, April 5, 2022 5:34:22 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> OK, I want to make sure I am understanding it clearly.  Its an interesting
> idea, but I really can't afford to blow away the original disks, so want to
> be really sure.
>
> The existing disks are used by the virtual machine by having LOADDEV
> statements in the directory for the vm and then IPLing the raddr of the
> NPIV port on the FC channel, i.e.:
>
> LOADDEV PORT 500507630628D700
> LOADDEV LUN 40014009
> IPL 2000
>
> Now, the idea is to define an EDEV to VM that points to the same LUN, as
> well as one that points to the new LUN on the DS8910.  Attach both edev
> devices to my machine and then use DDR to copy from the old one to the new
> one.  Very interesting idea.  As long as I don't try to write to the
> original LUN, define a minidisk on it, etc, it should be OK, in theory.
> Has anyone ever tried this?
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
> 
> From: Linux on 390 Port  on behalf of Rick Troth
> 
> Sent: Tuesday, April 5, 2022 5:27 PM
> To: LINUX-390@VM.MARIST.EDU 
> Subject: Re: Moving LUNs using z/VM
>
> What I mean is:
> define them even temporarily as EDEVs for the DDR and go for it.
>
>
>
> On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:
>
> > If they're defined as EDEVs then you can use DDR.
> >
> > FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> > include the boot partition. (Partition tables are not really needed on
> > fixed block disks, even laptop SSDs, but don't get me started.) Any
> > "partition table", and all partitions, would be included in the DDR copy.
> >
> >
> >
> > On Tue, Apr 5, 2022, 17:19 Martha McConaghy  >
> > wrote:
> >
> >> I have a few RHEL servers that run on z/VM but boot off of a direct
> >> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870
> and I
> >> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a
> way
> >> that I could use VM to copy these LUNs to the new storage?   I was
> looking
> >> at DDR, but wasn't sure if the FB-512 type would work for these.  They
> >> aren't CMS format disks, obviously, so that isn't an option.  I'm
> trying to
> >> avoid having to attach them to a Linux server to do the work, but will
> if
> >> that is the only option.  Since these are boot volumes, I have to copy
> the
> >> boot partition and boot record, not just the filesystems.  So, a
> physical
> >> copy would be the best.
> >>
> >> Any ideas?
> >>
> >> Martha
> >>
> >>
> >> Martha McConaghy
> >>
> >> Marist:  System Architect/Technical Lead
> >>
> >> SHARE Association:  Secretary
> >>
> >> Marist College IT
> >>
> >> Poughkeepsie, NY 12601
> >>
> >>
> >> --
> >> For LINUX-390 subscribe / signoff / archive access instructions,
> >> send email to lists...@vm.marist.edu with the message: INFO LINUX-390
> or
> >> visit
> >> http://www2.marist.edu/htbin/wlvindex?LINUX-390
> >>
> >
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send emai

Re: Moving LUNs using z/VM

[Martha McConaghy]

I have not been able to define an EDEV larger than 1TB without getting errors.  
However, I have not tired it with z/VM 7.2 yet.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Neale Ferguson 

Sent: Tuesday, April 5, 2022 6:01 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

Is there a maximum edev size?



You can copy the LUNs with DDR, but you have to first define an EDEVICE for 
them.

Regards,
Alan

Alan Altmark
Senior Managing z/VM Consultant
IBM Systems Lab Services
1 607 321 7556 Mobile
alan_altm...@us.ibm.com

> -Original Message-
> From: Linux on 390 Port  On Behalf Of
> Martha McConaghy
> Sent: Tuesday, April 5, 2022 5:20 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: [EXTERNAL] [LINUX-390] Moving LUNs using z/VM
>
> I have a few RHEL servers that run on z/VM but boot off of a direct attached
> SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I need to
> move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way that I
> could use VM to copy these LUNs to the new storage?   I was looking at DDR,
> but wasn't sure if the FB-512 type would work for these.  They aren't CMS
> format disks, obviously, so that isn't an option.  I'm trying to avoid having 
> to
> attach them to a Linux server to do the work, but will if that is the only
> option.  Since these are boot volumes, I have to copy the boot partition and
> boot record, not just the filesystems.  So, a physical copy would be the best.
>
> Any ideas?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Neale Ferguson]

Is there a maximum edev size?



You can copy the LUNs with DDR, but you have to first define an EDEVICE for 
them.

Regards,
Alan

Alan Altmark
Senior Managing z/VM Consultant
IBM Systems Lab Services
1 607 321 7556 Mobile
alan_altm...@us.ibm.com

> -Original Message-
> From: Linux on 390 Port  On Behalf Of
> Martha McConaghy
> Sent: Tuesday, April 5, 2022 5:20 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: [EXTERNAL] [LINUX-390] Moving LUNs using z/VM
>
> I have a few RHEL servers that run on z/VM but boot off of a direct attached
> SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I need to
> move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way that I
> could use VM to copy these LUNs to the new storage?   I was looking at DDR,
> but wasn't sure if the FB-512 type would work for these.  They aren't CMS
> format disks, obviously, so that isn't an option.  I'm trying to avoid having 
> to
> attach them to a Linux server to do the work, but will if that is the only
> option.  Since these are boot volumes, I have to copy the boot partition and
> boot record, not just the filesystems.  So, a physical copy would be the best.
>
> Any ideas?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Martha McConaghy]

That's also a good idea.  Thanks, Dave, Alan and Rick!  I think, while I'm at 
it, I could DDR them to file images so I have a back up too.

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of David Kreuter 

Sent: Tuesday, April 5, 2022 5:41 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

Hi Martha
I did this successfully some years back. Make the input a “full pack “ mini on 
edev link it read only to reduce stress.
Good luck
Dave

From: Linux on 390 Port  on behalf of Martha McConaghy 

Sent: Tuesday, April 5, 2022 5:34:22 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

OK, I want to make sure I am understanding it clearly.  Its an interesting 
idea, but I really can't afford to blow away the original disks, so want to be 
really sure.

The existing disks are used by the virtual machine by having LOADDEV statements 
in the directory for the vm and then IPLing the raddr of the NPIV port on the 
FC channel, i.e.:

LOADDEV PORT 500507630628D700
LOADDEV LUN 40014009
IPL 2000

Now, the idea is to define an EDEV to VM that points to the same LUN, as well 
as one that points to the new LUN on the DS8910.  Attach both edev devices to 
my machine and then use DDR to copy from the old one to the new one.  Very 
interesting idea.  As long as I don't try to write to the original LUN, define 
a minidisk on it, etc, it should be OK, in theory.  Has anyone ever tried this?

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Rick Troth 

Sent: Tuesday, April 5, 2022 5:27 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

What I mean is:
define them even temporarily as EDEVs for the DDR and go for it.



On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:

> If they're defined as EDEVs then you can use DDR.
>
> FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> include the boot partition. (Partition tables are not really needed on
> fixed block disks, even laptop SSDs, but don't get me started.) Any
> "partition table", and all partitions, would be included in the DDR copy.
>
>
>
> On Tue, Apr 5, 2022, 17:19 Martha McConaghy 
> wrote:
>
>> I have a few RHEL servers that run on z/VM but boot off of a direct
>> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
>> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
>> that I could use VM to copy these LUNs to the new storage?   I was looking
>> at DDR, but wasn't sure if the FB-512 type would work for these.  They
>> aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
>> avoid having to attach them to a Linux server to do the work, but will if
>> that is the only option.  Since these are boot volumes, I have to copy the
>> boot partition and boot record, not just the filesystems.  So, a physical
>> copy would be the best.
>>
>> Any ideas?
>>
>> Martha
>>
>>
>> Martha McConaghy
>>
>> Marist:  System Architect/Technical Lead
>>
>> SHARE Association:  Secretary
>>
>> Marist College IT
>>
>> Poughkeepsie, NY 12601
>>
>>
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions,
>> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
>> visit
>> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>>
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[David Kreuter]

Hi Martha
I did this successfully some years back. Make the input a “full pack “ mini on 
edev link it read only to reduce stress.
Good luck
Dave

From: Linux on 390 Port  on behalf of Martha McConaghy 

Sent: Tuesday, April 5, 2022 5:34:22 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

OK, I want to make sure I am understanding it clearly.  Its an interesting 
idea, but I really can't afford to blow away the original disks, so want to be 
really sure.

The existing disks are used by the virtual machine by having LOADDEV statements 
in the directory for the vm and then IPLing the raddr of the NPIV port on the 
FC channel, i.e.:

LOADDEV PORT 500507630628D700
LOADDEV LUN 40014009
IPL 2000

Now, the idea is to define an EDEV to VM that points to the same LUN, as well 
as one that points to the new LUN on the DS8910.  Attach both edev devices to 
my machine and then use DDR to copy from the old one to the new one.  Very 
interesting idea.  As long as I don't try to write to the original LUN, define 
a minidisk on it, etc, it should be OK, in theory.  Has anyone ever tried this?

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Rick Troth 

Sent: Tuesday, April 5, 2022 5:27 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

What I mean is:
define them even temporarily as EDEVs for the DDR and go for it.



On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:

> If they're defined as EDEVs then you can use DDR.
>
> FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> include the boot partition. (Partition tables are not really needed on
> fixed block disks, even laptop SSDs, but don't get me started.) Any
> "partition table", and all partitions, would be included in the DDR copy.
>
>
>
> On Tue, Apr 5, 2022, 17:19 Martha McConaghy 
> wrote:
>
>> I have a few RHEL servers that run on z/VM but boot off of a direct
>> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
>> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
>> that I could use VM to copy these LUNs to the new storage?   I was looking
>> at DDR, but wasn't sure if the FB-512 type would work for these.  They
>> aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
>> avoid having to attach them to a Linux server to do the work, but will if
>> that is the only option.  Since these are boot volumes, I have to copy the
>> boot partition and boot record, not just the filesystems.  So, a physical
>> copy would be the best.
>>
>> Any ideas?
>>
>> Martha
>>
>>
>> Martha McConaghy
>>
>> Marist:  System Architect/Technical Lead
>>
>> SHARE Association:  Secretary
>>
>> Marist College IT
>>
>> Poughkeepsie, NY 12601
>>
>>
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions,
>> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
>> visit
>> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>>
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Martha McConaghy]

OK, I want to make sure I am understanding it clearly.  Its an interesting 
idea, but I really can't afford to blow away the original disks, so want to be 
really sure.

The existing disks are used by the virtual machine by having LOADDEV statements 
in the directory for the vm and then IPLing the raddr of the NPIV port on the 
FC channel, i.e.:

LOADDEV PORT 500507630628D700
LOADDEV LUN 40014009
IPL 2000

Now, the idea is to define an EDEV to VM that points to the same LUN, as well 
as one that points to the new LUN on the DS8910.  Attach both edev devices to 
my machine and then use DDR to copy from the old one to the new one.  Very 
interesting idea.  As long as I don't try to write to the original LUN, define 
a minidisk on it, etc, it should be OK, in theory.  Has anyone ever tried this?

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


From: Linux on 390 Port  on behalf of Rick Troth 

Sent: Tuesday, April 5, 2022 5:27 PM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving LUNs using z/VM

What I mean is:
define them even temporarily as EDEVs for the DDR and go for it.



On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:

> If they're defined as EDEVs then you can use DDR.
>
> FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> include the boot partition. (Partition tables are not really needed on
> fixed block disks, even laptop SSDs, but don't get me started.) Any
> "partition table", and all partitions, would be included in the DDR copy.
>
>
>
> On Tue, Apr 5, 2022, 17:19 Martha McConaghy 
> wrote:
>
>> I have a few RHEL servers that run on z/VM but boot off of a direct
>> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
>> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
>> that I could use VM to copy these LUNs to the new storage?   I was looking
>> at DDR, but wasn't sure if the FB-512 type would work for these.  They
>> aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
>> avoid having to attach them to a Linux server to do the work, but will if
>> that is the only option.  Since these are boot volumes, I have to copy the
>> boot partition and boot record, not just the filesystems.  So, a physical
>> copy would be the best.
>>
>> Any ideas?
>>
>> Martha
>>
>>
>> Martha McConaghy
>>
>> Marist:  System Architect/Technical Lead
>>
>> SHARE Association:  Secretary
>>
>> Marist College IT
>>
>> Poughkeepsie, NY 12601
>>
>>
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions,
>> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
>> visit
>> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>>
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Rick Troth]

What I mean is:
define them even temporarily as EDEVs for the DDR and go for it.



On Tue, Apr 5, 2022, 17:25 Rick Troth  wrote:

> If they're defined as EDEVs then you can use DDR.
>
> FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
> include the boot partition. (Partition tables are not really needed on
> fixed block disks, even laptop SSDs, but don't get me started.) Any
> "partition table", and all partitions, would be included in the DDR copy.
>
>
>
> On Tue, Apr 5, 2022, 17:19 Martha McConaghy 
> wrote:
>
>> I have a few RHEL servers that run on z/VM but boot off of a direct
>> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
>> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
>> that I could use VM to copy these LUNs to the new storage?   I was looking
>> at DDR, but wasn't sure if the FB-512 type would work for these.  They
>> aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
>> avoid having to attach them to a Linux server to do the work, but will if
>> that is the only option.  Since these are boot volumes, I have to copy the
>> boot partition and boot record, not just the filesystems.  So, a physical
>> copy would be the best.
>>
>> Any ideas?
>>
>> Martha
>>
>>
>> Martha McConaghy
>>
>> Marist:  System Architect/Technical Lead
>>
>> SHARE Association:  Secretary
>>
>> Marist College IT
>>
>> Poughkeepsie, NY 12601
>>
>>
>> --
>> For LINUX-390 subscribe / signoff / archive access instructions,
>> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
>> visit
>> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>>
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Alan Altmark]

You can copy the LUNs with DDR, but you have to first define an EDEVICE for 
them. 

Regards,
Alan

Alan Altmark
Senior Managing z/VM Consultant
IBM Systems Lab Services
1 607 321 7556 Mobile
alan_altm...@us.ibm.com

> -Original Message-
> From: Linux on 390 Port  On Behalf Of
> Martha McConaghy
> Sent: Tuesday, April 5, 2022 5:20 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: [EXTERNAL] [LINUX-390] Moving LUNs using z/VM
> 
> I have a few RHEL servers that run on z/VM but boot off of a direct attached
> SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I need to
> move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way that I
> could use VM to copy these LUNs to the new storage?   I was looking at DDR,
> but wasn't sure if the FB-512 type would work for these.  They aren't CMS
> format disks, obviously, so that isn't an option.  I'm trying to avoid having 
> to
> attach them to a Linux server to do the work, but will if that is the only
> option.  Since these are boot volumes, I have to copy the boot partition and
> boot record, not just the filesystems.  So, a physical copy would be the best.
> 
> Any ideas?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving LUNs using z/VM

[Rick Troth]

If they're defined as EDEVs then you can use DDR.

FBA (EDEV or 3370, etc al) being fixed block, copying the whole disk will
include the boot partition. (Partition tables are not really needed on
fixed block disks, even laptop SSDs, but don't get me started.) Any
"partition table", and all partitions, would be included in the DDR copy.



On Tue, Apr 5, 2022, 17:19 Martha McConaghy 
wrote:

> I have a few RHEL servers that run on z/VM but boot off of a direct
> attached SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I
> need to move them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way
> that I could use VM to copy these LUNs to the new storage?   I was looking
> at DDR, but wasn't sure if the FB-512 type would work for these.  They
> aren't CMS format disks, obviously, so that isn't an option.  I'm trying to
> avoid having to attach them to a Linux server to do the work, but will if
> that is the only option.  Since these are boot volumes, I have to copy the
> boot partition and boot record, not just the filesystems.  So, a physical
> copy would be the best.
>
> Any ideas?
>
> Martha
>
>
> Martha McConaghy
>
> Marist:  System Architect/Technical Lead
>
> SHARE Association:  Secretary
>
> Marist College IT
>
> Poughkeepsie, NY 12601
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Moving LUNs using z/VM

[Martha McConaghy]

I have a few RHEL servers that run on z/VM but boot off of a direct attached 
SAN LUN (not an EDEV or ECKD).  They reside on an old DS8870 and I need to move 
them to a new DS8910.  (No PPRC, GDPS, etc.)  Is there a way that I could use 
VM to copy these LUNs to the new storage?   I was looking at DDR, but wasn't 
sure if the FB-512 type would work for these.  They aren't CMS format disks, 
obviously, so that isn't an option.  I'm trying to avoid having to attach them 
to a Linux server to do the work, but will if that is the only option.  Since 
these are boot volumes, I have to copy the boot partition and boot record, not 
just the filesystems.  So, a physical copy would be the best.

Any ideas?

Martha


Martha McConaghy

Marist:  System Architect/Technical Lead

SHARE Association:  Secretary

Marist College IT

Poughkeepsie, NY 12601


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Timothy Sipples]

I'd like to point out that there's a general trend toward workload
containerization, and a big driver is that it's easier to move container
images around than whole operating system instances. Thus if you shift
workloads into container images, you should end up with fewer, skinnier OS
instances that you don't care as much about moving around since it's easy
enough to (re)create them. That's the theory, anyway.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.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://www2.marist.edu/htbin/wlvindex?LINUX-390


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Moving a Linux guest from z/VM to KVM?

[Alan Haff]

Closing the loop... I got the system up and running under KVM. I hadn't seen 
Viktor's message yet but I did basically the same steps.

Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Viktor 
Mihajlovski:

>I assume it's SLES,

It is. I'm starting with a SLES guest but I have RHEL guests that I want to 
move as well.

>...because as far as I know, with RHEL the virtio drivers are mandatory.

Good to know. That'll make things easier for the RHEL systems.

>Should work if you add the following lines to /etc/dracut.conf (before
>cloning):
>
>  add_dracutmodules+="dasd_rules"
>  add_drivers+="virtio_blk dasd_eckd_mod"

I added a lot more drivers because I compared the list of loaded drivers on a 
system that I built from scratch under KVM with the loaded drivers on the z/VM 
guest I wanted to move and added all of the missing drivers.

add_drivers+="cdrom crc32_vx_s390 failover net_failover rng_core sr_mod 
virtio_balloon virtio_blk virtio_net virtio_rng virtio_scsi"

Probably overkill. I'll try again with just virtio_blk. 

>and then run
>  dracut -f
>  grub2-zipl-setup

I wanted to update grub to remove the resume=... from 
GRUB_CMDLINE_LINUX_DEFAULT so I ran grub2-mkconfig instead of dracut, then 
grub2-zipl-setup to get zipl updated.

The rest of the process went quite smoothly. After I made the changes on the 
z/VM guest I shut it down, re-cloned the DASD, and then IPLed the guest on KVM. 
When it came up I logged on to the console to create the config for the new 
network device and I was good to go.


Thanks everyone for your help...



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Mike Friesenegger]

On 11/30/20 11:34 PM, Christian Borntraeger wrote:

On 30.11.20 21:10, Mark Post wrote:

On 11/30/20 1:16 PM, Alan Haff wrote:

I have a number of Linux guests running under z/VM. I'd like to move some of 
them to a KVM host running in another LPAR. Naively I tried DDRing a guest's 
disks to new volumes and IPLing off of the new volumes. No luck, the virtio 
modules aren't available in the guest so it can't see any DASD.

Has someone put together a recipe for moving a guest from z/VM to KVM? Or am I 
heading down a dead end?

I'm not aware of one, but I wouldn't call it a dead end, either. As a
first step, I would rebuild the initrd with whatever parameters are
needed to include the virtio drivers, then try again. I have to think
that /etc/fstab entries would need to be looked at as well.

Look at the virtualization cookbook 5 from the redbooks.
http://www.redbooks.ibm.com/abstracts/sg248463.html?Open

chapter 8.7 contains information how to configure a system as such that it can
be moved forth and back between LPAR and KVM. That should then also be possible
with z/VM. If done right that should allow you to move the guest forth and back
between KVM and z/VM.

Basic idea:
make sure the initrd has classic (DASD) drivers and the virtio-blk driver and
then use driver independent names for the partitions.

CC Viktor, do we still have our presentation flying around somewhere?

I co-authored Chapter 8 and did much of the testing.  I agree with 
Christian that z/VM -> KVM is possible.


Chapter 8 starts with a SLES KVM VM running on a SLES KVM host running 
in an LPAR.  The SLES OS is installed on FCP SCSI disks. The KVM VM and 
host are shutdown and the SLES OS on the SCSI disk is IPL'd in the same 
LPAR.  Using DDR to duplicate the z/VM guest to the new DASDs on your 
KVM host is a good first step.  The good thing about this approach is 
that you can continue to run the z/VM guest as you work through the 
hurdles to get the KVM host to boot.


I suggest keeping the device ids of the OS disks defined in the KVM 
guest the same as it is in z/VM.  I encourage you to review the 
virt-install command in the shell script in Appendix B as an example how 
to define the KVM VM.


I would define the NIC with the same device id but add that to a NAT'd 
KVM network.  This will allow the network of the new KVM VM to start but 
will not step all over the IP address being used while the z/VM guest is 
running at the same time.


I also agree with Mark that it might be necessary to rebuild the initrd 
so that virtio drivers are available during IPL.


Regards,

Mike

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Viktor Mihajlovski]

On 12/1/20 5:25 PM, Alan Haff wrote:

Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Richard J Moore:


In this case I think you're saying have two configurations - one under KVM
and another under zVM. Then manually co-ordinate the sharing or resources
but ensure that you don't have both guests logged on simultaneously.


Right. Both LPARs - the one running z/VM and the one running KVM - share the 
same DS8800. I created new volumes, shutdown the z/VM guest, cloned the z/VM 
guest's DASD to the new volumes, and then brought the new volumes online to the 
KVM LPAR and attempted to IPL the guest from them.

I matched the DASD addresses in the definition of the KVM guest to the DASD 
addresses in the z/VM guest so I'm hoping /etc/fstab will be good to go.

z/VM:

   DEDICATE 100 7458
   DEDICATE 101 7459

KVM:

   
and
   


After I get the KVM guest to IPL successfully I'll re-IP it and then I should 
be able to have both guests up at the same time (although my goal is to 
eventually replace the z/VM guest with the KVM guest).

I assume it's SLES, because as far as I know, with RHEL the virtio
drivers are mandatory.
Should work if you add the following lines to /etc/dracut.conf (before
cloning):
 add_dracutmodules+="dasd_rules"
 add_drivers+="virtio_blk dasd_eckd_mod"
and then run
 dracut -f
 grub2-zipl-setup
(The DASD stuff in the initramfs is not strictly needed, but you're on
the safe side if you ever want to IPL in LPAR or z/VM)
Maybe to obvious, but don't forget to assign unique IP addresses to the
KVM guest to avoid networking confusion.


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390



--
Kind Regards,
   Viktor

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Alan Haff]

Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Richard J Moore:

>In this case I think you're saying have two configurations - one under KVM
>and another under zVM. Then manually co-ordinate the sharing or resources
>but ensure that you don't have both guests logged on simultaneously.

Right. Both LPARs - the one running z/VM and the one running KVM - share the 
same DS8800. I created new volumes, shutdown the z/VM guest, cloned the z/VM 
guest's DASD to the new volumes, and then brought the new volumes online to the 
KVM LPAR and attempted to IPL the guest from them.

I matched the DASD addresses in the definition of the KVM guest to the DASD 
addresses in the z/VM guest so I'm hoping /etc/fstab will be good to go.

z/VM:

  DEDICATE 100 7458
  DEDICATE 101 7459

KVM:

  
and
  


After I get the KVM guest to IPL successfully I'll re-IP it and then I should 
be able to have both guests up at the same time (although my goal is to 
eventually replace the z/VM guest with the KVM guest).

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Richard J Moore]

Linux on 390 Port  wrote on 01/12/2020 11:51:37:

> From: Christian Borntraeger 
> To: LINUX-390@VM.MARIST.EDU
> Date: 01/12/2020 11:55
> Subject: [EXTERNAL] Re: Moving a Linux guest from z/VM to KVM?
> Sent by: Linux on 390 Port 
>
> On 01.12.20 12:07, Richard J Moore wrote:
> > Is that really possible (KVM guest <-> z/VM guest)?
> > As far as I am aware the KVM and zVM hypervisors share no metadata
> > regarding the guest's set up. Nor do they share any of the protocols
used
> > in live (or dead) guest relocation.
> >
> > Am I misunderstanding the question?
>
> I was not talking about live migration. I was more talking about:
> site A: graceful shutdoen
> size B: IPL
>
> and this is possible as long as the dasd is available on both sides
> and your network routing can tolerate this (or the guest can
> tolerate to be in different networks depending on the IPL).

OK, that's not really a migration - dead or alive - in zVM terms. Under
zVM dead guest
migration doesn't require the guest to logoff then logon under another
hypervisor. We
would still move their storage and configuration whether IPL'd or not.

In this case I think you're saying have two configurations - one under KVM
and another
under zVM. Then manually co-ordinate the sharing or resources but ensure
that you don't
have both guests logged on simultaneously.


>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> INVALID URI REMOVED
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwICaQ=jf_iaSHvJObTbx-
>
siA1ZOg=hsO4Lk6XlJWxPC1OayT7oG3wyw3H8GpACVStAsDQDSM=az6AjYLgWfcZrMl0ChAUXY9yxQl40O8NsLSRjQP90Co=mtLjWfIPT9equ2k8EPtiQpQMWrxnLGl0JNLT963UanA=
>

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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Christian Borntraeger]

On 01.12.20 12:07, Richard J Moore wrote:
> Is that really possible (KVM guest <-> z/VM guest)?
> As far as I am aware the KVM and zVM hypervisors share no metadata
> regarding the guest's set up. Nor do they share any of the protocols used
> in live (or dead) guest relocation.
>
> Am I misunderstanding the question?

I was not talking about live migration. I was more talking about:
site A: graceful shutdoen
size B: IPL

and this is possible as long as the dasd is available on both sides
and your network routing can tolerate this (or the guest can
tolerate to be in different networks depending on the IPL).

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Richard J Moore]

Is that really possible (KVM guest <-> z/VM guest)?
As far as I am aware the KVM and zVM hypervisors share no metadata
regarding the guest's set up. Nor do they share any of the protocols used
in live (or dead) guest relocation.

Am I misunderstanding the question?

Richard

Richard J Moore -- 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



From:   Christian Borntraeger 
To: LINUX-390@VM.MARIST.EDU
Date:   01/12/2020 06:35
Subject:[EXTERNAL] Re: Moving a Linux guest from z/VM to KVM?
Sent by:Linux on 390 Port 



On 30.11.20 21:10, Mark Post wrote:
> On 11/30/20 1:16 PM, Alan Haff wrote:
>> I have a number of Linux guests running under z/VM. I'd like to move
some of them to a KVM host running in another LPAR. Naively I tried DDRing
a guest's disks to new volumes and IPLing off of the new volumes. No luck,
the virtio modules aren't available in the guest so it can't see any DASD.
>>
>> Has someone put together a recipe for moving a guest from z/VM to KVM?
Or am I heading down a dead end?
>
> I'm not aware of one, but I wouldn't call it a dead end, either. As a
> first step, I would rebuild the initrd with whatever parameters are
> needed to include the virtio drivers, then try again. I have to think
> that /etc/fstab entries would need to be looked at as well.

Look at the virtualization cookbook 5 from the redbooks.
http://www.redbooks.ibm.com/abstracts/sg248463.html?Open

chapter 8.7 contains information how to configure a system as such that it
can
be moved forth and back between LPAR and KVM. That should then also be
possible
with z/VM. If done right that should allow you to move the guest forth and
back
between KVM and z/VM.

Basic idea:
make sure the initrd has classic (DASD) drivers and the virtio-blk driver
and
then use driver independent names for the partitions.

CC Viktor, do we still have our presentation flying around somewhere?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390





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://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Christian Borntraeger]

On 30.11.20 21:10, Mark Post wrote:
> On 11/30/20 1:16 PM, Alan Haff wrote:
>> I have a number of Linux guests running under z/VM. I'd like to move some of 
>> them to a KVM host running in another LPAR. Naively I tried DDRing a guest's 
>> disks to new volumes and IPLing off of the new volumes. No luck, the virtio 
>> modules aren't available in the guest so it can't see any DASD.
>>
>> Has someone put together a recipe for moving a guest from z/VM to KVM? Or am 
>> I heading down a dead end?
>
> I'm not aware of one, but I wouldn't call it a dead end, either. As a
> first step, I would rebuild the initrd with whatever parameters are
> needed to include the virtio drivers, then try again. I have to think
> that /etc/fstab entries would need to be looked at as well.

Look at the virtualization cookbook 5 from the redbooks.
http://www.redbooks.ibm.com/abstracts/sg248463.html?Open

chapter 8.7 contains information how to configure a system as such that it can
be moved forth and back between LPAR and KVM. That should then also be possible
with z/VM. If done right that should allow you to move the guest forth and back
between KVM and z/VM.

Basic idea:
make sure the initrd has classic (DASD) drivers and the virtio-blk driver and
then use driver independent names for the partitions.

CC Viktor, do we still have our presentation flying around somewhere?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving a Linux guest from z/VM to KVM?

[Mark Post]

On 11/30/20 1:16 PM, Alan Haff wrote:
> I have a number of Linux guests running under z/VM. I'd like to move some of 
> them to a KVM host running in another LPAR. Naively I tried DDRing a guest's 
> disks to new volumes and IPLing off of the new volumes. No luck, the virtio 
> modules aren't available in the guest so it can't see any DASD.
>
> Has someone put together a recipe for moving a guest from z/VM to KVM? Or am 
> I heading down a dead end?

I'm not aware of one, but I wouldn't call it a dead end, either. As a
first step, I would rebuild the initrd with whatever parameters are
needed to include the virtio drivers, then try again. I have to think
that /etc/fstab entries would need to be looked at as well.

I seem to recall that Micro Focus acquired the Platespin products. It
might be instructive to see what those do for Intel systems that are to
be moved to KVM as a model.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Moving a Linux guest from z/VM to KVM?

[Alan Haff]

I have a number of Linux guests running under z/VM. I'd like to move some of 
them to a KVM host running in another LPAR. Naively I tried DDRing a guest's 
disks to new volumes and IPLing off of the new volumes. No luck, the virtio 
modules aren't available in the guest so it can't see any DASD.

Has someone put together a recipe for moving a guest from z/VM to KVM? Or am I 
heading down a dead end?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

On Tue, Nov 3, 2020 at 8:46 AM Grzegorz Powiedziuk 
wrote:

> Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7
> on Z and we are having big performance issues.
>

What about enabling SMT in z/VM ? Would 10 cpu db2 take an advantage of
this? On the p8 they had SMT-8 turned on
Gregory

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Eric Covener]

> Where  can I look for potential relief? Everyone was hoping for a better
> performance not worse.I am hoping that there is something we can tweak to
> make this better.

Only because I didn't see it specifically in the thread yet, do you have
similar large page size support/tuning in both environments?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Tully, Phil (CORP)]

Can you provide the zVM SRM parameters  and MT status?

Regards, Phil Tully
Chief Architect-z/VM & z/Linux
phil.tu...@adp.com
cell: 973-202-7427
1-800 377-0237,,5252697#



On 11/3/20, 12:25 PM, "Linux on 390 Port on behalf of Grzegorz Powiedziuk" 
 wrote:


WARNING: Do not click links or open attachments unless you recognize the 
source of the email and know the contents are safe. 

**
Hi Jim,

correction - we have z14 not z114

 .. .not sure why I keep calling our z14 z114 ;)  We have z14



We have 16 IFLs in total shared across 5 z/VM lparps but really there is

literally nothing running in there yet beside this one huge VM which has 10

IFLs configured. We have plenty of spare memory left and this one VM has

150G configured. It is about the same as what they had for this database

when it was on the AIX. This number has been calculated by DBAs and it

seems ok. I am not sure how to tell if DB2 is happy with what it has or

not, but the linux OS is definitely not starving for memory.



that p7 was 9117-MMD. And I just found that it was had EC set to 10 but it

could pull up to 15 processors. I am not sure how that works over there.







On Tue, Nov 3, 2020 at 10:58 AM Jim Elliott  wrote:



> Gregory:

>

> Do you have a z114 with 10 IFLs? That is the maximum number of IFLs

> available on a z114 (2818-M10) and would be unusual. Is this a single z/VM

> LPAR? How much memory is on the z114 (and in this LPAR)? Also, what was 
the

> specific MT/Model for the P7 box?

>

> If you were to compare a 12-core Power 730 (8231-E2C) to a 10 IFL z114 the

> Power system has 1.4 to 2.0 times the capacity of the z114.

>

> Jim Elliott

> Senior IT Consultant - GlassHouse Systems Inc.

>

>

> On Tue, Nov 3, 2020 at 8:47 AM Grzegorz Powiedziuk 

> wrote:

>

> > Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7

> on

> > Z and we are having big performance issues.

> > Same memory, CPU number is down from 12 to 10.  Although they had

> > multithreading ON so they saw more "cpus" We have faster disks (moved to

> > flash), faster FCP cards and faster network adapters.

> > We are running on z114 and at this point that is practically the only VM

> > running with IFLs on this box.

> >

> > It seems that when "jobs" run on their own, they finish faster than what

> > they were getting on AIX.

> > But problems start if there is more than we can chew. So either few jobs

> > running at the same time or some reorgs running in the database.

> >

> > Load average goes to 150-200, cpus are at 100%  (kernel time can go to

> > 20-30% ) but no iowaits.

> > Plenty of memory available.

> > At this point everything becomes extremely slow, people are starting

> having

> > problems with connecting to db2 (annd sshing), basically it becomes a

> > nightmare

> >

> > This db2 is massive (30+TB) and it is a multinode configuration (17 
nodes

> > running on the same host). We moved it like this 1:1 from that old AIX.

> >

> > DB2 is running on the ext4 filesystem (Actually a huge number of

> > filesystems- each NODE is a separate logical volume). Separate for logs,

> > data.

> >

> > If this continues like this, we will add 2 cpus but I have a feeling 
that

> > it will not make much difference.

> >

> > I know that we end up with a massive number of processes and a massive

> > number of file descriptors (lsof sice it shows also threads now, is

> > practically useless - it would run for way too long - 10-30 minutes

> > probably) .

> >

> > A snapshot from just now:

> >

> > top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29,

> 151.07,

> > 133.54

> > Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie

> > %Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,

> >  2.9 st

> > %Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,

> >  0.6 st

> > %Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,

> >  0.3 st

> > %Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,

> >  0.3 st

> > %Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,

> >  0.6 st

> > %Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,

> >  0.3 st

> > %Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,

> >  0.6 st

> > %Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,

> >  0.6 st

> > %Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,

> >  0.6 st

> > %Cpu9  : 84.1 

Re: performance problems db2 after moving from AIX

[Rob van der Heij]

On Tue, 3 Nov 2020 at 21:27, Grzegorz Powiedziuk 
wrote:

>
> In the performance monitor toolkit it shows around 12.000 diag x'9c' /s
> and 50 x'44'
> But at this time of a day everything is calm. i will check again tomorrow.
> Lot's of diag x'9c' would indicate too many virtual cpus right?
>

You would expect the amount of spinning to go down when you vary some CPUs
off from the Linux side. Since you seem to be running just this single
massive guest, there's less concern about adjusting SHARE settings along
with it.

It's not entirely clear from your description how identical this is to the
AIX configuration. If you doubled the number of virtual CPUs for the guest
because of SMT-2, with that many virtual CPUs the application locking may
turn out to make that counter-productive. There's no doubt a lot of wisdom
in monitor data from the workload to explain the z/VM side. As Christian
suggests, you would do wise to take advantage of your support arrangement
and have a z/VM performance analyst look into it.

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[barton]

Diag 9C are low cost, Diag 44 not so much.  50 is a low number.


On 11/3/2020 12:27 PM, Grzegorz Powiedziuk wrote:

On Tue, Nov 3, 2020 at 1:58 PM Grzegorz Powiedziuk 
wrote:


Thanks Christian.
There is no pagging (swapping) here besides just regular kernel's house
keeping (vm.swappiness =5 )
rhel 7 doesn't give me diag_stat in the debug filesystem hmm

On Tue, Nov 3, 2020 at 12:37 PM Christian Borntraeger <
borntrae...@linux.ibm.com> wrote:


So you at least had some time where you paged out memory.
If you have sysstat installed it would be good to get some history data of
cpu and swap.

You can also run "vmstat 1 -w" to get an online you on the system load.
Can you also check (as root)
/sys/kernel/debug/diag_stat
2 times and see if you see excessive diagnose 9c rates.



In the performance monitor toolkit it shows around 12.000 diag x'9c' /s
and 50 x'44'
But at this time of a day everything is calm. i will check again tomorrow.
Lot's of diag x'9c' would indicate too many virtual cpus right?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

On Tue, Nov 3, 2020 at 3:25 PM Jim Elliott  wrote:

> Gregory,
>
> Yes, thrashing. :-)
>
>
I like my name better and it even fits better :)
I will keep an eye on page faults tomorrow but we are not overcommitting
memory at all. Unless something inside of db2 is cooking but in linux there
is no swapping and in z/vm no paging whatsoever.
DB2 grabs about 95% of the memory and it all goes into "shmem" and uses
that for it's buffers and stuff. It's not like db2 has its own internal
paging? Even if it did, I am sure DBAs would scream by now.
Although the ~20% cpu time spent in kernel mode is something I've been
questioning (rest of it goes straight into user time) . But I have no clue
if it is a lot for this type of workload or not at all. I've been blaming a
massive number of filesystems/logical volumes (152) and huge number of
threads processes and FD's.
How do you best determine that there is no some other thrashing?
thanks!

Gregory


> Jim Elliott
> Senior IT Consultant - GlassHouse Systems Inc.
>
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

On Tue, Nov 3, 2020 at 1:58 PM Grzegorz Powiedziuk 
wrote:

> Thanks Christian.
> There is no pagging (swapping) here besides just regular kernel's house
> keeping (vm.swappiness =5 )
> rhel 7 doesn't give me diag_stat in the debug filesystem hmm
>
> On Tue, Nov 3, 2020 at 12:37 PM Christian Borntraeger <
> borntrae...@linux.ibm.com> wrote:
>
>>
>> So you at least had some time where you paged out memory.
>> If you have sysstat installed it would be good to get some history data of
>> cpu and swap.
>>
>> You can also run "vmstat 1 -w" to get an online you on the system load.
>> Can you also check (as root)
>> /sys/kernel/debug/diag_stat
>> 2 times and see if you see excessive diagnose 9c rates.
>>
>>
In the performance monitor toolkit it shows around 12.000 diag x'9c' /s
and 50 x'44'
But at this time of a day everything is calm. i will check again tomorrow.
Lot's of diag x'9c' would indicate too many virtual cpus right?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Jim Elliott]

Gregory,

Yes, thrashing. :-)

Jim Elliott
Senior IT Consultant - GlassHouse Systems Inc.


On Tue, Nov 3, 2020 at 2:07 PM Grzegorz Powiedziuk 
wrote:

> On Tue, Nov 3, 2020 at 1:57 PM Jim Elliott  wrote:
>
> > Gregory,
> >
> > The 9117-MMD could range from 1 chip/4 cores all the way up to 16
> chips/64
> > cores at either 3.80 or 4.22 GHz. If it has 15 cores, then it was likely
> > the 4.22 GHz 5 chip/15 core version. Using 10 out of 15 cores (even at
> 100%
> > busy) should fit on 5 z14 ZR1 or z14 M0x IFLs. Sounds like there is
> > something causing thrashing. Do you have a z/VM performance producs
> > (Velocity or IBM?) as that might help isolate where the bottleneck is.
> >
> >
> > Thanks Jim, this is encouraging. We do have a performance monitor toolkit
> and I've been running sar in here as well.
> When you say trashing, do you mean memory thrashing?
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

On Tue, Nov 3, 2020 at 1:57 PM Jim Elliott  wrote:

> Gregory,
>
> The 9117-MMD could range from 1 chip/4 cores all the way up to 16 chips/64
> cores at either 3.80 or 4.22 GHz. If it has 15 cores, then it was likely
> the 4.22 GHz 5 chip/15 core version. Using 10 out of 15 cores (even at 100%
> busy) should fit on 5 z14 ZR1 or z14 M0x IFLs. Sounds like there is
> something causing thrashing. Do you have a z/VM performance producs
> (Velocity or IBM?) as that might help isolate where the bottleneck is.
>
>
> Thanks Jim, this is encouraging. We do have a performance monitor toolkit
and I've been running sar in here as well.
When you say trashing, do you mean memory thrashing?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

On Tue, Nov 3, 2020 at 1:35 PM r.stricklin  wrote:

>
> I recently had a vaguely similar problem with a much smaller database on
> linux (x86, mysql for zabbix) that presented bizarre performance issues
> despite clearly having lots of resources left available.
>
> What our problem ended up being was the linux block i/o scheduler deciding
> to defer i/o based on seek avoidance, and under heavy database use this was
> causing havoc with mysql's ability to complete transactions. It seems
> absurd to preferentially avoid seeks when you have SSD. The problems
> vanished instantly when we changed the i/o scheduler on the SSD block
> devices to 'noop'.
>
> I think it's worth checking in your case.
>
>
OH! this is a great idea. I've completely forgot about this. We are using a
default deadline and noop could save some cpu cycles!!
thank you! I will definitely consider changing the scheduler

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

Thanks Christian.
There is no pagging (swapping) here besides just regular kernel's house
keeping (vm.swappiness =5 )
rhel 7 doesn't give me diag_stat in the debug filesystem hmm

On Tue, Nov 3, 2020 at 12:37 PM Christian Borntraeger <
borntrae...@linux.ibm.com> wrote:

> On 03.11.20 14:46, Grzegorz Powiedziuk wrote:
> > Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7
> on
> > Z and we are having big performance issues.
> > Same memory, CPU number is down from 12 to 10.  Although they had
> > multithreading ON so they saw more "cpus" We have faster disks (moved to
> > flash), faster FCP cards and faster network adapters.
> > We are running on z114 and at this point that is practically the only VM
> > running with IFLs on this box.
> >
> > It seems that when "jobs" run on their own, they finish faster than what
> > they were getting on AIX.
> > But problems start if there is more than we can chew. So either few jobs
> > running at the same time or some reorgs running in the database.
> >
> > Load average goes to 150-200, cpus are at 100%  (kernel time can go to
> > 20-30% ) but no iowaits.
> > Plenty of memory available.
> > At this point everything becomes extremely slow, people are starting
> having
> > problems with connecting to db2 (annd sshing), basically it becomes a
> > nightmare
> >
> > This db2 is massive (30+TB) and it is a multinode configuration (17 nodes
> > running on the same host). We moved it like this 1:1 from that old AIX.
> >
> > DB2 is running on the ext4 filesystem (Actually a huge number of
> > filesystems- each NODE is a separate logical volume). Separate for logs,
> > data.
> >
> > If this continues like this, we will add 2 cpus but I have a feeling that
> > it will not make much difference.
> >
> > I know that we end up with a massive number of processes and a massive
> > number of file descriptors (lsof sice it shows also threads now, is
> > practically useless - it would run for way too long - 10-30 minutes
> > probably) .
> >
> > A snapshot from just now:
> >
> > top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29,
> 151.07,
> > 133.54
> > Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie
> > %Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,
> >  2.9 st
> > %Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
> >  0.6 st
> > %Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> >  0.3 st
> > %Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> >  0.3 st
> > %Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
> >  0.6 st
> > %Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
> >  0.3 st
> > %Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
> >  0.6 st
> > %Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
> >  0.6 st
> > %Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
> >  0.6 st
> > %Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> >  0.6 st
> > KiB Mem : 15424256+total,  1069280 free, 18452168 used,
> 13472112+buff/cache
> > KiB Swap: 52305904 total, 51231216 free,  1074688 used. 17399028 avail
> Mem
>
> So you at least had some time where you paged out memory.
> If you have sysstat installed it would be good to get some history data of
> cpu and swap.
>
> You can also run "vmstat 1 -w" to get an online you on the system load.
> Can you also check (as root)
> /sys/kernel/debug/diag_stat
> 2 times and see if you see excessive diagnose 9c rates.
>
> >
> > Where  can I look for potential relief? Everyone was hoping for a better
> > performance not worse.I am hoping that there is something we can tweak to
> > make this better.
> > I will appreciate any ideas!
>
> I agree this should have gotten faster, not slower.
>
> If you have an IBM service contract (or any other vendor that provides
> support)
> you could open a service ticket to get this analysed.
>
> Christian
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Jim Elliott]

Gregory,

The 9117-MMD could range from 1 chip/4 cores all the way up to 16 chips/64
cores at either 3.80 or 4.22 GHz. If it has 15 cores, then it was likely
the 4.22 GHz 5 chip/15 core version. Using 10 out of 15 cores (even at 100%
busy) should fit on 5 z14 ZR1 or z14 M0x IFLs. Sounds like there is
something causing thrashing. Do you have a z/VM performance producs
(Velocity or IBM?) as that might help isolate where the bottleneck is.

Jim Elliott
Senior IT Consultant - GlassHouse Systems Inc.


On Tue, Nov 3, 2020 at 12:25 PM Grzegorz Powiedziuk 
wrote:

> Hi Jim,
> correction - we have z14 not z114
>  .. .not sure why I keep calling our z14 z114 ;)  We have z14
>
> We have 16 IFLs in total shared across 5 z/VM lparps but really there is
> literally nothing running in there yet beside this one huge VM which has 10
> IFLs configured. We have plenty of spare memory left and this one VM has
> 150G configured. It is about the same as what they had for this database
> when it was on the AIX. This number has been calculated by DBAs and it
> seems ok. I am not sure how to tell if DB2 is happy with what it has or
> not, but the linux OS is definitely not starving for memory.
>
> that p7 was 9117-MMD. And I just found that it was had EC set to 10 but it
> could pull up to 15 processors. I am not sure how that works over there.
>
>
>
> On Tue, Nov 3, 2020 at 10:58 AM Jim Elliott  wrote:
>
> > Gregory:
> >
> > Do you have a z114 with 10 IFLs? That is the maximum number of IFLs
> > available on a z114 (2818-M10) and would be unusual. Is this a single
> z/VM
> > LPAR? How much memory is on the z114 (and in this LPAR)? Also, what was
> the
> > specific MT/Model for the P7 box?
> >
> > If you were to compare a 12-core Power 730 (8231-E2C) to a 10 IFL z114
> the
> > Power system has 1.4 to 2.0 times the capacity of the z114.
> >
> > Jim Elliott
> > Senior IT Consultant - GlassHouse Systems Inc.
> >
> >
> > On Tue, Nov 3, 2020 at 8:47 AM Grzegorz Powiedziuk <
> gpowiedz...@gmail.com>
> > wrote:
> >
> > > Hi, I could use some ideas. We moved a huge db2 from old p7 aix to
> rhel7
> > on
> > > Z and we are having big performance issues.
> > > Same memory, CPU number is down from 12 to 10.  Although they had
> > > multithreading ON so they saw more "cpus" We have faster disks (moved
> to
> > > flash), faster FCP cards and faster network adapters.
> > > We are running on z114 and at this point that is practically the only
> VM
> > > running with IFLs on this box.
> > >
> > > It seems that when "jobs" run on their own, they finish faster than
> what
> > > they were getting on AIX.
> > > But problems start if there is more than we can chew. So either few
> jobs
> > > running at the same time or some reorgs running in the database.
> > >
> > > Load average goes to 150-200, cpus are at 100%  (kernel time can go to
> > > 20-30% ) but no iowaits.
> > > Plenty of memory available.
> > > At this point everything becomes extremely slow, people are starting
> > having
> > > problems with connecting to db2 (annd sshing), basically it becomes a
> > > nightmare
> > >
> > > This db2 is massive (30+TB) and it is a multinode configuration (17
> nodes
> > > running on the same host). We moved it like this 1:1 from that old AIX.
> > >
> > > DB2 is running on the ext4 filesystem (Actually a huge number of
> > > filesystems- each NODE is a separate logical volume). Separate for
> logs,
> > > data.
> > >
> > > If this continues like this, we will add 2 cpus but I have a feeling
> that
> > > it will not make much difference.
> > >
> > > I know that we end up with a massive number of processes and a massive
> > > number of file descriptors (lsof sice it shows also threads now, is
> > > practically useless - it would run for way too long - 10-30 minutes
> > > probably) .
> > >
> > > A snapshot from just now:
> > >
> > > top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29,
> > 151.07,
> > > 133.54
> > > Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie
> > > %Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,
> > >  2.9 st
> > > %Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
> > >  0.6 st
> > > %Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> > >  0.3 st
> > > %Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> > >  0.3 st
> > > %Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
> > >  0.6 st
> > > %Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
> > >  0.3 st
> > > %Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
> > >  0.6 st
> > > %Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
> > >  0.6 st
> > > %Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
> > >  0.6 st
> > > %Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> > >  0.6 st
> > > KiB Mem : 15424256+total,  1069280 free, 18452168 

Re: performance problems db2 after moving from AIX

[r.stricklin]

On Nov 3, 2020, at 5:46 AM, Grzegorz Powiedziuk wrote:

> DB2 is running on the ext4 filesystem (Actually a huge number of
> filesystems- each NODE is a separate logical volume). Separate for logs,
> data.

I recently had a vaguely similar problem with a much smaller database on linux 
(x86, mysql for zabbix) that presented bizarre performance issues despite 
clearly having lots of resources left available.

What our problem ended up being was the linux block i/o scheduler deciding to 
defer i/o based on seek avoidance, and under heavy database use this was 
causing havoc with mysql's ability to complete transactions. It seems absurd to 
preferentially avoid seeks when you have SSD. The problems vanished instantly 
when we changed the i/o scheduler on the SSD block devices to 'noop'.

I think it's worth checking in your case.


ok
bear.

-- 
until further notice

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Tully, Phil (CORP)]

Can you provide the output of 
Q MULTITHREAD and Q SRM

Regards, Phil Tully
Chief Architect-z/VM & z/Linux
phil.tu...@adp.com
cell: 973-202-7427
1-800 377-0237,,5252697#



On 11/3/20, 8:47 AM, "Linux on 390 Port on behalf of Grzegorz Powiedziuk" 
 wrote:


WARNING: Do not click links or open attachments unless you recognize the 
source of the email and know the contents are safe. 

**
Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7 on

Z and we are having big performance issues.

Same memory, CPU number is down from 12 to 10.  Although they had

multithreading ON so they saw more "cpus" We have faster disks (moved to

flash), faster FCP cards and faster network adapters.

We are running on z114 and at this point that is practically the only VM

running with IFLs on this box.



It seems that when "jobs" run on their own, they finish faster than what

they were getting on AIX.

But problems start if there is more than we can chew. So either few jobs

running at the same time or some reorgs running in the database.



Load average goes to 150-200, cpus are at 100%  (kernel time can go to

20-30% ) but no iowaits.

Plenty of memory available.

At this point everything becomes extremely slow, people are starting having

problems with connecting to db2 (annd sshing), basically it becomes a

nightmare



This db2 is massive (30+TB) and it is a multinode configuration (17 nodes

running on the same host). We moved it like this 1:1 from that old AIX.



DB2 is running on the ext4 filesystem (Actually a huge number of

filesystems- each NODE is a separate logical volume). Separate for logs,

data.



If this continues like this, we will add 2 cpus but I have a feeling that

it will not make much difference.



I know that we end up with a massive number of processes and a massive

number of file descriptors (lsof sice it shows also threads now, is

practically useless - it would run for way too long - 10-30 minutes

probably) .



A snapshot from just now:



top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29, 151.07,

133.54

Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie

%Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,

 2.9 st

%Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,

 0.6 st

%Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,

 0.3 st

%Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,

 0.3 st

%Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,

 0.6 st

%Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,

 0.3 st

%Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,

 0.6 st

%Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,

 0.6 st

%Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,

 0.6 st

%Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,

 0.6 st

KiB Mem : 15424256+total,  1069280 free, 18452168 used, 13472112+buff/cache

KiB Swap: 52305904 total, 51231216 free,  1074688 used. 17399028 avail Mem



Where  can I look for potential relief? Everyone was hoping for a better

performance not worse.I am hoping that there is something we can tweak to

make this better.

I will appreciate any ideas!

thanks

Gregory



--

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

send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visit


https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIBaQ=xu_5lAfKHjInGFR3ndoZrw=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU=SUeq7nloampLUlcudHLlDllRMQk8sapBSXhim0FFfbU=O5QoJ1ORESabvMAsvoNl3rqMG5HuqEdReIffDAH3p2E=
 



--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit

Re: performance problems db2 after moving from AIX

[Christian Borntraeger]

On 03.11.20 14:46, Grzegorz Powiedziuk wrote:
> Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7 on
> Z and we are having big performance issues.
> Same memory, CPU number is down from 12 to 10.  Although they had
> multithreading ON so they saw more "cpus" We have faster disks (moved to
> flash), faster FCP cards and faster network adapters.
> We are running on z114 and at this point that is practically the only VM
> running with IFLs on this box.
>
> It seems that when "jobs" run on their own, they finish faster than what
> they were getting on AIX.
> But problems start if there is more than we can chew. So either few jobs
> running at the same time or some reorgs running in the database.
>
> Load average goes to 150-200, cpus are at 100%  (kernel time can go to
> 20-30% ) but no iowaits.
> Plenty of memory available.
> At this point everything becomes extremely slow, people are starting having
> problems with connecting to db2 (annd sshing), basically it becomes a
> nightmare
>
> This db2 is massive (30+TB) and it is a multinode configuration (17 nodes
> running on the same host). We moved it like this 1:1 from that old AIX.
>
> DB2 is running on the ext4 filesystem (Actually a huge number of
> filesystems- each NODE is a separate logical volume). Separate for logs,
> data.
>
> If this continues like this, we will add 2 cpus but I have a feeling that
> it will not make much difference.
>
> I know that we end up with a massive number of processes and a massive
> number of file descriptors (lsof sice it shows also threads now, is
> practically useless - it would run for way too long - 10-30 minutes
> probably) .
>
> A snapshot from just now:
>
> top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29, 151.07,
> 133.54
> Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie
> %Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,
>  2.9 st
> %Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
>  0.6 st
> %Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.3 st
> %Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.3 st
> %Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
>  0.6 st
> %Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
>  0.3 st
> %Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
>  0.6 st
> %Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
>  0.6 st
> %Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
>  0.6 st
> %Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.6 st
> KiB Mem : 15424256+total,  1069280 free, 18452168 used, 13472112+buff/cache
> KiB Swap: 52305904 total, 51231216 free,  1074688 used. 17399028 avail Mem

So you at least had some time where you paged out memory.
If you have sysstat installed it would be good to get some history data of
cpu and swap.

You can also run "vmstat 1 -w" to get an online you on the system load.
Can you also check (as root)
/sys/kernel/debug/diag_stat
2 times and see if you see excessive diagnose 9c rates.

>
> Where  can I look for potential relief? Everyone was hoping for a better
> performance not worse.I am hoping that there is something we can tweak to
> make this better.
> I will appreciate any ideas!

I agree this should have gotten faster, not slower.

If you have an IBM service contract (or any other vendor that provides support)
you could open a service ticket to get this analysed.

Christian

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

Hi Jim,
correction - we have z14 not z114
 .. .not sure why I keep calling our z14 z114 ;)  We have z14

We have 16 IFLs in total shared across 5 z/VM lparps but really there is
literally nothing running in there yet beside this one huge VM which has 10
IFLs configured. We have plenty of spare memory left and this one VM has
150G configured. It is about the same as what they had for this database
when it was on the AIX. This number has been calculated by DBAs and it
seems ok. I am not sure how to tell if DB2 is happy with what it has or
not, but the linux OS is definitely not starving for memory.

that p7 was 9117-MMD. And I just found that it was had EC set to 10 but it
could pull up to 15 processors. I am not sure how that works over there.



On Tue, Nov 3, 2020 at 10:58 AM Jim Elliott  wrote:

> Gregory:
>
> Do you have a z114 with 10 IFLs? That is the maximum number of IFLs
> available on a z114 (2818-M10) and would be unusual. Is this a single z/VM
> LPAR? How much memory is on the z114 (and in this LPAR)? Also, what was the
> specific MT/Model for the P7 box?
>
> If you were to compare a 12-core Power 730 (8231-E2C) to a 10 IFL z114 the
> Power system has 1.4 to 2.0 times the capacity of the z114.
>
> Jim Elliott
> Senior IT Consultant - GlassHouse Systems Inc.
>
>
> On Tue, Nov 3, 2020 at 8:47 AM Grzegorz Powiedziuk 
> wrote:
>
> > Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7
> on
> > Z and we are having big performance issues.
> > Same memory, CPU number is down from 12 to 10.  Although they had
> > multithreading ON so they saw more "cpus" We have faster disks (moved to
> > flash), faster FCP cards and faster network adapters.
> > We are running on z114 and at this point that is practically the only VM
> > running with IFLs on this box.
> >
> > It seems that when "jobs" run on their own, they finish faster than what
> > they were getting on AIX.
> > But problems start if there is more than we can chew. So either few jobs
> > running at the same time or some reorgs running in the database.
> >
> > Load average goes to 150-200, cpus are at 100%  (kernel time can go to
> > 20-30% ) but no iowaits.
> > Plenty of memory available.
> > At this point everything becomes extremely slow, people are starting
> having
> > problems with connecting to db2 (annd sshing), basically it becomes a
> > nightmare
> >
> > This db2 is massive (30+TB) and it is a multinode configuration (17 nodes
> > running on the same host). We moved it like this 1:1 from that old AIX.
> >
> > DB2 is running on the ext4 filesystem (Actually a huge number of
> > filesystems- each NODE is a separate logical volume). Separate for logs,
> > data.
> >
> > If this continues like this, we will add 2 cpus but I have a feeling that
> > it will not make much difference.
> >
> > I know that we end up with a massive number of processes and a massive
> > number of file descriptors (lsof sice it shows also threads now, is
> > practically useless - it would run for way too long - 10-30 minutes
> > probably) .
> >
> > A snapshot from just now:
> >
> > top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29,
> 151.07,
> > 133.54
> > Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie
> > %Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,
> >  2.9 st
> > %Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
> >  0.6 st
> > %Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> >  0.3 st
> > %Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> >  0.3 st
> > %Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
> >  0.6 st
> > %Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
> >  0.3 st
> > %Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
> >  0.6 st
> > %Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
> >  0.6 st
> > %Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
> >  0.6 st
> > %Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
> >  0.6 st
> > KiB Mem : 15424256+total,  1069280 free, 18452168 used,
> 13472112+buff/cache
> > KiB Swap: 52305904 total, 51231216 free,  1074688 used. 17399028 avail
> Mem
> >
> > Where  can I look for potential relief? Everyone was hoping for a better
> > performance not worse.I am hoping that there is something we can tweak to
> > make this better.
> > I will appreciate any ideas!
> > thanks
> > Gregory
> >
> > --
> > For LINUX-390 subscribe / signoff / archive access instructions,
> > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> > visit
> > http://www2.marist.edu/htbin/wlvindex?LINUX-390
> >
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to 

Re: performance problems db2 after moving from AIX

[Jim Elliott]

Gregory:

Do you have a z114 with 10 IFLs? That is the maximum number of IFLs
available on a z114 (2818-M10) and would be unusual. Is this a single z/VM
LPAR? How much memory is on the z114 (and in this LPAR)? Also, what was the
specific MT/Model for the P7 box?

If you were to compare a 12-core Power 730 (8231-E2C) to a 10 IFL z114 the
Power system has 1.4 to 2.0 times the capacity of the z114.

Jim Elliott
Senior IT Consultant - GlassHouse Systems Inc.


On Tue, Nov 3, 2020 at 8:47 AM Grzegorz Powiedziuk 
wrote:

> Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7 on
> Z and we are having big performance issues.
> Same memory, CPU number is down from 12 to 10.  Although they had
> multithreading ON so they saw more "cpus" We have faster disks (moved to
> flash), faster FCP cards and faster network adapters.
> We are running on z114 and at this point that is practically the only VM
> running with IFLs on this box.
>
> It seems that when "jobs" run on their own, they finish faster than what
> they were getting on AIX.
> But problems start if there is more than we can chew. So either few jobs
> running at the same time or some reorgs running in the database.
>
> Load average goes to 150-200, cpus are at 100%  (kernel time can go to
> 20-30% ) but no iowaits.
> Plenty of memory available.
> At this point everything becomes extremely slow, people are starting having
> problems with connecting to db2 (annd sshing), basically it becomes a
> nightmare
>
> This db2 is massive (30+TB) and it is a multinode configuration (17 nodes
> running on the same host). We moved it like this 1:1 from that old AIX.
>
> DB2 is running on the ext4 filesystem (Actually a huge number of
> filesystems- each NODE is a separate logical volume). Separate for logs,
> data.
>
> If this continues like this, we will add 2 cpus but I have a feeling that
> it will not make much difference.
>
> I know that we end up with a massive number of processes and a massive
> number of file descriptors (lsof sice it shows also threads now, is
> practically useless - it would run for way too long - 10-30 minutes
> probably) .
>
> A snapshot from just now:
>
> top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29, 151.07,
> 133.54
> Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie
> %Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,
>  2.9 st
> %Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
>  0.6 st
> %Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.3 st
> %Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.3 st
> %Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
>  0.6 st
> %Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
>  0.3 st
> %Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
>  0.6 st
> %Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
>  0.6 st
> %Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
>  0.6 st
> %Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.6 st
> KiB Mem : 15424256+total,  1069280 free, 18452168 used, 13472112+buff/cache
> KiB Swap: 52305904 total, 51231216 free,  1074688 used. 17399028 avail Mem
>
> Where  can I look for potential relief? Everyone was hoping for a better
> performance not worse.I am hoping that there is something we can tweak to
> make this better.
> I will appreciate any ideas!
> thanks
> Gregory
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: performance problems db2 after moving from AIX

[Robert J Brenneman]

you've got a gig of swap used , and you said %system CPU time is way higher
while the system becomes unusable ?
are you actively swapping during that time when the system is not
responsive? If yes you need to try to either add memory or reduce the
memory demand on the system.

On Tue, Nov 3, 2020 at 8:47 AM Grzegorz Powiedziuk 
wrote:

> Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7 on
> Z and we are having big performance issues.
> Same memory, CPU number is down from 12 to 10.  Although they had
> multithreading ON so they saw more "cpus" We have faster disks (moved to
> flash), faster FCP cards and faster network adapters.
> We are running on z114 and at this point that is practically the only VM
> running with IFLs on this box.
>
> It seems that when "jobs" run on their own, they finish faster than what
> they were getting on AIX.
> But problems start if there is more than we can chew. So either few jobs
> running at the same time or some reorgs running in the database.
>
> Load average goes to 150-200, cpus are at 100%  (kernel time can go to
> 20-30% ) but no iowaits.
> Plenty of memory available.
> At this point everything becomes extremely slow, people are starting having
> problems with connecting to db2 (annd sshing), basically it becomes a
> nightmare
>
> This db2 is massive (30+TB) and it is a multinode configuration (17 nodes
> running on the same host). We moved it like this 1:1 from that old AIX.
>
> DB2 is running on the ext4 filesystem (Actually a huge number of
> filesystems- each NODE is a separate logical volume). Separate for logs,
> data.
>
> If this continues like this, we will add 2 cpus but I have a feeling that
> it will not make much difference.
>
> I know that we end up with a massive number of processes and a massive
> number of file descriptors (lsof sice it shows also threads now, is
> practically useless - it would run for way too long - 10-30 minutes
> probably) .
>
> A snapshot from just now:
>
> top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29, 151.07,
> 133.54
> Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie
> %Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,
>  2.9 st
> %Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
>  0.6 st
> %Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.3 st
> %Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.3 st
> %Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
>  0.6 st
> %Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
>  0.3 st
> %Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
>  0.6 st
> %Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
>  0.6 st
> %Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
>  0.6 st
> %Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
>  0.6 st
> KiB Mem : 15424256+total,  1069280 free, 18452168 used, 13472112+buff/cache
> KiB Swap: 52305904 total, 51231216 free,  1074688 used. 17399028 avail Mem
>
> Where  can I look for potential relief? Everyone was hoping for a better
> performance not worse.I am hoping that there is something we can tweak to
> make this better.
> I will appreciate any ideas!
> thanks
> Gregory
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>


--
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://www2.marist.edu/htbin/wlvindex?LINUX-390

performance problems db2 after moving from AIX

[Grzegorz Powiedziuk]

Hi, I could use some ideas. We moved a huge db2 from old p7 aix to rhel7 on
Z and we are having big performance issues.
Same memory, CPU number is down from 12 to 10.  Although they had
multithreading ON so they saw more "cpus" We have faster disks (moved to
flash), faster FCP cards and faster network adapters.
We are running on z114 and at this point that is practically the only VM
running with IFLs on this box.

It seems that when "jobs" run on their own, they finish faster than what
they were getting on AIX.
But problems start if there is more than we can chew. So either few jobs
running at the same time or some reorgs running in the database.

Load average goes to 150-200, cpus are at 100%  (kernel time can go to
20-30% ) but no iowaits.
Plenty of memory available.
At this point everything becomes extremely slow, people are starting having
problems with connecting to db2 (annd sshing), basically it becomes a
nightmare

This db2 is massive (30+TB) and it is a multinode configuration (17 nodes
running on the same host). We moved it like this 1:1 from that old AIX.

DB2 is running on the ext4 filesystem (Actually a huge number of
filesystems- each NODE is a separate logical volume). Separate for logs,
data.

If this continues like this, we will add 2 cpus but I have a feeling that
it will not make much difference.

I know that we end up with a massive number of processes and a massive
number of file descriptors (lsof sice it shows also threads now, is
practically useless - it would run for way too long - 10-30 minutes
probably) .

A snapshot from just now:

top - 08:37:50 up 11 days, 12:04, 28 users,  load average: 188.29, 151.07,
133.54
Tasks: 1843 total,  11 running, 1832 sleeping,   0 stopped,   0 zombie
%Cpu0  : 76.3 us, 16.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  1.0 hi,  3.2 si,
 2.9 st
%Cpu1  : 66.1 us, 31.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
 0.6 st
%Cpu2  : 66.9 us, 31.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
 0.3 st
%Cpu3  : 74.7 us, 23.4 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
 0.3 st
%Cpu4  : 86.7 us, 10.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.3 si,
 0.6 st
%Cpu5  : 83.8 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
 0.3 st
%Cpu6  : 81.6 us, 15.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
 0.6 st
%Cpu7  : 70.6 us, 26.2 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.9 si,
 0.6 st
%Cpu8  : 70.5 us, 26.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.6 hi,  1.6 si,
 0.6 st
%Cpu9  : 84.1 us, 13.6 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  1.3 si,
 0.6 st
KiB Mem : 15424256+total,  1069280 free, 18452168 used, 13472112+buff/cache
KiB Swap: 52305904 total, 51231216 free,  1074688 used. 17399028 avail Mem

Where  can I look for potential relief? Everyone was hoping for a better
performance not worse.I am hoping that there is something we can tweak to
make this better.
I will appreciate any ideas!
thanks
Gregory

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving Root to Larger disk

[Davis, Larry (National VM Capability)]

We have the Root Filesystem on  Mod-3 (/, /boot, /usr, /var, and others) /tmp 
and /home are on other disks
We want to move the root filesystem to a mod-9 because we have run out of space 
and Updates are failing
For the most part the stuff on the root file system is static during the Copy
The High level Steps to do this I was thinking is
1. Create a 1-End Minidisk on Mod-9 (New Root disk address 1150)
2. Attach Disk to Linux (cio_ignore and chccwdev commands)
3. Format and Partition new disk
4. Copy one physical disk to another
dd if== of= 
bs=64K
dd if=/dev/dasdb1 of=/dev/dasdd1 bs=64K
5. Extend the new root filesystem
6. Make the new root File system bootable
7. Shutdown  Linux Image
8. Update Directory to swap virtual addresses old root address 0150 and new 
root address 1150
9. Boot Linux image



Larry Davis (z/VM Team)

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Friday, June 26, 2020 11:56 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Root to Larger disk

On 6/26/20 9:54 AM, Davis, Larry (National VM Capability) wrote:
> I am trying to move a Linux root (/) file system to a larger disk
> format

I'm not sure what you mean by "a larger disk format" because:

> I was able to block copy the data from one device to the other using the DD 
> command below
> dd if=/dev/dasdb1 of=/dev/dasdd1 bs=64K
> conv=noerror,sync

This shows that you just copied an existing partition to a new partition, not 
an entire disk, and you didn't talk about resizing the file system on it, or 
how you avoided file system changes being missed on the, presumably active, 
source file system.

> But I need to make the new Device Bootable and normally I would use
> FDISK on a normal Linux system but FDASD does not have this function
>
> Is that the process of ZIPL?
> Am I just missing something in my process, or if someone has the steps
> and would like to share that would be great

Yes, you would use zipl to write out the bootloader, kernel, and initrd.
But, you need to make sure it writes things to the new disk, assuming that 
/boot is part of your root file system. If it's not part of / then you 
shouldn't have to do anything with this.

Is the reason you're doing this because everything is lumped into one large 
file system, and things like /usr, /tmp, etc., are all in it? If so, then 
there's a "how to" on linuxvm.org that talks about how you can split off things 
into separate file systems without having to move / around.


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
https://clicktime.symantec.com/a/1/LG8nbYHJk_3XOORmpwg-N7oFoVq0WdYhFyAtdI94OuQ=?d=YPn8voUO54RB-xI1pvK_hACCjmYgCMxXs4Dg578oeNOFouGBv_vN5O_wR0fXHE_1T5eAAeDrcm2mUMkAbmFKSA1BJ2rs1i18GFkNtUCpBg3l5MJgpvDfoG4VnoEJzGXknIvxXodt--j-ZLFU1s85eNzR9jcWxJHRizKEIavuVkLp8YT_7QCHUFX4nwXEtAnU4aXsIXoHAwb-wbMDkgeFByWlU9Xbs9yDQ9IQyO0haLDMhzAT_Qta7dJGu69urogGd4hp9AL8myTq1zdlPyrAquxEm-Ci6yYyHswbb5wM792IIK6RD1NtnM25xktA8IYL9Mf6AcGFhKcI9RXcjAbzsWstBDJZLvpMSs4dMlBc7a77OTmkmbR4Uh30a1a0lBY1QuObnXy6V-P8EedNylQr57CsH8VQaIgDNQ%3D%3D=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390

DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 
22102, USA.
DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates.  It is intended exclusively 
for the addressee.  The substance of this message, along with any attachments, 
may contain proprietary, confidential or privileged information or information 
that is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose. --.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving Root to Larger disk

[Mark Post]

On 6/26/20 9:54 AM, Davis, Larry (National VM Capability) wrote:
> I am trying to move a Linux root (/) file system to a larger disk format

I'm not sure what you mean by "a larger disk format" because:

> I was able to block copy the data from one device to the other using the DD 
> command below
> dd if=/dev/dasdb1 of=/dev/dasdd1 bs=64K conv=noerror,sync

This shows that you just copied an existing partition to a new
partition, not an entire disk, and you didn't talk about resizing the
file system on it, or how you avoided file system changes being missed
on the, presumably active, source file system.

> But I need to make the new Device Bootable and normally I would use FDISK on 
> a normal Linux system but FDASD does not have this function
> 
> Is that the process of ZIPL?
> Am I just missing something in my process, or if someone has the steps and 
> would like to share that would be great

Yes, you would use zipl to write out the bootloader, kernel, and initrd.
But, you need to make sure it writes things to the new disk, assuming
that /boot is part of your root file system. If it's not part of / then
you shouldn't have to do anything with this.

Is the reason you're doing this because everything is lumped into one
large file system, and things like /usr, /tmp, etc., are all in it? If
so, then there's a "how to" on linuxvm.org that talks about how you can
split off things into separate file systems without having to move / around.


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://www2.marist.edu/htbin/wlvindex?LINUX-390

Moving Root to Larger disk

[Davis, Larry (National VM Capability)]

I am trying to move a Linux root (/) file system to a larger disk format

I was able to block copy the data from one device to the other using the DD 
command below
dd if=/dev/dasdb1 of=/dev/dasdd1 bs=64K conv=noerror,sync

But I need to make the new Device Bootable and normally I would use FDISK on a 
normal Linux system but FDASD does not have this function

Is that the process of ZIPL?
Am I just missing something in my process, or if someone has the steps and 
would like to share that would be great


Larry Davis
Senior z/VM systems Architect, Enterprise Services
T +1.813.394.4240
DXC Technology dxc.technology


DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 
22102, USA.
DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose. --.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Moving z/vm and zlinux volumes from old dasd to new dasd

[Collinson.Shannon]

FYI--we did this recently using FDRPASVM (Innovation Data's z/VM companion to 
FDRPAS for z/OS), and man, it was quick, easy, and no downtime.  Of course, we 
were doing it alongside z/OS data on the same storage controllers, and we'd 
already owned FDR products for years, so it wasn't a big expense or change in 
procedure for us.  Sure made it simple, though, if you've got a lot to move...

Shannon Collinson

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott 
Rohling
Sent: Thursday, August 16, 2018 7:39 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd

Ah  - I see you meant for this to be run against new DASD -- assuming the
copy had been done...   I wasn't sure how/when the DASD would be copied to
the old...so it does depend...   the script should be run before or
after depending on the method ;-)

Scott Rohling

On Thu, Aug 16, 2018 at 4:35 PM Scott Rohling 
wrote:

> Good script -- I would use it 'after' the move though - not before..
> backout is much easier that way...   make changes on the new dasd - not the
> old.
>
> Use SAPL and change PDVOL= to correct address...   'then' run this script
> once everything comes up and looks good.   IMHO.
>
> Scott Rohling
>
> On Thu, Aug 16, 2018 at 4:16 PM Davis, Larry (National VM Capability) <
> larry.dav...@dxc.com> wrote:
>
>> For that process to work you will have to load a new Standalone program
>> Loader using the new Device address for the PDR volume on the PDVOL =
>>
>> Here is an example of an exec to load the IPL SALIPL file from the MAINT
>> 190 "S" disk
>>
>> MKSAIPL EXEC:
>> /* rexx exec */
>>
>> true  = (1=1)
>> false = \true
>> debug = TRUE
>>
>> /*  */
>> /*  */
>> /* Setup Procedures:*/
>> /*   1 NEED ACCESS TO THE Z/VM 6.4 IPL SALIPL TEXT DECK */
>> /*   2 If this is SSI Environment set to TRUE otherwise FALSE   */
>> /*   3 Is the virtual address the address the RESVOL is linked as?  */
>> /*   4 Is the volid of the RESVOL?  */
>> /*   5 Is the real address of the PDR VOLUME?   */
>> /*  */
>> /*  */
>>
>> ssi  = FALSE /* Set to TRUE when using SSI*/
>> DEV_ADDR = ''/* RESVOL Virtual Address*/
>> VOL_ID   = 'vv'  /* RESVOL Volume Serial Number   */
>> PD_VOL   = ''/* PDR VOLUME Real Address   */
>>
>>/* *** */
>>/* PDNUM is the offset extent for the CF0 PARM disk*/
>>/* PDVOL is the Real address for the PDR Volume*/
>>/* *** */
>>
>> if ssi Then do
>>   Say
>>   Say 'Loading SALIPL text deck for SSI on RESVOL' vol_id 'on' dev_addr
>>   Say
>>   IPL_PARM = 'FN=SYSTEM FT=CONFIG PDNUM=1 PDVOL=' pd_vol end Else do
>>   Say
>>   Say 'Loading SALIPL text deck on RESVOL' vol_id 'on' dev_addr
>>   Say
>>   IPL_PARM = 'FN=SYSTEM FT=CONFIG'
>> end
>>
>> if debug then do
>>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>>   'IPLPARMS' ipl_parm
>>say ' ADDRESS COMMAND SALIPL' dev_addr
>>say '  (' salp_opt
>> end
>> else do
>>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>>   'COMMENTS ? IPLPARMS' ipl_parm
>>
>>queue 'IPL Parameters Options are:  '
>>queue 'CONS= FN=fn FT=ft CLEARPDR REPAIR NOEXITS NOHCD PROMPT'
>>    queue 'PDNUM=n PDOFF=offset PDVOL=addr STORE=M/G/T/P/E  '
>>queue
>>
>>ADDRESS COMMAND 'SALIPL' dev_addr '(' salp_opt end
>>
>> Exit
>>
>>
>>
>> Larry Davis
>>
>>
>> -Original Message-
>> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
>> Davis, Jim [PRI-1PP]
>> Sent: Thursday, August 16, 2018 17:54
>> To: LINUX-390@VM.MARIST.EDU
>> Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd
>>
>> Thanks for the info. I get the following.
>>
>> Current IPL parameters:
>> FN=SYSTEMFT=CONFIGPDNUM=1  PDVOL=A84C
>> CONS=0908
>>
>> The PDVOL points to common volume which contains the SYSTEM CONFI

Re: Moving z/vm and zlinux volumes from old dasd to new dasd

[Davis, Jim [PRI-1PP]]

The process I would use would be as follows:

1) shutdown vm
2) take a safety backup from z/os of static six vm volumes.
3) ipl vm 
4) run saipl to change the PDVOL to new address.
5) shutdown vm
6) take a backup from z/os of static changed vm volumes.
7) CLIP old volumes to different names.
8) restore backup to new dasd addresses.
9) IPL vm from new ipl address.

If there is a problem:

10) restore safety backup to original dasd addresses
11) CLIP volumes on new address to different names
12) ipl VM



-Original Message-
From: Linux on 390 Port  On Behalf Of Scott Rohling
Sent: Thursday, August 16, 2018 7:39 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd

Ah  - I see you meant for this to be run against new DASD -- assuming the
copy had been done...   I wasn't sure how/when the DASD would be copied to
the old...so it does depend...   the script should be run before or
after depending on the method ;-)

Scott Rohling

On Thu, Aug 16, 2018 at 4:35 PM Scott Rohling 
wrote:

> Good script -- I would use it 'after' the move though - not before..
> backout is much easier that way...   make changes on the new dasd - not the
> old.
>
> Use SAPL and change PDVOL= to correct address...   'then' run this script
> once everything comes up and looks good.   IMHO.
>
> Scott Rohling
>
> On Thu, Aug 16, 2018 at 4:16 PM Davis, Larry (National VM Capability) 
> < larry.dav...@dxc.com> wrote:
>
>> For that process to work you will have to load a new Standalone 
>> program Loader using the new Device address for the PDR volume on the 
>> PDVOL =
>>
>> Here is an example of an exec to load the IPL SALIPL file from the 
>> MAINT
>> 190 "S" disk
>>
>> MKSAIPL EXEC:
>> /* rexx exec */
>>
>> true  = (1=1)
>> false = \true
>> debug = TRUE
>>
>> /*  */
>> /*  */
>> /* Setup Procedures:*/
>> /*   1 NEED ACCESS TO THE Z/VM 6.4 IPL SALIPL TEXT DECK */
>> /*   2 If this is SSI Environment set to TRUE otherwise FALSE   */
>> /*   3 Is the virtual address the address the RESVOL is linked as?  */
>> /*   4 Is the volid of the RESVOL?  */
>> /*   5 Is the real address of the PDR VOLUME?   */
>> /*  */
>> /*  
>> */
>>
>> ssi  = FALSE /* Set to TRUE when using SSI*/
>> DEV_ADDR = ''/* RESVOL Virtual Address*/
>> VOL_ID   = 'vv'  /* RESVOL Volume Serial Number   */
>> PD_VOL   = ''/* PDR VOLUME Real Address   */
>>
>>/* *** */
>>/* PDNUM is the offset extent for the CF0 PARM disk*/
>>/* PDVOL is the Real address for the PDR Volume*/
>>/* *** */
>>
>> if ssi Then do
>>   Say
>>   Say 'Loading SALIPL text deck for SSI on RESVOL' vol_id 'on' dev_addr
>>   Say
>>   IPL_PARM = 'FN=SYSTEM FT=CONFIG PDNUM=1 PDVOL=' pd_vol end Else do
>>   Say
>>   Say 'Loading SALIPL text deck on RESVOL' vol_id 'on' dev_addr
>>   Say
>>   IPL_PARM = 'FN=SYSTEM FT=CONFIG'
>> end
>>
>> if debug then do
>>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>>   'IPLPARMS' ipl_parm
>>say ' ADDRESS COMMAND SALIPL' dev_addr
>>say '  (' salp_opt
>> end
>> else do
>>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>>   'COMMENTS ? IPLPARMS' ipl_parm
>>
>>queue 'IPL Parameters Options are:  '
>>queue 'CONS= FN=fn FT=ft CLEARPDR REPAIR NOEXITS NOHCD PROMPT'
>>queue 'PDNUM=n PDOFF=offset PDVOL=addr STORE=M/G/T/P/E  '
>>queue
>>
>>ADDRESS COMMAND 'SALIPL' dev_addr '(' salp_opt end
>>
>> Exit
>>
>>
>>
>> Larry Davis
>>
>>
>> -Original Message-
>> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
>> Davis, Jim [PRI-1PP]
>> Sent: Thursday, August 16, 2018 17:54
>> To: LINUX-390@VM.MARIST.EDU
>> Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd
>>
>> Thanks for the info. I get the following.
>>
>> Current IPL parameters:
>> FN=SYSTEMFT=CONFIGPDNUM=1  PDVOL=A84C
>> C

Re: Moving z/vm and zlinux volumes from old dasd to new dasd

[Scott Rohling]

Ah  - I see you meant for this to be run against new DASD -- assuming the
copy had been done...   I wasn't sure how/when the DASD would be copied to
the old...so it does depend...   the script should be run before or
after depending on the method ;-)

Scott Rohling

On Thu, Aug 16, 2018 at 4:35 PM Scott Rohling 
wrote:

> Good script -- I would use it 'after' the move though - not before..
> backout is much easier that way...   make changes on the new dasd - not the
> old.
>
> Use SAPL and change PDVOL= to correct address...   'then' run this script
> once everything comes up and looks good.   IMHO.
>
> Scott Rohling
>
> On Thu, Aug 16, 2018 at 4:16 PM Davis, Larry (National VM Capability) <
> larry.dav...@dxc.com> wrote:
>
>> For that process to work you will have to load a new Standalone program
>> Loader using the new Device address for the PDR volume on the PDVOL =
>>
>> Here is an example of an exec to load the IPL SALIPL file from the MAINT
>> 190 "S" disk
>>
>> MKSAIPL EXEC:
>> /* rexx exec */
>>
>> true  = (1=1)
>> false = \true
>> debug = TRUE
>>
>> /*  */
>> /*  */
>> /* Setup Procedures:*/
>> /*   1 NEED ACCESS TO THE Z/VM 6.4 IPL SALIPL TEXT DECK */
>> /*   2 If this is SSI Environment set to TRUE otherwise FALSE   */
>> /*   3 Is the virtual address the address the RESVOL is linked as?  */
>> /*   4 Is the volid of the RESVOL?  */
>> /*   5 Is the real address of the PDR VOLUME?   */
>> /*  */
>> /*  */
>>
>> ssi  = FALSE /* Set to TRUE when using SSI*/
>> DEV_ADDR = ''/* RESVOL Virtual Address*/
>> VOL_ID   = 'vv'  /* RESVOL Volume Serial Number   */
>> PD_VOL   = ''/* PDR VOLUME Real Address   */
>>
>>/* *** */
>>/* PDNUM is the offset extent for the CF0 PARM disk*/
>>/* PDVOL is the Real address for the PDR Volume*/
>>/* *** */
>>
>> if ssi Then do
>>   Say
>>   Say 'Loading SALIPL text deck for SSI on RESVOL' vol_id 'on' dev_addr
>>   Say
>>   IPL_PARM = 'FN=SYSTEM FT=CONFIG PDNUM=1 PDVOL=' pd_vol end Else do
>>   Say
>>   Say 'Loading SALIPL text deck on RESVOL' vol_id 'on' dev_addr
>>   Say
>>   IPL_PARM = 'FN=SYSTEM FT=CONFIG'
>> end
>>
>> if debug then do
>>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>>   'IPLPARMS' ipl_parm
>>say ' ADDRESS COMMAND SALIPL' dev_addr
>>say '  (' salp_opt
>> end
>> else do
>>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>>   'COMMENTS ? IPLPARMS' ipl_parm
>>
>>queue 'IPL Parameters Options are:  '
>>queue 'CONS= FN=fn FT=ft CLEARPDR REPAIR NOEXITS NOHCD PROMPT'
>>    queue 'PDNUM=n PDOFF=offset PDVOL=addr STORE=M/G/T/P/E  '
>>queue
>>
>>ADDRESS COMMAND 'SALIPL' dev_addr '(' salp_opt end
>>
>> Exit
>>
>>
>>
>> Larry Davis
>>
>>
>> -Original Message-
>> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
>> Davis, Jim [PRI-1PP]
>> Sent: Thursday, August 16, 2018 17:54
>> To: LINUX-390@VM.MARIST.EDU
>> Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd
>>
>> Thanks for the info. I get the following.
>>
>> Current IPL parameters:
>> FN=SYSTEMFT=CONFIGPDNUM=1  PDVOL=A84C
>> CONS=0908
>>
>> The PDVOL points to common volume which contains the SYSTEM CONFIG file.
>>
>> I wonder if I can
>> Change PDVOL to the new address for the common volume.
>> Shutdown
>> Move all six volumes to their new addresses.
>> IPL from new res volume address.
>>
>>
>> -Original Message-
>> From: Linux on 390 Port  On Behalf Of Tom Huegel
>> Sent: Thursday, August 16, 2018 5:36 PM
>> To: LINUX-390@VM.MARIST.EDU
>> Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd
>>
>> Last question Q IPLPARMS
>>
>>
>> On Thu, Aug 16, 2018 at 4:14 PM, Davis, Jim [PRI-1PP] <
>> jim.da...@primerica.

Re: Moving z/vm and zlinux volumes from old dasd to new dasd

[Scott Rohling]

Good script -- I would use it 'after' the move though - not before..
backout is much easier that way...   make changes on the new dasd - not the
old.

Use SAPL and change PDVOL= to correct address...   'then' run this script
once everything comes up and looks good.   IMHO.

Scott Rohling

On Thu, Aug 16, 2018 at 4:16 PM Davis, Larry (National VM Capability) <
larry.dav...@dxc.com> wrote:

> For that process to work you will have to load a new Standalone program
> Loader using the new Device address for the PDR volume on the PDVOL =
>
> Here is an example of an exec to load the IPL SALIPL file from the MAINT
> 190 "S" disk
>
> MKSAIPL EXEC:
> /* rexx exec */
>
> true  = (1=1)
> false = \true
> debug = TRUE
>
> /*  */
> /*  */
> /* Setup Procedures:*/
> /*   1 NEED ACCESS TO THE Z/VM 6.4 IPL SALIPL TEXT DECK */
> /*   2 If this is SSI Environment set to TRUE otherwise FALSE   */
> /*   3 Is the virtual address the address the RESVOL is linked as?  */
> /*   4 Is the volid of the RESVOL?  */
> /*   5 Is the real address of the PDR VOLUME?   */
> /*  */
> /*  */
>
> ssi  = FALSE /* Set to TRUE when using SSI*/
> DEV_ADDR = ''/* RESVOL Virtual Address*/
> VOL_ID   = 'vv'  /* RESVOL Volume Serial Number   */
> PD_VOL   = ''/* PDR VOLUME Real Address   */
>
>/* *** */
>/* PDNUM is the offset extent for the CF0 PARM disk*/
>/* PDVOL is the Real address for the PDR Volume*/
>/* *** */
>
> if ssi Then do
>   Say
>   Say 'Loading SALIPL text deck for SSI on RESVOL' vol_id 'on' dev_addr
>   Say
>   IPL_PARM = 'FN=SYSTEM FT=CONFIG PDNUM=1 PDVOL=' pd_vol end Else do
>   Say
>   Say 'Loading SALIPL text deck on RESVOL' vol_id 'on' dev_addr
>   Say
>   IPL_PARM = 'FN=SYSTEM FT=CONFIG'
> end
>
> if debug then do
>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>   'IPLPARMS' ipl_parm
>say ' ADDRESS COMMAND SALIPL' dev_addr
>say '  (' salp_opt
> end
> else do
>salp_opt = 'EXTENT 1 VOLID' vol_id ,
>   'COMMENTS ? IPLPARMS' ipl_parm
>
>queue 'IPL Parameters Options are:  '
>queue 'CONS= FN=fn FT=ft CLEARPDR REPAIR NOEXITS NOHCD PROMPT'
>queue 'PDNUM=n PDOFF=offset PDVOL=addr STORE=M/G/T/P/E  '
>queue
>
>ADDRESS COMMAND 'SALIPL' dev_addr '(' salp_opt end
>
> Exit
>
>
>
> Larry Davis
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Davis, Jim [PRI-1PP]
> Sent: Thursday, August 16, 2018 17:54
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd
>
> Thanks for the info. I get the following.
>
> Current IPL parameters:
> FN=SYSTEMFT=CONFIGPDNUM=1  PDVOL=A84C
> CONS=0908
>
> The PDVOL points to common volume which contains the SYSTEM CONFIG file.
>
> I wonder if I can
> Change PDVOL to the new address for the common volume.
> Shutdown
> Move all six volumes to their new addresses.
> IPL from new res volume address.
>
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Tom Huegel
> Sent: Thursday, August 16, 2018 5:36 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd
>
> Last question Q IPLPARMS
>
>
> On Thu, Aug 16, 2018 at 4:14 PM, Davis, Jim [PRI-1PP] <
> jim.da...@primerica.com> wrote:
>
> > I have been tasked with moving our z/VM and zlinux file system volume
> > from an old DASD system to a New DASD system.
> > All of my device numbers / unit addresses will change.
> >
> > I have been successful in moving all of the z/linux volumes.
> >
> > My problem is how to move the 6 VM volumes since the IPL text has unit
> > addresses in it.
> >
> > In z/vm 5.x I just zapped the 2 addresses in ipl text.
> >
> > In z/VM 6.4 the ipl text has all of 6 volume address in text and some
> > in hex.
> >
> > Can I use SALIPL to change these addresses?
> >
> > SALIPL was run under the covers when I installed VM6.4; Is there a way
> > to

Re: Moving z/vm and zlinux volumes from old dasd to new dasd

[Davis, Larry (National VM Capability)]

For that process to work you will have to load a new Standalone program Loader 
using the new Device address for the PDR volume on the PDVOL =

Here is an example of an exec to load the IPL SALIPL file from the MAINT 190 
"S" disk

MKSAIPL EXEC:
/* rexx exec */

true  = (1=1)
false = \true
debug = TRUE

/*  */
/*  */
/* Setup Procedures:*/
/*   1 NEED ACCESS TO THE Z/VM 6.4 IPL SALIPL TEXT DECK */
/*   2 If this is SSI Environment set to TRUE otherwise FALSE   */
/*   3 Is the virtual address the address the RESVOL is linked as?  */
/*   4 Is the volid of the RESVOL?  */
/*   5 Is the real address of the PDR VOLUME?   */
/*  */
/*  */

ssi  = FALSE /* Set to TRUE when using SSI*/
DEV_ADDR = ''/* RESVOL Virtual Address*/
VOL_ID   = 'vv'  /* RESVOL Volume Serial Number   */
PD_VOL   = ''/* PDR VOLUME Real Address   */

   /* *** */
   /* PDNUM is the offset extent for the CF0 PARM disk*/
   /* PDVOL is the Real address for the PDR Volume*/
   /* *** */

if ssi Then do
  Say
  Say 'Loading SALIPL text deck for SSI on RESVOL' vol_id 'on' dev_addr
  Say
  IPL_PARM = 'FN=SYSTEM FT=CONFIG PDNUM=1 PDVOL=' pd_vol end Else do
  Say
  Say 'Loading SALIPL text deck on RESVOL' vol_id 'on' dev_addr
  Say
  IPL_PARM = 'FN=SYSTEM FT=CONFIG'
end

if debug then do
   salp_opt = 'EXTENT 1 VOLID' vol_id ,
  'IPLPARMS' ipl_parm
   say ' ADDRESS COMMAND SALIPL' dev_addr
   say '  (' salp_opt
end
else do
   salp_opt = 'EXTENT 1 VOLID' vol_id ,
  'COMMENTS ? IPLPARMS' ipl_parm

   queue 'IPL Parameters Options are:  '
   queue 'CONS= FN=fn FT=ft CLEARPDR REPAIR NOEXITS NOHCD PROMPT'
   queue 'PDNUM=n PDOFF=offset PDVOL=addr STORE=M/G/T/P/E  '
   queue

   ADDRESS COMMAND 'SALIPL' dev_addr '(' salp_opt end

Exit



Larry Davis


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Davis, 
Jim [PRI-1PP]
Sent: Thursday, August 16, 2018 17:54
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd

Thanks for the info. I get the following.

Current IPL parameters:
FN=SYSTEMFT=CONFIGPDNUM=1  PDVOL=A84C
CONS=0908

The PDVOL points to common volume which contains the SYSTEM CONFIG file.

I wonder if I can
Change PDVOL to the new address for the common volume.
Shutdown
Move all six volumes to their new addresses.
IPL from new res volume address.


-Original Message-
From: Linux on 390 Port  On Behalf Of Tom Huegel
Sent: Thursday, August 16, 2018 5:36 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd

Last question Q IPLPARMS


On Thu, Aug 16, 2018 at 4:14 PM, Davis, Jim [PRI-1PP] < 
jim.da...@primerica.com> wrote:

> I have been tasked with moving our z/VM and zlinux file system volume
> from an old DASD system to a New DASD system.
> All of my device numbers / unit addresses will change.
>
> I have been successful in moving all of the z/linux volumes.
>
> My problem is how to move the 6 VM volumes since the IPL text has unit
> addresses in it.
>
> In z/vm 5.x I just zapped the 2 addresses in ipl text.
>
> In z/VM 6.4 the ipl text has all of 6 volume address in text and some
> in hex.
>
> Can I use SALIPL to change these addresses?
>
> SALIPL was run under the covers when I installed VM6.4; Is there a way
> to find out what was passed as parms to SALIPL.
>
>
>
> James Davis
> jim.da...@primerica.com
> 470-564-5061
> "quando omni flunkus moritati"
>
> --
> 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 Syste

Re: Moving z/vm and zlinux volumes from old dasd to new dasd

[Davis, Larry (National VM Capability)]

Q IPLPARMS should display what was set in the IPL SALIPL when it was loaded to 
the RESVOL

When you move the VM Volumes as long as the VOLSER's don't change there should 
be no issues unless you are setting the new devices OFFLINE AT IPL  time in 
Your SYSTEM CONFIG file.

For the most part Spool Volumes and Page Volumes are defined in the CP_OWNED 
area and user volumes are set in the USER_VOLUME_INCLUDE or LIST section, both 
use VOLSER's rather than real device addresses



Larry Davis


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Davis, 
Jim [PRI-1PP]
Sent: Thursday, August 16, 2018 17:15
To: LINUX-390@VM.MARIST.EDU
Subject: Moving z/vm and zlinux volumes from old dasd to new dasd

I have been tasked with moving our z/VM and zlinux file system volume from an 
old DASD system to a New DASD system.
All of my device numbers / unit addresses will change.

I have been successful in moving all of the z/linux volumes.

My problem is how to move the 6 VM volumes since the IPL text has unit 
addresses in it.

In z/vm 5.x I just zapped the 2 addresses in ipl text.

In z/VM 6.4 the ipl text has all of 6 volume address in text and some in hex.

Can I use SALIPL to change these addresses?

SALIPL was run under the covers when I installed VM6.4; Is there a way to find 
out what was passed as parms to SALIPL.



James Davis
jim.da...@primerica.com
470-564-5061
"quando omni flunkus moritati"

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


DXC - This is a PRIVATE message - If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 
the Company to any order or other contract unless pursuant to explicit written 
agreement or government initiative expressly permitting the use of e-mail for 
such purpose.

--
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: Moving z/vm and zlinux volumes from old dasd to new dasd

[Alan Altmark]

 Just a small warning:  QUERY IPLPARMS shows you the parameters that will be 
used on SHUTDOWN REIPL.
 
 They will typically be the parameters that were in effect at IPL time, but 
they can be changed by SET IPLPARMS.
 
 I recommend updating AUTOLOG1 to stash away the output of QUERY IPLPARMS so 
that you can go back to the original values in case you mess things up.  Been 
there, done that.
 
 Alan Altmark


--
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: Moving z/vm and zlinux volumes from old dasd to new dasd

[Scott Rohling]

Yes - give it a parm of either SYSG  (the integrated 3270 console on the
HMC) -- or your main operator console address.   For example - if it is E00
...   Then enter PARM of E00 at the load screen...   then the SAPL screen
will come up there ..if on the normal console - just change PDVOL= ..
if on SYSG or another console address..  change PDVOL= and  add CONS=SYSG
or CONS=E00 to the parm line...

Scott Rohling

On Thu, Aug 16, 2018 at 3:17 PM Davis, Jim [PRI-1PP] <
jim.da...@primerica.com> wrote:

> I know what SALIPL and SAPL are but not SAIPL.
> Is SAIPL just a typo?
>
> When we IPL we never see the SAPL screen where I can override the PDVOL=
>
> The original install resulted in no SAPL screen being displayed.
>
> Is there a way to make this appear when IPLing?
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Scott
> Rohling
> Sent: Thursday, August 16, 2018 5:40 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd
>
> CP Query IPL   gives you the parms used...
>
> You can use SAIPL to bring up z/VM the first time on new DASD (just specify
> correct PDVOL=) ..   then run SALIPL on the IPL volume to make the parms
> stick and not need SAIPL next time..
>
> Scott  Rohling
>
> On Thu, Aug 16, 2018 at 2:17 PM Davis, Jim [PRI-1PP] <
> jim.da...@primerica.com> wrote:
>
> > I have been tasked with moving our z/VM and zlinux file system volume
> > from an old DASD system to a New DASD system.
> > All of my device numbers / unit addresses will change.
> >
> > I have been successful in moving all of the z/linux volumes.
> >
> > My problem is how to move the 6 VM volumes since the IPL text has unit
> > addresses in it.
> >
> > In z/vm 5.x I just zapped the 2 addresses in ipl text.
> >
> > In z/VM 6.4 the ipl text has all of 6 volume address in text and some
> > in hex.
> >
> > Can I use SALIPL to change these addresses?
> >
> > SALIPL was run under the covers when I installed VM6.4; Is there a way
> > to find out what was passed as parms to SALIPL.
> >
> >
> >
> > James Davis
> > jim.da...@primerica.com
> > 470-564-5061
> > "quando omni flunkus moritati"
> >
> > --
> > 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/
>
> --
> 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: Moving z/vm and zlinux volumes from old dasd to new dasd

[Davis, Jim [PRI-1PP]]

I know what SALIPL and SAPL are but not SAIPL.
Is SAIPL just a typo?

When we IPL we never see the SAPL screen where I can override the PDVOL=

The original install resulted in no SAPL screen being displayed.

Is there a way to make this appear when IPLing?

-Original Message-
From: Linux on 390 Port  On Behalf Of Scott Rohling
Sent: Thursday, August 16, 2018 5:40 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd

CP Query IPL   gives you the parms used...

You can use SAIPL to bring up z/VM the first time on new DASD (just specify
correct PDVOL=) ..   then run SALIPL on the IPL volume to make the parms
stick and not need SAIPL next time..

Scott  Rohling

On Thu, Aug 16, 2018 at 2:17 PM Davis, Jim [PRI-1PP] < jim.da...@primerica.com> 
wrote:

> I have been tasked with moving our z/VM and zlinux file system volume 
> from an old DASD system to a New DASD system.
> All of my device numbers / unit addresses will change.
>
> I have been successful in moving all of the z/linux volumes.
>
> My problem is how to move the 6 VM volumes since the IPL text has unit 
> addresses in it.
>
> In z/vm 5.x I just zapped the 2 addresses in ipl text.
>
> In z/VM 6.4 the ipl text has all of 6 volume address in text and some 
> in hex.
>
> Can I use SALIPL to change these addresses?
>
> SALIPL was run under the covers when I installed VM6.4; Is there a way 
> to find out what was passed as parms to SALIPL.
>
>
>
> James Davis
> jim.da...@primerica.com
> 470-564-5061
> "quando omni flunkus moritati"
>
> --
> 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/

--
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: Moving z/vm and zlinux volumes from old dasd to new dasd

[Fred Bader]

I have moved/cloned z/VM 6.4 systems and the only thing related to the new
DASD addresses that I've had to do is run SALIPL against the new IPL volume
and specify the real address of the device with the parm disk as part of
the IPLPARMS text.  For example, if F000 is the real address of the new
z/VM 6.4 IPL volume (640RES), and F004 is the real address of the new
volume with the parm disk containing the system configuration file (SYSTEM
CONFIG), then after attaching F000 to my userid, I issue SALIPL as follows:

SALIPL F000 (volid 640RES extent 1 minivol MNTCF1 iplparms fn=SYSTEM
ft=CONFIG pdnum=1 pdvol=F004

To determine the IPL parameters of the existing system, use the Q IPLPARMS
command.

Regards, Fred





From:   "Davis, Jim [PRI-1PP]" 
To: LINUX-390@VM.MARIST.EDU
Date:   08/16/2018 05:16 PM
Subject:Moving z/vm and zlinux volumes from old dasd to new dasd
Sent by:Linux on 390 Port 



I have been tasked with moving our z/VM and zlinux file system volume from
an old DASD system to a New DASD system.
All of my device numbers / unit addresses will change.

I have been successful in moving all of the z/linux volumes.

My problem is how to move the 6 VM volumes since the IPL text has unit
addresses in it.

In z/vm 5.x I just zapped the 2 addresses in ipl text.

In z/VM 6.4 the ipl text has all of 6 volume address in text and some in
hex.

Can I use SALIPL to change these addresses?

SALIPL was run under the covers when I installed VM6.4; Is there a way to
find out what was passed as parms to SALIPL.



James Davis
jim.da...@primerica.com
470-564-5061
"quando omni flunkus moritati"

--
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: Moving z/vm and zlinux volumes from old dasd to new dasd

[Davis, Jim [PRI-1PP]]

Thanks for the info. I get the following.

Current IPL parameters:
FN=SYSTEMFT=CONFIGPDNUM=1  PDVOL=A84C
CONS=0908

The PDVOL points to common volume which contains the SYSTEM CONFIG file.

I wonder if I can 
Change PDVOL to the new address for the common volume.
Shutdown 
Move all six volumes to their new addresses.
IPL from new res volume address.


-Original Message-
From: Linux on 390 Port  On Behalf Of Tom Huegel
Sent: Thursday, August 16, 2018 5:36 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving z/vm and zlinux volumes from old dasd to new dasd

Last question Q IPLPARMS


On Thu, Aug 16, 2018 at 4:14 PM, Davis, Jim [PRI-1PP] < 
jim.da...@primerica.com> wrote:

> I have been tasked with moving our z/VM and zlinux file system volume 
> from an old DASD system to a New DASD system.
> All of my device numbers / unit addresses will change.
>
> I have been successful in moving all of the z/linux volumes.
>
> My problem is how to move the 6 VM volumes since the IPL text has unit 
> addresses in it.
>
> In z/vm 5.x I just zapped the 2 addresses in ipl text.
>
> In z/VM 6.4 the ipl text has all of 6 volume address in text and some 
> in hex.
>
> Can I use SALIPL to change these addresses?
>
> SALIPL was run under the covers when I installed VM6.4; Is there a way 
> to find out what was passed as parms to SALIPL.
>
>
>
> James Davis
> jim.da...@primerica.com
> 470-564-5061
> "quando omni flunkus moritati"
>
> --
> 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/

--
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: Moving z/vm and zlinux volumes from old dasd to new dasd

[Scott Rohling]

CP Query IPL   gives you the parms used...

You can use SAIPL to bring up z/VM the first time on new DASD (just specify
correct PDVOL=) ..   then run SALIPL on the IPL volume to make the parms
stick and not need SAIPL next time..

Scott  Rohling

On Thu, Aug 16, 2018 at 2:17 PM Davis, Jim [PRI-1PP] <
jim.da...@primerica.com> wrote:

> I have been tasked with moving our z/VM and zlinux file system volume from
> an old DASD system to a New DASD system.
> All of my device numbers / unit addresses will change.
>
> I have been successful in moving all of the z/linux volumes.
>
> My problem is how to move the 6 VM volumes since the IPL text has unit
> addresses in it.
>
> In z/vm 5.x I just zapped the 2 addresses in ipl text.
>
> In z/VM 6.4 the ipl text has all of 6 volume address in text and some in
> hex.
>
> Can I use SALIPL to change these addresses?
>
> SALIPL was run under the covers when I installed VM6.4; Is there a way to
> find out what was passed as parms to SALIPL.
>
>
>
> James Davis
> jim.da...@primerica.com
> 470-564-5061
> "quando omni flunkus moritati"
>
> --
> 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: Moving z/vm and zlinux volumes from old dasd to new dasd

[Tom Huegel]

Last question Q IPLPARMS


On Thu, Aug 16, 2018 at 4:14 PM, Davis, Jim [PRI-1PP] <
jim.da...@primerica.com> wrote:

> I have been tasked with moving our z/VM and zlinux file system volume from
> an old DASD system to a New DASD system.
> All of my device numbers / unit addresses will change.
>
> I have been successful in moving all of the z/linux volumes.
>
> My problem is how to move the 6 VM volumes since the IPL text has unit
> addresses in it.
>
> In z/vm 5.x I just zapped the 2 addresses in ipl text.
>
> In z/VM 6.4 the ipl text has all of 6 volume address in text and some in
> hex.
>
> Can I use SALIPL to change these addresses?
>
> SALIPL was run under the covers when I installed VM6.4; Is there a way to
> find out what was passed as parms to SALIPL.
>
>
>
> James Davis
> jim.da...@primerica.com
> 470-564-5061
> "quando omni flunkus moritati"
>
> --
> 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/

Moving z/vm and zlinux volumes from old dasd to new dasd

[Davis, Jim [PRI-1PP]]

I have been tasked with moving our z/VM and zlinux file system volume from an 
old DASD system to a New DASD system.
All of my device numbers / unit addresses will change.

I have been successful in moving all of the z/linux volumes.

My problem is how to move the 6 VM volumes since the IPL text has unit 
addresses in it.

In z/vm 5.x I just zapped the 2 addresses in ipl text.

In z/VM 6.4 the ipl text has all of 6 volume address in text and some in hex.

Can I use SALIPL to change these addresses?

SALIPL was run under the covers when I installed VM6.4; Is there a way to find 
out what was passed as parms to SALIPL.



James Davis
jim.da...@primerica.com
470-564-5061
"quando omni flunkus moritati"

--
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: Moving zLinux to a bigger disk - solved

[Jan Höppner]

Hi Donald,

> Just FYI... I spent many hours tinkering with VM DRR and Linux dd and
> different experiments of formatting etc etc. I had a case open with Red
> Hat, which they eventually pretty much gave up on and gave me the source
> code for fdasd and dasdfmt (which is where I learned of the --mode expand
> option in the first place. It’s not in the man pages.)
> 

that made me worry for a second. I just checked on a fresh RHEL7.5
installation and the modes option is fully documented in the man pages.

Regards,
Jan

--
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: Moving zLinux to a bigger disk - solved

[Donald Russell]

Peter,
THANK YOU !! Using fdasd option u fixed it up. I was then able to expand
the file system and I now have a happy RHEL system on a mod-27 with lots of
spare space.

Just FYI... I spent many hours tinkering with VM DRR and Linux dd and
different experiments of formatting etc etc. I had a case open with Red
Hat, which they eventually pretty much gave up on and gave me the source
code for fdasd and dasdfmt (which is where I learned of the --mode expand
option in the first place. It’s not in the man pages.)

Like so many things, when you know how, it’s simple. Once again, the
informal, no-charge listserv community out-performs the paid-for official
support. TGFL - Thank God For Listserv.  LOL

Thanks again.
Donald Russell


On Fri, Jun 29, 2018 at 05:01 Peter Oberparleiter 
wrote:

> On 29.06.2018 00:10, Donald Russell wrote:
> > On Thu, Jun 28, 2018 at 14:27 Donald Russell 
> wrote:
> >> The dasdfmt -b 4096 --mode=expand worked great.   Started formatting the
> >> disk at track 150240 as expected.  But then fdasd choked saying only the
> >> first 10016 cylinders are formatted so I can’t create the new larger
> >> partition.
> >>
> >> How can I coerce fdasd into doing the right thing? Whatever fdasd is
> >> looking at for that cylinder count I expected dasdfmt to update.
> >>
> >> Where is that data, maybe I can just zap it with some other tool like
> cms
> >> pipe read/write track.
>
> fdasd is looking at the DASD's VTOC, specifically at the format 5 DSCB
> that is supposed to list free space extents on the volume. The 'dasdfmt
> --mode expand' call doesn't add the newly formatted extent to this DSCB,
> therefore fdasd assumes that that it is not formatted.
>
> This is a bug/limitation in dasdfmt/fdasd and we plan to fix this in a
> future version of s390-tools.
>
> In the meantime, you can try the following:
>
> # fdasd /dev/dasd...
> u ('re-create VTOC re-using existing partition sizes')
> y ('yes')
> w ('write table to disk and exit')
>
> You need to perform these steps TWICE, or fdasd will terminate with a
> "BUG..." statement when you try to create/change partitions afterwards.
>
>
> Regards,
>   Peter Oberparleiter
>
> --
> Peter Oberparleiter
> Linux on Z Development - IBM Germany
>
> --
> 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: Moving zLinux to a bigger disk

[Peter Oberparleiter]

On 29.06.2018 00:10, Donald Russell wrote:
> On Thu, Jun 28, 2018 at 14:27 Donald Russell  wrote:
>> The dasdfmt -b 4096 --mode=expand worked great.   Started formatting the
>> disk at track 150240 as expected.  But then fdasd choked saying only the
>> first 10016 cylinders are formatted so I can’t create the new larger
>> partition.
>>
>> How can I coerce fdasd into doing the right thing? Whatever fdasd is
>> looking at for that cylinder count I expected dasdfmt to update.
>>
>> Where is that data, maybe I can just zap it with some other tool like cms
>> pipe read/write track.

fdasd is looking at the DASD's VTOC, specifically at the format 5 DSCB
that is supposed to list free space extents on the volume. The 'dasdfmt
--mode expand' call doesn't add the newly formatted extent to this DSCB,
therefore fdasd assumes that that it is not formatted.

This is a bug/limitation in dasdfmt/fdasd and we plan to fix this in a
future version of s390-tools.

In the meantime, you can try the following:

# fdasd /dev/dasd...
u ('re-create VTOC re-using existing partition sizes')
y ('yes')
w ('write table to disk and exit')

You need to perform these steps TWICE, or fdasd will terminate with a
"BUG..." statement when you try to create/change partitions afterwards.


Regards,
  Peter Oberparleiter

-- 
Peter Oberparleiter
Linux on Z Development - IBM Germany

--
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: Moving zLinux to a bigger disk

[Mark Post]

>>> On 6/28/2018 at 06:10 PM, Donald Russell  wrote: 
> I forgot to put a subject.  Now there*s one.  :-)
> Don
> 
> On Thu, Jun 28, 2018 at 14:27 Donald Russell  wrote:
> 
-snip-
>> Any suggestions beyond install from scratch on the larger disk? :-)

What I typically do is:
1. Run dasdfmt on the whole of the new disk.
2. Copy the older/smaller volume to the new one
3. Use fdasd to print out the old partition table
4. Delete the old partition table
5. Recreate the partition table using the information from #3, but make sure 
the "last" partition goes to the end of the disk.

Even then, you have to understand just what to do with that new, larger 
partition in terms of what file system is on it, or if it's an LVM PV, etc. and 
jigger that around until the system knows just how much space it has.  The 
other possibility is to format the disk, create the partitions the way you want 
them, create any LVM PVs, LV, etc., create file systems, and then use the HOWTO 
at http://linuxvm.org/Info/HOWTOs/movefs.html to copy over the entire system.  
That will take considerably longer, since you're not doing large block I/Os, 
but depending on your comfort level with the previous method, it might be 
easier for you.


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/

Moving zLinux to a bigger disk

[Donald Russell]

I forgot to put a subject.  Now there’s one.  :-)
Don

On Thu, Jun 28, 2018 at 14:27 Donald Russell  wrote:

> I have RHEL 7 system on a mod-9 (10016 cup) ECKD DASD and want to move it
> to a mod-27 (32759 cyl).
>
> The disk is not in use, I used zVM/CMS to DDR the disk to the larger one.
> Then I attached it to a zLinux system to format the back end of the disk.
> After that I would remove the last partition and create a new partition
> extending to the end of disk and finally  resize the file system in that
> partition.
>
> The dasdfmt -b 4096 --mode=expand worked great.   Started formatting the
> disk at track 150240 as expected.  But then fdasd choked saying only the
> first 10016 cylinders are formatted so I can’t create the new larger
> partition.
>
> How can I coerce fdasd into doing the right thing? Whatever fdasd is
> looking at for that cylinder count I expected dasdfmt to update.
>
> Where is that data, maybe I can just zap it with some other tool like cms
> pipe read/write track.
>
> I also tried dasdfmt --mode=quick which fixed my fdasd issue.  It now got
> the right size of the disk but that removes the IPL record and who knows
> what else so the disk was no longer bootable.
>
> Any suggestions beyond install from scratch on the larger disk? :-)
>
> Thanks,
> Don
>
> Thu 28 Jun 20:58:17 UTC
> [root@sl55zdump] ~
> #dasdfmt -b 4096 --mode=expand /dev/dasdr
> Expansion mode active. Searching for starting position...
> Done. Unformatted part starts at track 150240.
> Drive Geometry: 32759 Cylinders * 15 Heads =  491385 Tracks
>
> I am going to format the device /dev/dasdr in the following way:
>Device number of device : 0x200
>Labelling device: yes
>Disk label  : VOL1
>Disk identifier : 0X0200
>Extent start (trk no)   : 150240
>Extent end (trk no) : 491384
>Compatible Disk Layout  : yes
>Blocksize   : 4096
>Mode: Expand
>
> Type "yes" to continue, no will leave the disk untouched: yes
> Formatting the device. This may take a while (get yourself a coffee).
>
> Finished formatting the device.
> Rereading the partition table... ok
>
> Thu 28 Jun 21:05:40 UTC
> [root@sl55zdump] ~
> #fdasd /dev/dasdr
> reading volume label ..: VOL1
> reading vtoc ..: ok
> WARNING: This device is not fully formatted! Only 10016 of 32759 cylinders
> are available.
>
>
>
>
>
>
>
>

--
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: Moving on

[Fred Bader]

>  I started in the business in 1972.  Our local college had an 8k IBM 1130
Almost immediately,
> I wanted to find out move about it. After graduation, I went to work at
my present employer
> (Baldor).  After 40 years here, I have accepted an early retirement.

Sounds like we both got into the business around the same time.  My
university did have an S/360
model 65 with LCS, but the first actual hands on access to a computer was a
S/360 model 20.

Enjoy your retirement or whatever you do in the next chapter of your life.

>  (Anyone happen to have the instructions on haw to move  to  a different
email address.
> I am using a work email  address that will be killed in the next day or
two.)

I don't know of a way to change your E-mail address on the mailing list,
but if you go to
http://www2.marist.edu/htbin/wlvindex?LINUX-390 and scroll down to
"Subscription request"
near the bottom of the page, you can subscribe with your personal E-mail
address, and after
that is active, you can unsubscribe from your work E-mail address.

Fred Bader


--
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: Moving on

[Bfishing]

I just unsubscribed with my old email and reset with a personal one. Really
makes sense noting Corp social policies these days too.

Kurt

On Feb 9, 2017 1:08 PM, "Mark Post"  wrote:

>>> On 2/8/2017 at 02:57 PM, Ron Foster  wrote:
> After 40 years here, I have accepted an early retirement.

Hi, Ron,

Glad to hear you're able to retire.  Are you going to actually retire, or
look for work elsewhere?

It was nice getting to know you via work and at SHARE.  Whatever your plans
are, I hope you enjoy them.


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: Moving on

[Mark Post]

>>> On 2/8/2017 at 02:57 PM, Ron Foster  wrote: 
> After 40 years here, I have accepted an early retirement.

Hi, Ron,

Glad to hear you're able to retire.  Are you going to actually retire, or look 
for work elsewhere?

It was nice getting to know you via work and at SHARE.  Whatever your plans 
are, I hope you enjoy them.


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: Moving on

[Scott Rohling]

​While the IT guys might be willing - I'd hope the company's business and
security policies wouldn't allow that.Any forwarding should be to
whoever will be responsible for Ron's business communications and Baldor.
 Less messy all around to just subscribe with your own personal email.

Scott Rohling

On Thu, Feb 9, 2017 at 8:57 AM, Paul Dembry <p...@trifox.com> wrote:

> Create a gmail account and ask Baldor's IT to auto-forward your emails for
> a
> couple of months?
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ron
> Foster
> Sent: Wednesday, February 08, 2017 11:57 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Moving on
>
> I started in the business in 1972.  Our local college had an 8k IBM 1130
> Almost immediately,  I wanted to find out move about it. After graduation,
> I
> went to work at my present employer(Baldor).  After 40 years here, I have
> accepted an early retirement.
>
>
> I enjoyed the people on the mailing list. They almost always had the answer
> to whatever problem. I was having at the moment.
>
>
> It was always nice to put a face with a name at SHARE.
>
>
> Thanks mailing list.  Keep helping people.
>
>
> (Anyone happen to have the instructions on haw to move  to  a different
> email address.
>
> I am using a work email  address that will be killed in the next day or
> two.)
>
> Ron Foster
>
> ABB - Fort Smith
>
> Large Systems Analyst
>
> 5711 R S Boreham Jr Street
>
> Fort Smith, AR 72901
>
> Phone:479-648-5865
>
> Fax:479-648-5985
>
> Email: ron.fos...@us.abb.com<mailto:ron.fos...@baldor.abb.com>
>
> IM Address:ron.fos...@us.abb.com
>
> www.baldor.com<http://www.baldor.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/
>
> --
> 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: Moving on

[Paul Dembry]

Create a gmail account and ask Baldor's IT to auto-forward your emails for a
couple of months?

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ron
Foster
Sent: Wednesday, February 08, 2017 11:57 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Moving on

I started in the business in 1972.  Our local college had an 8k IBM 1130
Almost immediately,  I wanted to find out move about it. After graduation, I
went to work at my present employer(Baldor).  After 40 years here, I have
accepted an early retirement.


I enjoyed the people on the mailing list. They almost always had the answer
to whatever problem. I was having at the moment.


It was always nice to put a face with a name at SHARE.


Thanks mailing list.  Keep helping people.


(Anyone happen to have the instructions on haw to move  to  a different
email address.

I am using a work email  address that will be killed in the next day or
two.)

Ron Foster

ABB - Fort Smith

Large Systems Analyst

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-648-5985

Email: ron.fos...@us.abb.com<mailto:ron.fos...@baldor.abb.com>

IM Address:ron.fos...@us.abb.com

www.baldor.com<http://www.baldor.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/

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

Moving on

[Ron Foster]

I started in the business in 1972.  Our local college had an 8k IBM 1130  
Almost immediately,  I wanted to find out move about it. After graduation, I 
went to work at my present employer(Baldor).  After 40 years here, I have 
accepted an early retirement.


I enjoyed the people on the mailing list. They almost always had the answer to 
whatever problem. I was having at the moment.


It was always nice to put a face with a name at SHARE.


Thanks mailing list.  Keep helping people.


(Anyone happen to have the instructions on haw to move  to  a different email 
address.

I am using a work email  address that will be killed in the next day or two.)

Ron Foster

ABB - Fort Smith

Large Systems Analyst

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-648-5985

Email: ron.fos...@us.abb.com

IM Address:ron.fos...@us.abb.com

www.baldor.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: Moving on

[Leonard Santalucia]

Congratulations, Mike!!

Regards, Len

Leonard J. Santalucia
CTO | Business Development Manager | Certified Specialist
Vicom Infinity, Inc.
IBM Premier Business Partner
One Penn Plaza - Suite 2010
New York, New York 10119
Office804-918-3728 
Cell…….917-856-4493
eFax413-622-1229
vText……… 9178564...@vtext.com
My Blog http://www.infinite-blue.com/blog/
Vicom Infinity http://www.vicominfinity.com
Vicom Computer Services http://www.vicomnet.com/ 
Infinity Systems http://www.infinite-blue.com




-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael 
MacIsaac
Sent: Monday, August 17, 2015 10:43 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Moving on

Hello lists,

I have again started a new job, moving on from Innovation Data Processing to 
ADP.

At Innovation, helping to roll out the FDRPASVM product that allows you to 
migrate running Linux and z/VM systems to new DASD regardless of manufacturer 
was a challenging and satisfying project.  However, most of that work was 
winding down.

As ADP has a continually growing z/VM and Linux environment, they should keep 
me busy for many years to come.  I look forward to this new role.

-Mike MacIsaac

--
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: Moving on

[Rick Troth]

congrats!


On 08/17/2015 10:43 AM, Michael MacIsaac wrote:
 I have again started a new job, moving on from Innovation Data Processing
 to ADP.

 At Innovation, helping to roll out the FDRPASVM product that allows you to
 migrate running Linux and z/VM systems to new DASD regardless of
 manufacturer was a challenging and satisfying project.  However, most of
 that work was winding down.

 As ADP has a continually growing z/VM and Linux environment, they should
 keep me busy for many years to come.  I look forward to this new role.

 -Mike MacIsaac

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

Moving on

[Michael MacIsaac]

Hello lists,

I have again started a new job, moving on from Innovation Data Processing
to ADP.

At Innovation, helping to roll out the FDRPASVM product that allows you to
migrate running Linux and z/VM systems to new DASD regardless of
manufacturer was a challenging and satisfying project.  However, most of
that work was winding down.

As ADP has a continually growing z/VM and Linux environment, they should
keep me busy for many years to come.  I look forward to this new role.

-Mike MacIsaac

--
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: Moving on

[Mark Post]

 On 8/17/2015 at 10:43 AM, Michael MacIsaac mike99...@gmail.com wrote: 
 Hello lists,
 
 I have again started a new job, moving on from Innovation Data Processing
 to ADP.

It's starting to get difficult to keep track of you lately.  After 30 years in 
one place, now you're job hopping.  :)  I hope things work well for both ADP 
and you.


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: Moving on

[Mauro Souza]

Congratulations Mike!

ADP is a company I admire very much, you will have fun working there.
On Aug 17, 2015 11:49, Leonard Santalucia lsantalu...@vicominfinity.com
wrote:

 Congratulations, Mike!!

 Regards, Len

 Leonard J. Santalucia
 CTO | Business Development Manager | Certified Specialist
 Vicom Infinity, Inc.
 IBM Premier Business Partner
 One Penn Plaza - Suite 2010
 New York, New York 10119
 Office804-918-3728
 Cell…….917-856-4493
 eFax413-622-1229
 vText……… 9178564...@vtext.com
 My Blog http://www.infinite-blue.com/blog/
 Vicom Infinity http://www.vicominfinity.com
 Vicom Computer Services http://www.vicomnet.com/
 Infinity Systems http://www.infinite-blue.com




 -Original Message-
 From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
 Michael MacIsaac
 Sent: Monday, August 17, 2015 10:43 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Moving on

 Hello lists,

 I have again started a new job, moving on from Innovation Data Processing
 to ADP.

 At Innovation, helping to roll out the FDRPASVM product that allows you to
 migrate running Linux and z/VM systems to new DASD regardless of
 manufacturer was a challenging and satisfying project.  However, most of
 that work was winding down.

 As ADP has a continually growing z/VM and Linux environment, they should
 keep me busy for many years to come.  I look forward to this new role.

 -Mike MacIsaac

 --
 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: Moving on

[David Kreuter]

Congratulations Mike!
We will need to reinstate a moving on list just for you.
David

div Original message /divdivFrom: Michael MacIsaac 
mike99...@gmail.com /divdivDate:08-17-2015  11:43  (GMT-04:00) 
/divdivTo: LINUX-390@VM.MARIST.EDU /divdivSubject: Moving on /divdiv
/divHello lists,

I have again started a new job, moving on from Innovation Data Processing
to ADP.

At Innovation, helping to roll out the FDRPASVM product that allows you to
migrate running Linux and z/VM systems to new DASD regardless of
manufacturer was a challenging and satisfying project.  However, most of
that work was winding down.

As ADP has a continually growing z/VM and Linux environment, they should
keep me busy for many years to come.  I look forward to this new role.

-Mike MacIsaac

--
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: Moving on

[Terry Spaulding]

Congrats and good luck on your new job Mike...

 I have again started a new job, moving on from Innovation Data Processing
 to ADP.

 At Innovation, helping to roll out the FDRPASVM product that allows you
to
 migrate running Linux and z/VM systems to new DASD regardless of
 manufacturer was a challenging and satisfying project.  However, most of
 that work was winding down.

 As ADP has a continually growing z/VM and Linux environment, they should
 keep me busy for many years to come.  I look forward to this new role.

-Mike MacIsaac

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

Destination z articles -- moving a data center (two parts)

[Gabe Goldberg]

I previously sent first article, not second. Here are both parts...

Planning for Data Center Move Is Critical
Clearly defining steps and outcome before a move, upgrade or build helps
ensure a smooth transition to success
http://www.destinationz.org/Mainframe-Solution/Systems-Administration/Planning-for-Data-Center-Move-Is-Critical
http://tinyurl.com/lfg7rnt

Flexibility Needed During Execution of Data Center Move
Having backup plans and defined roles makes the move easier when
surprises arise
http://www.destinationz.org/Mainframe-Solution/Systems-Administration/Flexibility-Needed-During-Execution-of-Data-Center
http://tinyurl.com/pdcea79

Thanks to people who answered the query for this...

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

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

Automatische Antwort: Destination z articles -- moving a data center (two parts)

[Tasler Robert MSS sIT]

Ich bin zur Zeit nicht im Haus. Meine Mails werden nicht weitergeleitet.

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

Porto Alegre: A smarter city that keeps its citizens moving

[Neale Ferguson]

Porto Alegre: A smarter city that keeps its citizens moving

http://www-03.ibm.com/software/businesscasestudies/us/en/corp?synkey=L470824Z40607B29
Sent from LinkedIn for Android

Re: Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

[Feller, Paul]

I can answer #3.  Yes z/VM 5.4 will run on a z114.  We are running it on a z196 
(big brother to z114), but we had to apply maintenance to z/VM 5.4.  

You can find a list of PTFs for z/VM 5.4 to support the z196 and z114 at 
http://www.vm.ibm.com/service/vmreqze.html

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Bruce Arro
Sent: Monday, May 27, 2013 4:41 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

Hi list

Looking for the way forward.

Have a Z9 with 1 CP and 5 IFL's. Have 4 X Z/VM 5.4 LPARS with various versions 
of SUSE Linux running as guests and a Z/OS Prod and Test Lpar.

Are installing a Z114 in a few weeks time and would like to upgrade to Z/VM 6.2 
also

Questions.

1) Is it easier to move the Z/VM 5.4 Lpars over with the Suse Guest's and then 
upgrade to Z/VM 6.2? Or should I install Z/VM 6.2 and then move the guests 
(Will keep all of the device address's the same on the new machine.)

2) According to IBM Z/OS 1.7 will not run natively in an LPAR on the Z114. We 
need to run it under Z/VM as a guest. Has anyone run into this problem? - 
Though I would create a separate Lpar with Z/VM and 2 X Z/OS guests (Prod an 
Test)

3) Does Z/VM 5.4 run on a Z114?

Regards
Bruce Arro

--
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: Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

[Shane G]

And just for completeness, I have a customer happily running 5.4 on a z114.

I would go for 6.2 on the new box, but you'd have to think IBM would cane you
something awful with licensing for running z/OS as guests.
Needs must I suppose ...

Shane ...

On Tue, May 28th, 2013 at 8:09 PM, Feller, Paul wrote:

 I can answer #3.  Yes z/VM 5.4 will run on a z114.  We are running it on a
 z196 (big brother to z114), but we had to apply maintenance to z/VM 5.4. 

...
 Hi list
 
 Looking for the way forward.
 
 Have a Z9 with 1 CP and 5 IFL's. Have 4 X Z/VM 5.4 LPARS with various
 versions of SUSE Linux running as guests and a Z/OS Prod and Test Lpar.
 
 Are installing a Z114 in a few weeks time and would like to upgrade to
 Z/VM 6.2 also
 
 Questions.
 
 1) Is it easier to move the Z/VM 5.4 Lpars over with the Suse Guest's and
 then upgrade to Z/VM 6.2? Or should I install Z/VM 6.2 and then move the
 guests (Will keep all of the device address's the same on the new
 machine.)
 
 2) According to IBM Z/OS 1.7 will not run natively in an LPAR on the Z114.
 We need to run it under Z/VM as a guest. Has anyone run into this problem?
 - Though I would create a separate Lpar with Z/VM and 2 X Z/OS guests
 (Prod an Test)
 
 3) Does Z/VM 5.4 run on a Z114?

--
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: Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

[Kurt Acker]

z/VM 540 is at least supported on a z114... however running production zOS
under z/VM is not really recommended so I have to ask why you are not
considering upgrading zOS?  That would also have to help simplify your
System z push/pull process for the upgrade.

Here is a quick high level z114 FAQ doc that includes supported levels of
operating systems:
http://public.dhe.ibm.com/common/ssi/ecm/en/zsq03051usen/ZSQ03051USEN.PDF

Kurt Acker
IBM Smarter Planet, Smarter Data Centers
Virtualization and Enterprise System Management Technologies

--
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: Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

[Alan Altmark]

On Monday, 05/27/2013 at 04:43 EDT, Bruce Arro ba...@amcotec.co.za
wrote:
 Have a Z9 with 1 CP and 5 IFL's. Have 4 X Z/VM 5.4 LPARS with various
versions
 of SUSE Linux running as guests and a Z/OS Prod and Test Lpar.

 Are installing a Z114 in a few weeks time and would like to upgrade to
Z/VM 6.2
 also

 Questions.

 1) Is it easier to move the Z/VM 5.4 Lpars over with the Suse Guest's
and then
 upgrade to Z/VM 6.2? Or should I install Z/VM 6.2 and then move the
guests
 (Will keep all of the device address's the same on the new machine.)

The tried-and-true approach to migration is to change as few things as
possible.
1.  Put z/VM 5.4, with enabling PTFs, on your z114
2.  Apply any z114-related patches to Linux
3.  Move them to the z114.
4.  Validate
5.  Upgrade z114 to z/VM 6.2
6.  Validate

 2) According to IBM Z/OS 1.7 will not run natively in an LPAR on the
Z114. We
 need to run it under Z/VM as a guest. Has anyone run into this problem?
-
 Though I would create a separate Lpar with Z/VM and 2 X Z/OS guests
(Prod an
 Test)

That depends on why it won't run.  z/VM does not protect a guest from the
new processor architecture, but it *will* limit the guest to a single
channel subsystem.  Of course, even if it ran it wouldn't be supported.

 3) Does Z/VM 5.4 run on a Z114?

With service, yes.   See http://www.vm.ibm.com/zvm540/ for links to
required service for zEC12, z196/z114, and for Crypto Express3 and FICON
Express.


Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
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: Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

[Alan Altmark]

On Tuesday, 05/28/2013 at 06:29 EDT, Shane G ibm-m...@tpg.com.au wrote:
 I would go for 6.2 on the new box, but you'd have to think IBM would
cane you
 something awful with licensing for running z/OS as guests.

Why?  Some of my IBM brethren are more knowledgeable on this subject than
I, but I believe that as long as you license z/OS  Friends on a
subcapacity basis, you won't have any bruises (that show), since you must
run SCRT on all z/OS instances, including z/VM guests.  The z/OS guests
will report capacity that accounts for the guest's SHARE values.  If you
don't have sub-cap pricing, all bets are off.

(Also making the point that running z/OS on z/VM, whether production or
test, isn't free.  I've run into a few people over the years who thought
otherwise)

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
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: Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

[Alan Altmark]

On Tuesday, 05/28/2013 at 09:14 EDT, Kurt Acker/Endicott/IBM@IBMUS wrote:
 z/VM 540 is at least supported on a z114... however running production
zOS
 under z/VM is not really recommended

There was a time when even the minimal overhead of z/VM was enough to make
running z/OS as a guest ill-suited for production.  As z/VM has been
enhanced to work better with large virtual machines and with the speed of
z10+ machines, it has finally moved into the realm of fast enough.   The
old not recommended rule no longer applies.

These days, the decision to run z/OS in production on z/VM needs to be
made based on measurements, and configuration and capability requirements
(e.g. access to real CF).

See http://www.vm.ibm.com/zos.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
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/

Z9 to Z114, Z/VM5.4 to Z/VM6.2 and moving Z/OS to a guest?

[Bruce Arro]

Hi list

Looking for the way forward.

Have a Z9 with 1 CP and 5 IFL's. Have 4 X Z/VM 5.4 LPARS with various versions 
of SUSE Linux running as guests and a Z/OS Prod and Test Lpar.

Are installing a Z114 in a few weeks time and would like to upgrade to Z/VM 6.2 
also

Questions.

1) Is it easier to move the Z/VM 5.4 Lpars over with the Suse Guest's and then 
upgrade to Z/VM 6.2? Or should I install Z/VM 6.2 and then move the guests 
(Will keep all of the device address's the same on the new machine.)

2) According to IBM Z/OS 1.7 will not run natively in an LPAR on the Z114. We 
need to run it under Z/VM as a guest. Has anyone run into this problem? - 
Though I would create a separate Lpar with Z/VM and 2 X Z/OS guests (Prod an 
Test)

3) Does Z/VM 5.4 run on a Z114?

Regards
Bruce Arro

--
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: Moving Root DASD

[Steffen Maier]

On 10/11/2012 11:20 PM, Scott Rohling wrote:

The easiest thing to do is bring the guest down and  LINK these 2 disks
from another running Linux ..  mount them as /mnt /mnt/disk1 and 2 and copy
- I would use rsync:

rsync -av /mnt/disk1/  /mnt/disk2


In case you follow down this path, don't forget to rewrite the 
bootloader since the boot files are now at different places on the disk 
after having copied the content file by file:

chroot /mnt/disk2
zipl -V
exit


Unmount, detach - and swap the disks in the directory so the big disk is
the same address as the old small one.


In case you don't want to / cannot rename the DASD devno, you can adjust 
it in above workflow between the chroot and the zipl call with:

vi /etc/fstab
vi /etc/zipl.conf
# use the distro mechanism to configure root devno such that it'll
# set it (or them in case of multi-PV LVM rootfs) online during boot
mkinitrd # not necessary with RHEL6

With zfcp attached scsi disks this is usually mandatory since one can 
hardly influence target WWPN and LUN to be the same after moving to 
another disk (or even a disk in another storage system).



If you don't have another running Linux you can do something similar by
booting the install kernel from the reader and getting into the recovery
shell..   I don't think the rsync command is there, so you'd have to use
the 'cp' command or a tar pipe.

Scott Rohling


On Thu, Oct 11, 2012 at 12:41 PM, Ben Duncan b...@linux4ms.net wrote:


Hi group. Need to some help in transferring and recreating the ROOT ( /
) dasd device to another dasd
Specifically we want to migrate from a 300MB partition and replace it
with a 2Gb partition which is
already formatted and prepped.


Any pointer or how to's on this ?


Steffen Maier

Linux on System z Development

IBM Deutschland Research  Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

--
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: Moving Root DASD

[Thomas Denier]

Would he need to execute the 'chroot' and 'zipl' commands after
copying the disk contents?

Thomas Denier
Thomas Jefferson University Hospital

-Scott Rohling wrote: -

The easiest thing to do is bring the guest down and  LINK these 2
disks
from another running Linux ..  mount them as /mnt /mnt/disk1 and 2
and copy
- I would use rsync:

rsync -av /mnt/disk1/  /mnt/disk2

Unmount, detach - and swap the disks in the directory so the big disk
is
the same address as the old small one.

If you don't have another running Linux you can do something similar
by
booting the install kernel from the reader and getting into the
recovery
shell..   I don't think the rsync command is there, so you'd have to
use
the 'cp' command or a tar pipe.

Scott Rohling


On Thu, Oct 11, 2012 at 12:41 PM, Ben Duncan b...@linux4ms.net
wrote:

 Hi group. Need to some help in transferring and recreating the ROOT
( /
 ) dasd device to another dasd
 Specifically we want to migrate from a 300MB partition and replace
it
 with a 2Gb partition which is
 already formatted and prepped.


 Any pointer or how to's on this ?

 Thanks ...

 Ben Duncan - Business Network Solutions, Inc. 336 Elton Road
Jackson
 MS, 39212
--
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/

Moving Root DASD

[Ben Duncan]

Hi group. Need to some help in transferring and recreating the ROOT ( /
) dasd device to another dasd
Specifically we want to migrate from a 300MB partition and replace it
with a 2Gb partition which is
already formatted and prepped.


Any pointer or how to's on this ?

Thanks ...

Ben Duncan - Business Network Solutions, Inc. 336 Elton Road  Jackson
MS, 39212
Never attribute to malice, that which can be adequately explained by
stupidity
- Hanlon's Razor



--
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: Moving Root DASD

[Scott Rohling]

The easiest thing to do is bring the guest down and  LINK these 2 disks
from another running Linux ..  mount them as /mnt /mnt/disk1 and 2 and copy
- I would use rsync:

rsync -av /mnt/disk1/  /mnt/disk2

Unmount, detach - and swap the disks in the directory so the big disk is
the same address as the old small one.

If you don't have another running Linux you can do something similar by
booting the install kernel from the reader and getting into the recovery
shell..   I don't think the rsync command is there, so you'd have to use
the 'cp' command or a tar pipe.

Scott Rohling


On Thu, Oct 11, 2012 at 12:41 PM, Ben Duncan b...@linux4ms.net wrote:

 Hi group. Need to some help in transferring and recreating the ROOT ( /
 ) dasd device to another dasd
 Specifically we want to migrate from a 300MB partition and replace it
 with a 2Gb partition which is
 already formatted and prepped.


 Any pointer or how to's on this ?

 Thanks ...

 Ben Duncan - Business Network Solutions, Inc. 336 Elton Road  Jackson
 MS, 39212
 Never attribute to malice, that which can be adequately explained by
 stupidity
 - Hanlon's Razor



 --
 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: Moving Root DASD

[Mark Post]

 On 10/11/2012 at 03:41 PM, Ben Duncan b...@linux4ms.net wrote: 
 Hi group. Need to some help in transferring and recreating the ROOT ( /
 ) dasd device to another dasd
 Specifically we want to migrate from a 300MB partition and replace it
 with a 2Gb partition which is
 already formatted and prepped.
 
 
 Any pointer or how to's on this ?

I wouldn't do it in the first place.  If you need additional space, add DASD 
volumes, use them to create an LVM VG and LVs, and migrate things like /usr, 
/var, /tmp, etc. to them using http://linuxvm.org/Info/HOWTOs/movefs.html


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/

MEMO: Moving Over, Not On

[Mark Post]

All,

I'm writing to inform everyone that effective today, I have transferred from 
Novell Technical Services to the SUSE SLE Core team.  (No more on call duty! 
Yay!)

Part of my charter is to help determine what our customers want and need in the 
way of improvements and new features, and use that try to influence our Product 
Management team for SLE.  I have my own list of things in mind, but I would 
appreciate any thoughts on that subject from this audience.  I'll be at SHARE 
in Atlanta, and hope I get into some conversations about this while I'm there 
as well.

Another part of my charter is to document features, write white papers, etc., 
for our customers in collaboration with the developers that created them.  
(Amazingly enough, most developers don't want to take the time to write about 
what they're doing. :)  If there's any specific area of the documentation you 
think needs cleaning up, or clarification, please let me know about that and 
I'll see what I can do.


Thanks in advance for your help,

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/