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

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

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

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/

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/

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

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/

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

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/

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/

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/

Re: Moving LVM volume group to another system

[Jonathan Quay]

Did you do a vgscan?

On Wed, Dec 21, 2011 at 9:33 AM, Mark Pace pacemainl...@gmail.com wrote:

 I've had a disk failure on my linux root filesystem, please don't ask how
 that happened, and now need to move an LVM file system to another Linux
 guest.
 I've added all the disk to the guest, put them all online and doing a
 pvscan I see that they are all there.  What I can't figure out is how to
 bring them into this system.  Every reference I find is for when you were
 able to do an vgexport ahead of time.  I didn't have that luxury and so I
 can not do a vgimport.

 --
 The postings on this site are my own and don’t necessarily represent
 Mainline’s positions or opinions

 Mark D Pace
 Senior Systems Engineer
 Mainline Information Systems

 --
 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 LVM volume group to another system

[Mark Pace]

Yes.
sles003:/srv/ftp # vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group vg1 using metadata type lvm2



On Wed, Dec 21, 2011 at 9:42 AM, Jonathan Quay jonathan.q...@ihg.comwrote:

 Did you do a vgscan?

 On Wed, Dec 21, 2011 at 9:33 AM, Mark Pace pacemainl...@gmail.com wrote:

  I've had a disk failure on my linux root filesystem, please don't ask how
  that happened, and now need to move an LVM file system to another Linux
  guest.
  I've added all the disk to the guest, put them all online and doing a
  pvscan I see that they are all there.  What I can't figure out is how to
  bring them into this system.  Every reference I find is for when you were
  able to do an vgexport ahead of time.  I didn't have that luxury and so I
  can not do a vgimport.
 
  --
  The postings on this site are my own and don’t necessarily represent
  Mainline’s positions or opinions
 
  Mark D Pace
  Senior Systems Engineer
  Mainline Information Systems
 
  --
  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/




-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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 LVM volume group to another system

[Jonathan Quay]

Can you see the /dev/mapper structures now?  Mount 'em up.

* *

On Wed, Dec 21, 2011 at 9:50 AM, Mark Pace pacemainl...@gmail.com wrote:

 Yes.
 sles003:/srv/ftp # vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group vg1 using metadata type lvm2



 On Wed, Dec 21, 2011 at 9:42 AM, Jonathan Quay jonathan.q...@ihg.com
 wrote:

  Did you do a vgscan?
 
  On Wed, Dec 21, 2011 at 9:33 AM, Mark Pace pacemainl...@gmail.com
 wrote:
 
   I've had a disk failure on my linux root filesystem, please don't ask
 how
   that happened, and now need to move an LVM file system to another Linux
   guest.
   I've added all the disk to the guest, put them all online and doing a
   pvscan I see that they are all there.  What I can't figure out is how
 to
   bring them into this system.  Every reference I find is for when you
 were
   able to do an vgexport ahead of time.  I didn't have that luxury and
 so I
   can not do a vgimport.
  
   --
   The postings on this site are my own and don’t necessarily represent
   Mainline’s positions or opinions
  
   Mark D Pace
   Senior Systems Engineer
   Mainline Information Systems
  
   --
   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/
 



 --
 The postings on this site are my own and don’t necessarily represent
 Mainline’s positions or opinions

 Mark D Pace
 Senior Systems Engineer
 Mainline Information Systems

 --
 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 LVM volume group to another system

[Mark Pace]

That didn't seem to help.
But I did do an lvscan  which showed that the lv was inactive.  So I did an
lvchange -ay  and that did create the devices so that I could mount the
system.

Thanks very much

On Wed, Dec 21, 2011 at 10:03 AM, Jonathan Quay jonathan.q...@ihg.comwrote:

 Can you see the /dev/mapper structures now?  Mount 'em up.

 * *

 On Wed, Dec 21, 2011 at 9:50 AM, Mark Pace pacemainl...@gmail.com wrote:

  Yes.
  sles003:/srv/ftp # vgscan
   Reading all physical volumes.  This may take a while...
   Found volume group vg1 using metadata type lvm2
 
 
 
  On Wed, Dec 21, 2011 at 9:42 AM, Jonathan Quay jonathan.q...@ihg.com
  wrote:
 
   Did you do a vgscan?
  
   On Wed, Dec 21, 2011 at 9:33 AM, Mark Pace pacemainl...@gmail.com
  wrote:
  
I've had a disk failure on my linux root filesystem, please don't ask
  how
that happened, and now need to move an LVM file system to another
 Linux
guest.
I've added all the disk to the guest, put them all online and doing a
pvscan I see that they are all there.  What I can't figure out is how
  to
bring them into this system.  Every reference I find is for when you
  were
able to do an vgexport ahead of time.  I didn't have that luxury and
  so I
can not do a vgimport.
   
--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions
   
Mark D Pace
Senior Systems Engineer
Mainline Information Systems
   
   
 --
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/
  
 
 
 
  --
  The postings on this site are my own and don’t necessarily represent
  Mainline’s positions or opinions
 
  Mark D Pace
  Senior Systems Engineer
  Mainline Information Systems
 
  --
  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/




-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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 LVM volume group to another system

[Mark Post]

 On 12/21/2011 at 10:10 AM, Mark Pace pacemainl...@gmail.com wrote: 
 That didn't seem to help.
 But I did do an lvscan  which showed that the lv was inactive.  So I did an
 lvchange -ay  and that did create the devices so that I could mount the
 system.

The command you're looking for is vgchange -a y which will automatically make 
the LVs active.


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 LVM volume group to another system

[Mark Pace]

Thanks,  I hope to never need it again.  But as the last 2 days have
shown.  You never know!

On Wed, Dec 21, 2011 at 1:13 PM, Mark Post mp...@novell.com wrote:

  On 12/21/2011 at 10:10 AM, Mark Pace pacemainl...@gmail.com wrote:
  That didn't seem to help.
  But I did do an lvscan  which showed that the lv was inactive.  So I did
 an
  lvchange -ay  and that did create the devices so that I could mount the
  system.

 The command you're looking for is vgchange -a y which will automatically
 make the LVs active.


 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/




-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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 Oracle off zLinux boxes -- comments from the field?

[Christopher Cox]

Oracle is NOT supporting them well on zLinux.   So... there's both the
financial and technical reason.

Why would anyone stay with a platform that is not well supported?  Oracle
couldn't handle it, so they are moving.

Now... certainly the false mindset issue surrounding mainframes is an
issue... but I'd probably move Oracle too if they weren't willing to
address support issues in a timely manner.

Maybe it's time to change your database supplier??  You know, if if you
have to move it, I wonder if moving to something a bit more heavy duty,
like a IBM Power7 box was even considered...  If DB2 isn't an option, maybe
Oracle on Power7 would be a better fit (saying without knowledge of
Oracle's commitment of support there as well).




From:   Barton Robinson bar...@vm1.velocity-software.com
To: LINUX-390@vm.marist.edu
Date:   03/18/2011 04:04 PM
Subject:Re: Moving Oracle off zLinux boxes -- comments from the field?
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a
 zLinux  Application group planning meeting at our worksite. The DBA
 advised us that they (Database group) were going to move/migrate all the
 Oracle databases that we have on zLinux boxes off to an intel/unix
 platform. He did not offer details of the hardware, or when or how, just
 that they were going to do it. This is a bite of a surprise as we have
 just moved our MQ off the Mainframe (zOS) to the zLinux platform (guests
 on zVM) and that move is doing well. This may be due in part to the
 false mindset that we have in our upper management at our site that
 Mainframes are old technology. Also we have had slow response from
 Oracle on resolving issues we have identify (certifying Oracle 11 on
 z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x
 architecture). Has anyone else on this list had any related war
 stories similar to what we may be about to experience as this move
 takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


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

inline: graycol.gif

Re: Moving Oracle off zLinux boxes -- comments from the field?

[Barton Robinson]

so is this guy a troll or just someone clueless (and i'm tryin to be
nice). And I assume that Alan is behind the wood shed counciling...

Considering Oracle is extremely virtual friendly where DB2 is completely
virtual hostile (polling at 200,000 times a second was for High
Availability or something silly). Considering MANY positive experiences
presented around the world for Oracle, and zero for DB2, i just better stop.

Christopher Cox wrote:

Oracle is NOT supporting them well on zLinux.   So... there's both the
financial and technical reason.

Why would anyone stay with a platform that is not well supported?  Oracle
couldn't handle it, so they are moving.

Now... certainly the false mindset issue surrounding mainframes is an
issue... but I'd probably move Oracle too if they weren't willing to
address support issues in a timely manner.

Maybe it's time to change your database supplier??  You know, if if you
have to move it, I wonder if moving to something a bit more heavy duty,
like a IBM Power7 box was even considered...  If DB2 isn't an option, maybe
Oracle on Power7 would be a better fit (saying without knowledge of
Oracle's commitment of support there as well).




From:   Barton Robinson bar...@vm1.velocity-software.com
To: LINUX-390@vm.marist.edu
Date:   03/18/2011 04:04 PM
Subject:Re: Moving Oracle off zLinux boxes -- comments from the field?
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:

We just had a surprise announcement by one of the Oracle DBAs during a
zLinux  Application group planning meeting at our worksite. The DBA
advised us that they (Database group) were going to move/migrate all the
Oracle databases that we have on zLinux boxes off to an intel/unix
platform. He did not offer details of the hardware, or when or how, just
that they were going to do it. This is a bite of a surprise as we have
just moved our MQ off the Mainframe (zOS) to the zLinux platform (guests
on zVM) and that move is doing well. This may be due in part to the
false mindset that we have in our upper management at our site that
Mainframes are old technology. Also we have had slow response from
Oracle on resolving issues we have identify (certifying Oracle 11 on
z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x
architecture). Has anyone else on this list had any related war
stories similar to what we may be about to experience as this move
takes place?



James Chaplin

Systems Programmer, MVS, zVM  zLinux



--
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/
attachment: BARTON.vcf

Re: Moving Oracle off zLinux boxes -- comments from the field?

[Simms, Michael]

I suspect, I'm unfortunately not a fly on the wall, that Oracle simply wants to 
sell their newly acquired hardware 'division', Sun. But that is only 
speculation. This almost looks like a strong shove away from the hardware they 
can't handle, apparently. 

I can just see Jack Nickelson screaming to Larry, 'You can't handle the 
mainframe!!' (except for zO$, I guess it's $upported.)

Unfortunately, the application we bought must use Oracle, at least that's my 
understanding. So that kind of messes with using DB2 as a replacement. The 
application we are gearing up will be very heavily used, 60+ sites, all with 
very frequent updates.
So, we need the power of the mainframe IFLs and i/o system. But if Oracle 
doesn't get their support/certification in gear we may have to consider 
something less than what we were expecting and it would be similar to what is 
happening in James shop. We'll cross that road when we get to it.

-Original Message-
From: Linux on 390 Port on behalf of Christopher Cox
Sent: Wed 3/23/2011 11:11 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?
 

Oracle is NOT supporting them well on zLinux.   So... there's both the
financial and technical reason.

Why would anyone stay with a platform that is not well supported?  Oracle
couldn't handle it, so they are moving.

Now... certainly the false mindset issue surrounding mainframes is an
issue... but I'd probably move Oracle too if they weren't willing to
address support issues in a timely manner.

Maybe it's time to change your database supplier??  You know, if if you
have to move it, I wonder if moving to something a bit more heavy duty,
like a IBM Power7 box was even considered...  If DB2 isn't an option, maybe
Oracle on Power7 would be a better fit (saying without knowledge of
Oracle's commitment of support there as well).




From:   Barton Robinson bar...@vm1.velocity-software.com
To: LINUX-390@vm.marist.edu
Date:   03/18/2011 04:04 PM
Subject:Re: Moving Oracle off zLinux boxes -- comments from the field?
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a
 zLinux  Application group planning meeting at our worksite. The DBA
 advised us that they (Database group) were going to move/migrate all the
 Oracle databases that we have on zLinux boxes off to an intel/unix
 platform. He did not offer details of the hardware, or when or how, just
 that they were going to do it. This is a bite of a surprise as we have
 just moved our MQ off the Mainframe (zOS) to the zLinux platform (guests
 on zVM) and that move is doing well. This may be due in part to the
 false mindset that we have in our upper management at our site that
 Mainframes are old technology. Also we have had slow response from
 Oracle on resolving issues we have identify (certifying Oracle 11 on
 z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x
 architecture). Has anyone else on this list had any related war
 stories similar to what we may be about to experience as this move
 takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


--
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 Oracle off zLinux boxes -- comments from the field?

[Norman Hollander on DesertWiz]

Apparently someone's reality is some other alternate universe.  The real
issue, not being a technical one,
is the political-management error of listening to DBAs with some other
unreal agenda.  That's really the shocking
part of the story.  And using that part to serve as fact, is my issue with
this.  I know that Oracle on Linux can work well,
and that's the truth.

zNorman

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Barton
Robinson
Sent: Wednesday, March 23, 2011 Wednesday 8:58 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?

so is this guy a troll or just someone clueless (and i'm tryin to be nice).
And I assume that Alan is behind the wood shed counciling...

Considering Oracle is extremely virtual friendly where DB2 is completely
virtual hostile (polling at 200,000 times a second was for High Availability
or something silly). Considering MANY positive experiences presented around
the world for Oracle, and zero for DB2, i just better stop.

Christopher Cox wrote:
 Oracle is NOT supporting them well on zLinux.   So... there's both the
 financial and technical reason.

 Why would anyone stay with a platform that is not well supported?
 Oracle couldn't handle it, so they are moving.

 Now... certainly the false mindset issue surrounding mainframes is
 an issue... but I'd probably move Oracle too if they weren't willing
 to address support issues in a timely manner.

 Maybe it's time to change your database supplier??  You know, if if
 you have to move it, I wonder if moving to something a bit more heavy
 duty, like a IBM Power7 box was even considered...  If DB2 isn't an
 option, maybe Oracle on Power7 would be a better fit (saying without
 knowledge of Oracle's commitment of support there as well).




 From: Barton Robinson bar...@vm1.velocity-software.com
 To:   LINUX-390@vm.marist.edu
 Date: 03/18/2011 04:04 PM
 Subject:  Re: Moving Oracle off zLinux boxes -- comments from the
field?
 Sent by:  Linux on 390 Port LINUX-390@vm.marist.edu



 wow, your DBAs have the authority to spend that kind of money and make
 that kind of change without management signature? So no financial
 analysis, no technical reason, sounds religious.

 CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during
 a zLinux  Application group planning meeting at our worksite. The
 DBA advised us that they (Database group) were going to move/migrate
 all the Oracle databases that we have on zLinux boxes off to an
 intel/unix platform. He did not offer details of the hardware, or
 when or how, just that they were going to do it. This is a bite of a
 surprise as we have just moved our MQ off the Mainframe (zOS) to the
 zLinux platform (guests on zVM) and that move is doing well. This may
 be due in part to the false mindset that we have in our upper
 management at our site that Mainframes are old technology. Also we
 have had slow response from Oracle on resolving issues we have
 identify (certifying Oracle 11 on z390x architecture, getting Oracle
 10 support for RHEL 5.0 on z390x architecture). Has anyone else on
 this list had any related war stories similar to what we may be
 about to experience as this move takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


 --
 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 Oracle off zLinux boxes -- comments from the field?

[Pat Carroll]

Works *very* well here. 


Patrick Carroll  |  Technology Architect II 
L.L.Bean, Inc.(r) |  Double L St. |  Freeport ME 04033 
http://www.llbean.com | pcarr...@llbean.com | 207.552.2426 

CONFIDENTIALITY NOTICE: This e-mail and any attachments may contain 
confidential information that is legally privileged. The information is solely 
for the use of the intended recipient(s). Any disclosure, copying, 
distribution, or other use of this information is strictly prohibited. If you 
have received this e-mail in error, please notify the sender by return e-mail 
and delete this message.


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
Christopher Cox
Sent: Wednesday, March 23, 2011 11:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?


Oracle is NOT supporting them well on zLinux.   So... there's both the
financial and technical reason.

Why would anyone stay with a platform that is not well supported?  Oracle 
couldn't handle it, so they are moving.

Now... certainly the false mindset issue surrounding mainframes is an 
issue... but I'd probably move Oracle too if they weren't willing to address 
support issues in a timely manner.

Maybe it's time to change your database supplier??  You know, if if you have to 
move it, I wonder if moving to something a bit more heavy duty, like a IBM 
Power7 box was even considered...  If DB2 isn't an option, maybe Oracle on 
Power7 would be a better fit (saying without knowledge of Oracle's commitment 
of support there as well).




From:   Barton Robinson bar...@vm1.velocity-software.com
To: LINUX-390@vm.marist.edu
Date:   03/18/2011 04:04 PM
Subject:Re: Moving Oracle off zLinux boxes -- comments from the field?
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



wow, your DBAs have the authority to spend that kind of money and make that 
kind of change without management signature? So no financial analysis, no 
technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a 
 zLinux  Application group planning meeting at our worksite. The DBA 
 advised us that they (Database group) were going to move/migrate all 
 the Oracle databases that we have on zLinux boxes off to an intel/unix 
 platform. He did not offer details of the hardware, or when or how, 
 just that they were going to do it. This is a bite of a surprise as we 
 have just moved our MQ off the Mainframe (zOS) to the zLinux platform 
 (guests on zVM) and that move is doing well. This may be due in part 
 to the false mindset that we have in our upper management at our site 
 that Mainframes are old technology. Also we have had slow response 
 from Oracle on resolving issues we have identify (certifying Oracle 11 
 on z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x 
 architecture). Has anyone else on this list had any related war 
 stories similar to what we may be about to experience as this move 
 takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


--
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 Oracle off zLinux boxes -- comments from the field?

[Tom Duerbusch]

I have Oracle 10g R 2 running on zLinux.  I really haven't had many problems 
with it.

But I always wondered
Is there an application related reason that they need the latest, greatest 
release of Oracle, some new bell or whistle or were they just reading the 
latest trade rag?

My gut says that the Open Systems types always needs the latest software in 
order to support the latest hardware, which changes frequently.  Just how often 
are there mainframe hardware changes made that an application, or middleware is 
aware of?  Hipersockets?  Dataspaces?  64 bit addressing?  Anything else?

Here, I can't get anyone interested in new releases.  They are very happy as 
is.  G

About 5 years ago or so, I think it was Oracle that stated that not every 
release will be available for the mainframe.  However, they will support the 
mainframe releases longer than they normally do to keep in line with the 
mainframe methods.  

Not that I was watching, but I didn't hear about loads of mainframes replacing 
DB2/UDB 9.5 with DB2/UDB 9.7. 

At some point, I expect to have Oracle 11 up and running.  It would be 
concurrent with 10 g, most likely for years.  Easy with zLinux.  Sometimes that 
can be a bad thing also G.

Tom Duerbusch
THD Consulting 
(of course I still have some SLES7 images running)

 Simms, Michael michael.si...@hma.com 3/23/2011 11:09 AM 
I suspect, I'm unfortunately not a fly on the wall, that Oracle simply wants to 
sell their newly acquired hardware 'division', Sun. But that is only 
speculation. This almost looks like a strong shove away from the hardware they 
can't handle, apparently. 

I can just see Jack Nickelson screaming to Larry, 'You can't handle the 
mainframe!!' (except for zO$, I guess it's $upported.)

Unfortunately, the application we bought must use Oracle, at least that's my 
understanding. So that kind of messes with using DB2 as a replacement. The 
application we are gearing up will be very heavily used, 60+ sites, all with 
very frequent updates.
So, we need the power of the mainframe IFLs and i/o system. But if Oracle 
doesn't get their support/certification in gear we may have to consider 
something less than what we were expecting and it would be similar to what is 
happening in James shop. We'll cross that road when we get to it.

-Original Message-
From: Linux on 390 Port on behalf of Christopher Cox
Sent: Wed 3/23/2011 11:11 AM
To: LINUX-390@VM.MARIST.EDU 
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?
 

Oracle is NOT supporting them well on zLinux.   So... there's both the
financial and technical reason.

Why would anyone stay with a platform that is not well supported?  Oracle
couldn't handle it, so they are moving.

Now... certainly the false mindset issue surrounding mainframes is an
issue... but I'd probably move Oracle too if they weren't willing to
address support issues in a timely manner.

Maybe it's time to change your database supplier??  You know, if if you
have to move it, I wonder if moving to something a bit more heavy duty,
like a IBM Power7 box was even considered...  If DB2 isn't an option, maybe
Oracle on Power7 would be a better fit (saying without knowledge of
Oracle's commitment of support there as well).




From:   Barton Robinson bar...@vm1.velocity-software.com
To: LINUX-390@vm.marist.edu 
Date:   03/18/2011 04:04 PM
Subject:Re: Moving Oracle off zLinux boxes -- comments from the field?
Sent by:Linux on 390 Port LINUX-390@vm.marist.edu



wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a
 zLinux  Application group planning meeting at our worksite. The DBA
 advised us that they (Database group) were going to move/migrate all the
 Oracle databases that we have on zLinux boxes off to an intel/unix
 platform. He did not offer details of the hardware, or when or how, just
 that they were going to do it. This is a bite of a surprise as we have
 just moved our MQ off the Mainframe (zOS) to the zLinux platform (guests
 on zVM) and that move is doing well. This may be due in part to the
 false mindset that we have in our upper management at our site that
 Mainframes are old technology. Also we have had slow response from
 Oracle on resolving issues we have identify (certifying Oracle 11 on
 z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x
 architecture). Has anyone else on this list had any related war
 stories similar to what we may be about to experience as this move
 takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


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

Re: Moving Oracle off zLinux boxes -- comments from the field?

[David Kreuter]

The poster must have been confusing our world with vmware. Grins. We are
supported.
Echoing Barton Oracle runs *VERY WELL*.  IBM has experts that will come
in tune the LIVING DAYLIGHTS out of
Oracle - including reaching back and repairing crummy SQL statements.  I
have witnessed one SQL statement tuned resulting in saving 40% of an
IFL.

  The IBM Oracle team including Gaylan Braselton, David Simpson and Sam
Avesalu to name a few are highly skilled and helpful.

I have had clients successfully running hundreds of LOZ Oracle virtual
machines decide that windows was the solution to all problems.  It is
religo politico - cannot argue with that type of vaporized logic.  

David


 Original Message 
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?
From: Pat Carroll pcarr...@llbean.com
Date: Wed, March 23, 2011 1:30 pm
To: LINUX-390@VM.MARIST.EDU

Works *very* well here. 


Patrick Carroll | Technology Architect II 
L.L.Bean, Inc.(r) | Double L St. | Freeport ME 04033 
http://www.llbean.com | pcarr...@llbean.com | 207.552.2426 

CONFIDENTIALITY NOTICE: This e-mail and any attachments may contain
confidential information that is legally privileged. The information is
solely for the use of the intended recipient(s). Any disclosure,
copying, distribution, or other use of this information is strictly
prohibited. If you have received this e-mail in error, please notify the
sender by return e-mail and delete this message.


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
Christopher Cox
Sent: Wednesday, March 23, 2011 11:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?


Oracle is NOT supporting them well on zLinux. So... there's both the
financial and technical reason.

Why would anyone stay with a platform that is not well supported? Oracle
couldn't handle it, so they are moving.

Now... certainly the false mindset issue surrounding mainframes is an
issue... but I'd probably move Oracle too if they weren't willing to
address support issues in a timely manner.

Maybe it's time to change your database supplier?? You know, if if you
have to move it, I wonder if moving to something a bit more heavy duty,
like a IBM Power7 box was even considered... If DB2 isn't an option,
maybe Oracle on Power7 would be a better fit (saying without knowledge
of Oracle's commitment of support there as well).




From: Barton Robinson bar...@vm1.velocity-software.com
To: LINUX-390@vm.marist.edu
Date: 03/18/2011 04:04 PM
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?
Sent by: Linux on 390 Port LINUX-390@vm.marist.edu



wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a 
 zLinux  Application group planning meeting at our worksite. The DBA 
 advised us that they (Database group) were going to move/migrate all 
 the Oracle databases that we have on zLinux boxes off to an intel/unix 
 platform. He did not offer details of the hardware, or when or how, 
 just that they were going to do it. This is a bite of a surprise as we 
 have just moved our MQ off the Mainframe (zOS) to the zLinux platform 
 (guests on zVM) and that move is doing well. This may be due in part 
 to the false mindset that we have in our upper management at our site 
 that Mainframes are old technology. Also we have had slow response 
 from Oracle on resolving issues we have identify (certifying Oracle 11 
 on z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x 
 architecture). Has anyone else on this list had any related war 
 stories similar to what we may be about to experience as this move 
 takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


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

Re: Moving Oracle off zLinux boxes -- comments from the field?

[Alan Altmark]

On Wednesday, 03/23/2011 at 12:09 EDT, Barton Robinson
bar...@vm1.velocity-software.com wrote:
 so is this guy a troll or just someone clueless (and i'm tryin to be
 nice). And I assume that Alan is behind the wood shed counciling...

I will graciously assume that you were referring to some other Alan,
since I am not involved in any such woodshed-induced behavior.  I find
that the choice of database server is based more on politics, vendor
certifications, and available in-house expertise than on any technical
merit.

Alan Altmark

z/VM and Linux on System z 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: Moving Oracle off zLinux boxes -- comments from the field?

[Martin, Terry R. (CMS/CTR) (CTR)]

We have moved a 7TB Oracle data base from Solaris to z/Linux along with the 
applications that access the data base and other than some startup issues we 
have had no problems. In fact the applications have never run better. Now I 
will say if you just move the data bases up and do nothing to tune them you are 
going to have problems. We took a lot of time up front to make sure that the 
Data Base was efficient. When we first got it up on z/Linux it was not 
performing very well at all constant issues with performance and such. We found 
that the data base needed some work like additional indexes, and some other 
Oracle parameter changes. We are in the process of moving about 28 data base 
servers from Solaris to z/Linux which represents about 108 data bases of all 
sizes.

Now I can tell you that we did have some support challenges with Oracle on z 
initially, but the customers upper management has engaged Oracle's upper 
management and have ironed most of the issues. Oracle is working right along 
with us in this conversion effort and has committed to Oracle on z. 

Since our POC with 3 z/Linux guests in 2008 we now have 110 z/Linux guests 
running on z and we have had very few issues. It took some work up front a lot 
tuning and such but at this point I believe if you asked the end users if they 
wanted to go back to mid-tier they would give you an emphatic NO. 

I would say don't be too quick to throw your hands up on this. With patients 
and some work up front you can have yourself a well running environment backed 
by arguably the most reliable, accessible, and stable Virtual environment 
around, the mainframe running z/VM and z/Linux, not to mention the I/O 
capabilities of the mainframe are unparalleled. 


Thank You,

Terry Martin
Lockheed Martin
CMS - CITIC
3300 Lord Baltimore Drive, Suite 200, 21244  
Engineering Computing
Mainframe Support
Cell - 443 632-4191


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of David 
Kreuter
Sent: Wednesday, March 23, 2011 3:48 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?

The poster must have been confusing our world with vmware. Grins. We are
supported.
Echoing Barton Oracle runs *VERY WELL*.  IBM has experts that will come
in tune the LIVING DAYLIGHTS out of
Oracle - including reaching back and repairing crummy SQL statements.  I
have witnessed one SQL statement tuned resulting in saving 40% of an
IFL.

  The IBM Oracle team including Gaylan Braselton, David Simpson and Sam
Avesalu to name a few are highly skilled and helpful.

I have had clients successfully running hundreds of LOZ Oracle virtual
machines decide that windows was the solution to all problems.  It is
religo politico - cannot argue with that type of vaporized logic.  

David


 Original Message 
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?
From: Pat Carroll pcarr...@llbean.com
Date: Wed, March 23, 2011 1:30 pm
To: LINUX-390@VM.MARIST.EDU

Works *very* well here. 


Patrick Carroll | Technology Architect II 
L.L.Bean, Inc.(r) | Double L St. | Freeport ME 04033 
http://www.llbean.com | pcarr...@llbean.com | 207.552.2426 

CONFIDENTIALITY NOTICE: This e-mail and any attachments may contain
confidential information that is legally privileged. The information is
solely for the use of the intended recipient(s). Any disclosure,
copying, distribution, or other use of this information is strictly
prohibited. If you have received this e-mail in error, please notify the
sender by return e-mail and delete this message.


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
Christopher Cox
Sent: Wednesday, March 23, 2011 11:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?


Oracle is NOT supporting them well on zLinux. So... there's both the
financial and technical reason.

Why would anyone stay with a platform that is not well supported? Oracle
couldn't handle it, so they are moving.

Now... certainly the false mindset issue surrounding mainframes is an
issue... but I'd probably move Oracle too if they weren't willing to
address support issues in a timely manner.

Maybe it's time to change your database supplier?? You know, if if you
have to move it, I wonder if moving to something a bit more heavy duty,
like a IBM Power7 box was even considered... If DB2 isn't an option,
maybe Oracle on Power7 would be a better fit (saying without knowledge
of Oracle's commitment of support there as well).




From: Barton Robinson bar...@vm1.velocity-software.com
To: LINUX-390@vm.marist.edu
Date: 03/18/2011 04:04 PM
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?
Sent by: Linux on 390 Port LINUX-390@vm.marist.edu



wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So

Re: Moving Oracle off zLinux boxes -- comments from the field?

[Saulo Silva]

Hi James ,

There is a couple information that should be knowing before someone take
some strange decision like that . The first is your machine model and size
of the linux guest , and also the number of linux guest running at the same
lpar .

About the Oracle slow response , that would really depends of the problem ,
maybe the same slow response could be happening at all other platforms .
Although did they contact IBM representative about that . Sometimes IBM have
quicker response them the ISVs, because of the large experience .

One important point to consider is the cost of Oracle licenses for intel
plataform . The cost are much higher .

Best Regards,

Saulo Augusto Silva .



2011/3/18 CHAPLIN, JAMES (CTR) james.chap...@associates.dhs.gov

 We just had a surprise announcement by one of the Oracle DBAs during a
 zLinux  Application group planning meeting at our worksite. The DBA
 advised us that they (Database group) were going to move/migrate all the
 Oracle databases that we have on zLinux boxes off to an intel/unix
 platform. He did not offer details of the hardware, or when or how, just
 that they were going to do it. This is a bite of a surprise as we have
 just moved our MQ off the Mainframe (zOS) to the zLinux platform (guests
 on zVM) and that move is doing well. This may be due in part to the
 false mindset that we have in our upper management at our site that
 Mainframes are old technology. Also we have had slow response from
 Oracle on resolving issues we have identify (certifying Oracle 11 on
 z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x
 architecture). Has anyone else on this list had any related war
 stories similar to what we may be about to experience as this move
 takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


 --
 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 Oracle off zLinux boxes -- comments from the field?

[Shockley, Gerard C]

Especially with 11R2 due out any minute (day).

Gerard


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Barton 
Robinson
Sent: Friday, March 18, 2011 5:03 PM
To: LINUX-390@vm.marist.edu
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?

wow, your DBAs have the authority to spend that kind of money and make that 
kind of change without management signature? So no financial analysis, no 
technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a 
 zLinux  Application group planning meeting at our worksite. The DBA 
 advised us that they (Database group) were going to move/migrate all 
 the Oracle databases that we have on zLinux boxes off to an intel/unix 
 platform. He did not offer details of the hardware, or when or how, 
 just that they were going to do it. This is a bite of a surprise as we 
 have just moved our MQ off the Mainframe (zOS) to the zLinux platform 
 (guests on zVM) and that move is doing well. This may be due in part 
 to the false mindset that we have in our upper management at our site 
 that Mainframes are old technology. Also we have had slow response 
 from Oracle on resolving issues we have identify (certifying Oracle 11 
 on z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x 
 architecture). Has anyone else on this list had any related war 
 stories similar to what we may be about to experience as this move 
 takes place?



 James Chaplin

 Systems Programmer, MVS, zVM  zLinux


 --
 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 Oracle off zLinux boxes -- comments from the field?

[Simms, Michael]

We are about to put into production, once we have gotten our multipath 
(failover) issues resolved with EMC, Oracle 10. We had to step back to SLES 10 
SP3+ due to Oracles glacial speed with certification of Oracle 11 on zLinux. 
Also, the application only runs on Oracle 10, I imagine for the same reason.

On a brighter note: Our DB2 on zLinux, the latest DB2 for zLinux, is running in 
test, again we await a resolution of multipathing (failover) issues with our 
EMC SAN before we make it production. I share your pain. It took us a long time 
to convince our management that consolidating/introducing Linux images on the z 
was a good idea. So far we (well, I) aren't disappointed. The part that sorta 
called off the nay sayers or hushed them up was when we ran a nightly flow that 
runs on a pSeries (multiple CPUs, same DS4700 subsystem) on Linux/DB2 that ran 
5 times faster on our 1 IFL. Hmmm...hard to argue with that. :-)

Just my opinion but it sounds to me like someone lost a bet or a poker game 
where the loser had to give up their platform for Oracle. Just a WAG, but 
sounds about as reasonable. When management makes decisions like the one you 
describe, well it leaves me speechless! At least for a little while. I wish you 
a good outcome.

Michael Simms
Systems Programmer
zSeries  VM, VSE, (z)Linux, AIX
Naples Campus, Florida
239-552-3479

Enabling America's Best Local Healthcare

 Please consider the environment before printing this email and SAVE A TREE. 


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of CHAPLIN, 
JAMES (CTR)
Sent: Friday, March 18, 2011 2:22 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Moving Oracle off zLinux boxes -- comments from the field?


We just had a surprise announcement by one of the Oracle DBAs during a
zLinux  Application group planning meeting at our worksite. The DBA
advised us that they (Database group) were going to move/migrate all the
Oracle databases that we have on zLinux boxes off to an intel/unix
platform. He did not offer details of the hardware, or when or how, just
that they were going to do it. This is a bite of a surprise as we have
just moved our MQ off the Mainframe (zOS) to the zLinux platform (guests
on zVM) and that move is doing well. This may be due in part to the
false mindset that we have in our upper management at our site that
Mainframes are old technology. Also we have had slow response from
Oracle on resolving issues we have identify (certifying Oracle 11 on
z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x
architecture). Has anyone else on this list had any related war
stories similar to what we may be about to experience as this move
takes place?

 

James Chaplin

Systems Programmer, MVS, zVM  zLinux


--
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 Oracle off zLinux boxes -- comments from the field?

[Barton Robinson]

wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:

We just had a surprise announcement by one of the Oracle DBAs during a
zLinux  Application group planning meeting at our worksite. The DBA
advised us that they (Database group) were going to move/migrate all the
Oracle databases that we have on zLinux boxes off to an intel/unix
platform. He did not offer details of the hardware, or when or how, just
that they were going to do it. This is a bite of a surprise as we have
just moved our MQ off the Mainframe (zOS) to the zLinux platform (guests
on zVM) and that move is doing well. This may be due in part to the
false mindset that we have in our upper management at our site that
Mainframes are old technology. Also we have had slow response from
Oracle on resolving issues we have identify (certifying Oracle 11 on
z390x architecture, getting Oracle 10 support for RHEL 5.0 on z390x
architecture). Has anyone else on this list had any related war
stories similar to what we may be about to experience as this move
takes place?



James Chaplin

Systems Programmer, MVS, zVM  zLinux


--
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/
attachment: BARTON.vcf

Re: Moving Oracle off zLinux boxes -- comments from the field?

[Mike Riggs]

inline: graycol.gifinline: pic26058.gifinline: ecblank.gifattachment: BARTON.vcf

Re: Moving Oracle off zLinux boxes -- comments from the field?

[CHAPLIN, JAMES (CTR)]

It's government, what do you expect ;-)

James Chaplin

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
Barton Robinson
Sent: Friday, March 18, 2011 5:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?

wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a
. . . .

--
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 Oracle off zLinux boxes -- comments from the field?

[Carroll, William D]

Value for your dollars,   OMG, silly me, you said government  forget that.  
Doesn't happen

William 'Doug' Carroll

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of CHAPLIN, 
JAMES (CTR)
Sent: Friday, March 18, 2011 5:19 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?

It's government, what do you expect ;-)

James Chaplin

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
Barton Robinson
Sent: Friday, March 18, 2011 5:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving Oracle off zLinux boxes -- comments from the field?

wow, your DBAs have the authority to spend that kind of money and make
that kind of change without management signature? So no financial
analysis, no technical reason, sounds religious.

CHAPLIN, JAMES (CTR) wrote:
 We just had a surprise announcement by one of the Oracle DBAs during a
. . . .

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase  Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase 
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

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

[Bob Horne]

Mark,
Glad to hear that you find a good position. Best of luck to you.

Bob


Bob Horne
IBM Software Group - Tivoli
Atlanta, GA




From:
Mark Wheeler mwheele...@hotmail.com
To:
LINUX-390@vm.marist.edu
Date:
02/18/2010 10:30 AM
Subject:
Moving On
Sent by:
Linux on 390 Port LINUX-390@vm.marist.edu



Friends,

 

After 8 1/2 months of unplanned retirement, I am pleased to announce 
that I have started a new job at UnitedHealth Group, supporting z/VM and 
zLinux. Lots of good things happening here, and I'm working with a bunch 
of terrific people. 

 

Thanks for all your support over the last year. I've never been prouder to 
be part of the VM community.

 

Very best regards,

 

Mark Wheeler

UnitedHealth Group
  
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469226/direct/01/
--
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



image/gif

Re: Moving On: Cross-posted to linux and vm lists

[David Kreuter]

Phil best of luck in your new role and look forward to your posts
David Kreuter


 Original Message 
Subject: Moving On: Cross-posted to linux and vm lists
From: Phil Tully tull...@optonline.net
Date: Tue, December 29, 2009 8:12 pm
To: LINUX-390@VM.MARIST.EDU

To All,

As of January 1, 2010, I will no longer work for IBM.

The past 5 + years have been a rewarding experience for me, but I have
found an opportunity that I could not ignore. The new situation will be
better for me professionally, and personally.

I will continue to work with VM and Linux on Z and will continue to be a
member of both listservs.

With regards to all the customers I have interacted with , Thank You. I
hope you learned half as much as I did.

Phil Tully

--
'in media stat virtus'
Virtue's in the middle

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

Re: Moving a Samba directory

[Aria Bamdad]

When you cycle the samba server, all connection to the shares will be broken
but the clients reconnect when they see this happen.   At least for windows
clients, this should be transparent unless someone tries to access your
server in the exact time you are restarting it.

Before you restart your server, you can issue a SMBSTATUS command to see if
there are any open files or not.  You will see client connections to shares
but you want to watch out for open files.  If you recycle the server while
files are open, those application with open files will get upset.

You can minimize your samba outage to seconds by using the RSYNC command I
pointed out in an earlier post just before you shutdown your samba server
and immediately after you shutdown the server and before you start it again
in its new  home.  Depending on the size of your file system, this could be
just seconds.  I am not sure how much shorter you can make this outage.

Aria

 -Original Message-
 From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
 Tom Duerbusch
 Sent: Wednesday, September 09, 2009 4:39 PM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: Moving a Samba directory

 Like I said, I knew the answer to this one (i.e. shutdown Samba), but I
 hoping for a quick and dirty way, of doing the conversion with Samba
 still up.

 Well, once this is done, I can then add disks to the LVM on the fly.
 Just hate to have to do the scheduling of downtime (users and servers)
 when I know no one is going to be active anyway, just their shares are
 in use.

 Right?  When I cycle the server, the users have to reaccess their
 shares?  It's the servers that are accessing the Samba shares, then
 also have to be cycledand those users have to be notified...

 Thanks

 Tom Duerbusch
 THD Consulting

  Justin Payne jpa...@redhat.com 9/9/2009 2:41 PM 
 If you do not stop the samba service you run a risk of files being
 accessed during the move, and this could lead to corruption of the new
 files. As recommended before, you should be able to copy the bulk of
 the
 data without shutting down the service. With the bulk of the data
 mirrored on the new LVM, the second rsync will be quite quick at
 syncing
 only the changes so downtime will be minimal.

 It would be best to plan a brief outage of the samba service to
 complete
 the task you have outlined.

 Justin Payne

 On 09/09/2009 12:53 PM, Tom Duerbusch wrote:
  I think I know the answer to this one, but then, I don't know how
 much I don't knowG.
 
  I have a Samba server that runs 24X7.  It is rarely used at night,
 but still has Windows shares active.
  The /home directory is located off the / directory (dasda1).  It
 needs more space.
  I've created a LVM with a directory name of /home2.
  I plan on copying the /home directory to /home2, rename /home to
 /homeold, and rename /home2 to /home.
  Simple.
 
  What is Samba going to think about this?
  Do I need to cycle Samba, and have all the currently connected users,
 reconnect?
  Or as long as Samba isn't trying to access a file during this period
 of time, would it care?
 
  Part of this is trying to decide how much notification I have to give
 the end users, and there are a couple servers that also have Samba
 shares.  I don't know how to reconnect them, other than cycling those
 servers, which, then requires additional notification.
 
  On my test system, I moved the Samba /home directory to a LVM setup.
 No problem.  But I didn't have any currently accessed shares at that
 time (poor test plan).
 
  Thanks for any input and direction.
 
  Tom Duerbusch
  THD Consulting
 
  -
 -
  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 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 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 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

Re: Moving a Samba directory

[Tom Duerbusch]

Thanks Aria

SMBSTATUS is a good thing to know.
I'm not worried about syncing files using RSYNC as the only time this Samba 
server is updated is during 1st shiftwell, so far.

I will be doing the expansion during the 3td shift.

Tom Duerbusch
THD Consulting

 Aria Bamdad a...@bsc.gwu.edu 9/11/2009 8:12 AM 
When you cycle the samba server, all connection to the shares will be broken
but the clients reconnect when they see this happen.   At least for windows
clients, this should be transparent unless someone tries to access your
server in the exact time you are restarting it.

Before you restart your server, you can issue a SMBSTATUS command to see if
there are any open files or not.  You will see client connections to shares
but you want to watch out for open files.  If you recycle the server while
files are open, those application with open files will get upset.

You can minimize your samba outage to seconds by using the RSYNC command I
pointed out in an earlier post just before you shutdown your samba server
and immediately after you shutdown the server and before you start it again
in its new  home.  Depending on the size of your file system, this could be
just seconds.  I am not sure how much shorter you can make this outage.

Aria

 -Original Message-
 From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
 Tom Duerbusch
 Sent: Wednesday, September 09, 2009 4:39 PM
 To: LINUX-390@VM.MARIST.EDU 
 Subject: Re: Moving a Samba directory

 Like I said, I knew the answer to this one (i.e. shutdown Samba), but I
 hoping for a quick and dirty way, of doing the conversion with Samba
 still up.

 Well, once this is done, I can then add disks to the LVM on the fly.
 Just hate to have to do the scheduling of downtime (users and servers)
 when I know no one is going to be active anyway, just their shares are
 in use.

 Right?  When I cycle the server, the users have to reaccess their
 shares?  It's the servers that are accessing the Samba shares, then
 also have to be cycledand those users have to be notified...

 Thanks

 Tom Duerbusch
 THD Consulting

  Justin Payne jpa...@redhat.com 9/9/2009 2:41 PM 
 If you do not stop the samba service you run a risk of files being
 accessed during the move, and this could lead to corruption of the new
 files. As recommended before, you should be able to copy the bulk of
 the
 data without shutting down the service. With the bulk of the data
 mirrored on the new LVM, the second rsync will be quite quick at
 syncing
 only the changes so downtime will be minimal.

 It would be best to plan a brief outage of the samba service to
 complete
 the task you have outlined.

 Justin Payne

 On 09/09/2009 12:53 PM, Tom Duerbusch wrote:
  I think I know the answer to this one, but then, I don't know how
 much I don't knowG.
 
  I have a Samba server that runs 24X7.  It is rarely used at night,
 but still has Windows shares active.
  The /home directory is located off the / directory (dasda1).  It
 needs more space.
  I've created a LVM with a directory name of /home2.
  I plan on copying the /home directory to /home2, rename /home to
 /homeold, and rename /home2 to /home.
  Simple.
 
  What is Samba going to think about this?
  Do I need to cycle Samba, and have all the currently connected users,
 reconnect?
  Or as long as Samba isn't trying to access a file during this period
 of time, would it care?
 
  Part of this is trying to decide how much notification I have to give
 the end users, and there are a couple servers that also have Samba
 shares.  I don't know how to reconnect them, other than cycling those
 servers, which, then requires additional notification.
 
  On my test system, I moved the Samba /home directory to a LVM setup.
 No problem.  But I didn't have any currently accessed shares at that
 time (poor test plan).
 
  Thanks for any input and direction.
 
  Tom Duerbusch
  THD Consulting
 
  -
 -
  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 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 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 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

Re: Moving a Samba directory

[Tom Duerbusch]

Thanks Mark

I can slip this thru and cycle the Samba server, during a known time period 
where no one is actively accessing Samba files.  

Thanks

Tom Duerbusch
THD Consulting

 Mark Post mp...@novell.com 9/9/2009 6:14 PM 
 On 9/9/2009 at  4:38 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote: 
-snip-
 Right?  When I cycle the server, the users have to reaccess their shares?  


I doubt it.  The Windows clients won't know that Samba has been cycled, so they 
will just try to re-establish the connection the next time the user tries to 
use it.  It will likely be fairly transparent to 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 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

Re: Moving a Samba directory

[John Summerfield]

Mark Post wrote:

On 9/9/2009 at  4:38 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote:

-snip-

Right?  When I cycle the server, the users have to reaccess their shares?



I doubt it.  The Windows clients won't know that Samba has been cycled, so they 
will just try to re-establish the connection the next time the user tries to 
use it.  It will likely be fairly transparent to them.


My recollection from my OS/2 days is that this is transparent.

--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

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

Re: Moving a Samba directory

[Aria Bamdad]

Tom,

To be safe, you want to do this while Samba is not running.  When I upgrade
the disks on my Samba server, I use rsync to copy the contents of the
existing drive to the new drive using the -av and --delete options.  You can
do this during the day when the server is being used.  Then just before you
do the switch, shutdown Samba and any other application that may have files
open in the file system or directory you are moving.  Then run another rsync
-av --delete  which should bring the new disk in sync with the old and
should take a very short time.  Swap the disks and restart your server.

Aria

 -Original Message-
 From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
 Tom Duerbusch
 Sent: Wednesday, September 09, 2009 12:54 PM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Moving a Samba directory

 I think I know the answer to this one, but then, I don't know how much
 I don't know G.

 I have a Samba server that runs 24X7.  It is rarely used at night, but
 still has Windows shares active.
 The /home directory is located off the / directory (dasda1).  It needs
 more space.
 I've created a LVM with a directory name of /home2.
 I plan on copying the /home directory to /home2, rename /home to
 /homeold, and rename /home2 to /home.
 Simple.

 What is Samba going to think about this?
 Do I need to cycle Samba, and have all the currently connected users,
 reconnect?
 Or as long as Samba isn't trying to access a file during this period of
 time, would it care?

 Part of this is trying to decide how much notification I have to give
 the end users, and there are a couple servers that also have Samba
 shares.  I don't know how to reconnect them, other than cycling those
 servers, which, then requires additional notification.

 On my test system, I moved the Samba /home directory to a LVM setup.
 No problem.  But I didn't have any currently accessed shares at that
 time (poor test plan).

 Thanks for any input and direction.

 Tom Duerbusch
 THD Consulting

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

Re: Moving a Samba directory

[Justin Payne]

If you do not stop the samba service you run a risk of files being
accessed during the move, and this could lead to corruption of the new
files. As recommended before, you should be able to copy the bulk of the
data without shutting down the service. With the bulk of the data
mirrored on the new LVM, the second rsync will be quite quick at syncing
only the changes so downtime will be minimal.

It would be best to plan a brief outage of the samba service to complete
the task you have outlined.

Justin Payne

On 09/09/2009 12:53 PM, Tom Duerbusch wrote:

I think I know the answer to this one, but then, I don't know how much I don't 
knowG.

I have a Samba server that runs 24X7.  It is rarely used at night, but still 
has Windows shares active.
The /home directory is located off the / directory (dasda1).  It needs more 
space.
I've created a LVM with a directory name of /home2.
I plan on copying the /home directory to /home2, rename /home to /homeold, and 
rename /home2 to /home.
Simple.

What is Samba going to think about this?
Do I need to cycle Samba, and have all the currently connected users, reconnect?
Or as long as Samba isn't trying to access a file during this period of time, 
would it care?

Part of this is trying to decide how much notification I have to give the end users, and 
there are a couple servers that also have Samba shares.  I don't know how to 
reconnect them, other than cycling those servers, which, then requires additional 
notification.

On my test system, I moved the Samba /home directory to a LVM setup.  No 
problem.  But I didn't have any currently accessed shares at that time (poor 
test plan).

Thanks for any input and direction.

Tom Duerbusch
THD Consulting

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

Re: Moving a Samba directory

[Tom Duerbusch]

Like I said, I knew the answer to this one (i.e. shutdown Samba), but I hoping 
for a quick and dirty way, of doing the conversion with Samba still up.

Well, once this is done, I can then add disks to the LVM on the fly.
Just hate to have to do the scheduling of downtime (users and servers) when I 
know no one is going to be active anyway, just their shares are in use.

Right?  When I cycle the server, the users have to reaccess their shares?  It's 
the servers that are accessing the Samba shares, then also have to be 
cycledand those users have to be notified...

Thanks

Tom Duerbusch
THD Consulting

 Justin Payne jpa...@redhat.com 9/9/2009 2:41 PM 
If you do not stop the samba service you run a risk of files being
accessed during the move, and this could lead to corruption of the new
files. As recommended before, you should be able to copy the bulk of the
data without shutting down the service. With the bulk of the data
mirrored on the new LVM, the second rsync will be quite quick at syncing
only the changes so downtime will be minimal.

It would be best to plan a brief outage of the samba service to complete
the task you have outlined.

Justin Payne

On 09/09/2009 12:53 PM, Tom Duerbusch wrote:
 I think I know the answer to this one, but then, I don't know how much I 
 don't knowG.

 I have a Samba server that runs 24X7.  It is rarely used at night, but still 
 has Windows shares active.
 The /home directory is located off the / directory (dasda1).  It needs more 
 space.
 I've created a LVM with a directory name of /home2.
 I plan on copying the /home directory to /home2, rename /home to /homeold, 
 and rename /home2 to /home.
 Simple.

 What is Samba going to think about this?
 Do I need to cycle Samba, and have all the currently connected users, 
 reconnect?
 Or as long as Samba isn't trying to access a file during this period of time, 
 would it care?

 Part of this is trying to decide how much notification I have to give the end 
 users, and there are a couple servers that also have Samba shares.  I don't 
 know how to reconnect them, other than cycling those servers, which, then 
 requires additional notification.

 On my test system, I moved the Samba /home directory to a LVM setup.  No 
 problem.  But I didn't have any currently accessed shares at that time (poor 
 test plan).

 Thanks for any input and direction.

 Tom Duerbusch
 THD Consulting

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

Re: Moving a Samba directory

[Mark Post]

 On 9/9/2009 at  4:38 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote: 
-snip-
 Right?  When I cycle the server, the users have to reaccess their shares?  


I doubt it.  The Windows clients won't know that Samba has been cycled, so they 
will just try to re-establish the connection the next time the user tries to 
use it.  It will likely be fairly transparent to 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

Re: Moving native linux

[Paul Meier]

So can anyone help me on this? I am still stuck. When I copy the volumes and
then IPL from the new UCB It will only recognize the old volumes but I have
changed everything in zipl.conf and fstab.

One of my thoughts is that I need to change dasd_mod. During boot I get
these messages:

Starting udevd
Creating devices
Loading dasd_mod
Loading dasd_eckd_mod
*Activating DASDs: 0.0.e3ee:0*

This tells me there is something I still need to change, however I do not
know where to edit dasd_mod. I assumed it was in /etc/modprob.conf but it is
not. How can I change this to activate the new DASD at UCB 0.0.4058

I have read Mark Posts response to this. But I do not know how to update
your parmfile is this something different than zipl.conf and fstab?

http://linuxvm.org/info/HOWTOs/dumprest.html


On Mon, Jul 20, 2009 at 12:47 PM, Paul Meier pm.mli...@gmail.com wrote:

 Oh and we are not moving the LPAR but the DASD we are booting from.


 On Mon, Jul 20, 2009 at 12:34 PM, Paul Meier pm.mli...@gmail.com wrote:

 Thanks for the heads up. The addresses of the disks will be different and
 we do not have VM. Will changing the references to by-path allow me to
 change then the UCB addresses to the correct new ones? The disk will be
 completely mirrored over to a new one on a different box.



 On Mon, Jul 20, 2009 at 11:46 AM, David Boyes dbo...@sinenomine.netwrote:

   What would I need to change to make sure this works.

 First thing, download and run
 www.sinenomine.net/download/sane-dasd-update to change the by-id
 references you have in your /etc/fstab to by-path BEFORE you lose the old
 disks.  The way things are now, your system is irrevocably linked to the
 physical disk ids it's installed on, and it WILL NOT BOOT if you copy it to
 another disk.  If you can, get them to define the disks at the same
 addresses in the new LPAR. Then you can shut down the Linux system
 completely, and use ADRDSSU or DDR (if you have VM) to copy the disks over.

 FSTAB has entries but they seem to be only the last two digits of the 4
 character hex UCB. For example:

 /dev/disk/by-id/ccw-HTC.5500010957.4c14.ee-part1
 Where the UCB is E4EE.

 Second I know I can use vgexport for the lvm, but would that be all?

 Lastly how can I check if hyper-pav is enabled?

 Thanks!

 -Paul

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

Re: Moving native linux

[Mauro Souza]

Paul,

If you have access to a installation Linux, try this:
1 - start the installation as if you would reinstall from scratch
2 - somewhere in the installation, the installer will activate the dasds for
you. as soon as it happens, drop to a shell (connect another session, and
under sles or rhel you will have a shell awaiting you)
3 - mount your disks somewhere, /tmp/new for example... you will need to
chroot into there... (more info on chrooting, see
http://www.gentoo.org/proj/en/base/x86/chroot.xml. it's for gentoo but it's
the same thing)
4 - cd /tmp/new  chroot .
5 - now you are in you old system. edit your config files to ensure
everything is fine (/etc/fstab, /etc/modprobe.conf, etc)
6 - cd /boot and create a new initrd with mkinitrd
7 - run a zipl to recreate the boot record
8 - exit chroot, unmount the filesystem, reboot your system
9 - if your system still not boots, gave us some error messages... if boots,
you owe me one cent... ;)

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.


On Thu, Jul 30, 2009 at 11:25 AM, Paul Meier pm.mli...@gmail.com wrote:

 So can anyone help me on this? I am still stuck. When I copy the volumes
 and
 then IPL from the new UCB It will only recognize the old volumes but I have
 changed everything in zipl.conf and fstab.

 One of my thoughts is that I need to change dasd_mod. During boot I get
 these messages:

 Starting udevd
 Creating devices
 Loading dasd_mod
 Loading dasd_eckd_mod
 *Activating DASDs: 0.0.e3ee:0*

 This tells me there is something I still need to change, however I do not
 know where to edit dasd_mod. I assumed it was in /etc/modprob.conf but it
 is
 not. How can I change this to activate the new DASD at UCB 0.0.4058

 I have read Mark Posts response to this. But I do not know how to update
 your parmfile is this something different than zipl.conf and fstab?

 http://linuxvm.org/info/HOWTOs/dumprest.html


 On Mon, Jul 20, 2009 at 12:47 PM, Paul Meier pm.mli...@gmail.com wrote:

  Oh and we are not moving the LPAR but the DASD we are booting from.
 
 
  On Mon, Jul 20, 2009 at 12:34 PM, Paul Meier pm.mli...@gmail.com
 wrote:
 
  Thanks for the heads up. The addresses of the disks will be different
 and
  we do not have VM. Will changing the references to by-path allow me to
  change then the UCB addresses to the correct new ones? The disk will be
  completely mirrored over to a new one on a different box.
 
 
 
  On Mon, Jul 20, 2009 at 11:46 AM, David Boyes dbo...@sinenomine.net
 wrote:
 
What would I need to change to make sure this works.
 
  First thing, download and run
  www.sinenomine.net/download/sane-dasd-update to change the by-id
  references you have in your /etc/fstab to by-path BEFORE you lose the
 old
  disks.  The way things are now, your system is irrevocably linked to
 the
  physical disk ids it's installed on, and it WILL NOT BOOT if you copy
 it to
  another disk.  If you can, get them to define the disks at the same
  addresses in the new LPAR. Then you can shut down the Linux system
  completely, and use ADRDSSU or DDR (if you have VM) to copy the disks
 over.
 
  FSTAB has entries but they seem to be only the last two digits of the 4
  character hex UCB. For example:
 
  /dev/disk/by-id/ccw-HTC.5500010957.4c14.ee-part1
  Where the UCB is E4EE.
 
  Second I know I can use vgexport for the lvm, but would that be all?
 
  Lastly how can I check if hyper-pav is enabled?
 
  Thanks!
 
  -Paul
 
  --
  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 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 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 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

Re: Moving native linux

[Walters, Gene P]

Did you run zipl and mk_initrd?


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Paul Meier
Sent: Thursday, July 30, 2009 10:26 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Moving native linux

So can anyone help me on this? I am still stuck. When I copy the volumes
and
then IPL from the new UCB It will only recognize the old volumes but I
have
changed everything in zipl.conf and fstab.

One of my thoughts is that I need to change dasd_mod. During boot I get
these messages:

Starting udevd
Creating devices
Loading dasd_mod
Loading dasd_eckd_mod
*Activating DASDs: 0.0.e3ee:0*

This tells me there is something I still need to change, however I do
not
know where to edit dasd_mod. I assumed it was in /etc/modprob.conf but
it is
not. How can I change this to activate the new DASD at UCB 0.0.4058

I have read Mark Posts response to this. But I do not know how to
update
your parmfile is this something different than zipl.conf and fstab?

http://linuxvm.org/info/HOWTOs/dumprest.html


On Mon, Jul 20, 2009 at 12:47 PM, Paul Meier pm.mli...@gmail.com
wrote:

 Oh and we are not moving the LPAR but the DASD we are booting from.


 On Mon, Jul 20, 2009 at 12:34 PM, Paul Meier pm.mli...@gmail.com
wrote:

 Thanks for the heads up. The addresses of the disks will be different
and
 we do not have VM. Will changing the references to by-path allow me
to
 change then the UCB addresses to the correct new ones? The disk will
be
 completely mirrored over to a new one on a different box.



 On Mon, Jul 20, 2009 at 11:46 AM, David Boyes
dbo...@sinenomine.netwrote:

   What would I need to change to make sure this works.

 First thing, download and run
 www.sinenomine.net/download/sane-dasd-update to change the by-id
 references you have in your /etc/fstab to by-path BEFORE you lose
the old
 disks.  The way things are now, your system is irrevocably linked to
the
 physical disk ids it's installed on, and it WILL NOT BOOT if you
copy it to
 another disk.  If you can, get them to define the disks at the same
 addresses in the new LPAR. Then you can shut down the Linux system
 completely, and use ADRDSSU or DDR (if you have VM) to copy the
disks over.

 FSTAB has entries but they seem to be only the last two digits of
the 4
 character hex UCB. For example:

 /dev/disk/by-id/ccw-HTC.5500010957.4c14.ee-part1
 Where the UCB is E4EE.

 Second I know I can use vgexport for the lvm, but would that be all?

 Lastly how can I check if hyper-pav is enabled?

 Thanks!

 -Paul


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

Re: Moving native linux

[Mark Post]

 On 7/30/2009 at 10:25 AM, Paul Meier pm.mli...@gmail.com wrote: 
 So can anyone help me on this? I am still stuck. When I copy the volumes and
 then IPL from the new UCB It will only recognize the old volumes but I have
 changed everything in zipl.conf and fstab.
 
 One of my thoughts is that I need to change dasd_mod. During boot I get
 these messages:
 
 Starting udevd
 Creating devices
 Loading dasd_mod
 Loading dasd_eckd_mod
 *Activating DASDs: 0.0.e3ee:0*

What are your contents of /etc/zipl.conf?  Do the reflect the new DASD devices, 
or the old ones?  If the old ones, then you'll need to update them, re-run 
mkinitrd, re-run zipl, and reboot.


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

Re: Moving native linux

[Paul Meier]

Thanks,
I did not run mkinitrd. I did everything else but that. It works now!
Thanks!

On Thu, Jul 30, 2009 at 1:53 PM, Mark Post mp...@novell.com wrote:

  On 7/30/2009 at 10:25 AM, Paul Meier pm.mli...@gmail.com wrote:
  So can anyone help me on this? I am still stuck. When I copy the volumes
 and
  then IPL from the new UCB It will only recognize the old volumes but I
 have
  changed everything in zipl.conf and fstab.
 
  One of my thoughts is that I need to change dasd_mod. During boot I get
  these messages:
 
  Starting udevd
  Creating devices
  Loading dasd_mod
  Loading dasd_eckd_mod
  *Activating DASDs: 0.0.e3ee:0*

 What are your contents of /etc/zipl.conf?  Do the reflect the new DASD
 devices, or the old ones?  If the old ones, then you'll need to update them,
 re-run mkinitrd, re-run zipl, and reboot.


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

Re: Moving native linux

[David Boyes]

  What would I need to change to make sure this works.

First thing, download and run www.sinenomine.net/download/sane-dasd-update to 
change the by-id references you have in your /etc/fstab to by-path BEFORE you 
lose the old disks.  The way things are now, your system is irrevocably linked 
to the physical disk ids it's installed on, and it WILL NOT BOOT if you copy it 
to another disk.  If you can, get them to define the disks at the same 
addresses in the new LPAR. Then you can shut down the Linux system completely, 
and use ADRDSSU or DDR (if you have VM) to copy the disks over.

FSTAB has entries but they seem to be only the last two digits of the 4
character hex UCB. For example:

/dev/disk/by-id/ccw-HTC.5500010957.4c14.ee-part1
Where the UCB is E4EE.

Second I know I can use vgexport for the lvm, but would that be all?

Lastly how can I check if hyper-pav is enabled?

Thanks!

-Paul

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