We used EDEVICE's for 15 years, tired of that. :-) Seriously the large
EDEVICEs with many zLinux OS disks per device was a bottleneck. We
never moved '/var' off so log backups (often for a bunch of systems at
once) and Linux backups were both having really high wait times on
EDEVs, with 1 I/O at a time per EDEVICE I guess no surprise. On top of
that we have really bad SAN performance during backup windows for a VERY
long time (6-8 months).
Maybe our EDEV's were too large and with too many servers per each, and
certainly the servers could have been placed on them more randomly, but
when the Linux SA's decided to up the OS disk allocation from 20G for
SLES11 to 60G for SLES12 the thinking was we would need even larger
EDEV's causing even more contention.
Now we're learning that NPIV would be an important thing to have for a
pure LUN based implementation, but alas, hard to implement down the road
like this. If this proves to be too difficult we might go back to EDEV,
we're just starting with this project.
I don't know what all went in to the decision to not do NPIV, but the
limitation on login's may have been a factor. But we certainly have
seen cases where someone has picked up the wrong LUN, and fortunately
DIDN'T USE IT, but still, the other server couldn't come up because it's
LUN was stolen.
Anyway, I'm the VM guy, and there are a lot of good tips here, but I'll
need to see what our Linux guys want to do. Maybe the SLES12-SP3 clone
fixer thing would do, sounds like it would.
Alan, so don't share the PCHPID b/c say 1803 could be attached to two
servers at once? Problem is that we have a spare ficon to the SAN with
very little on it and we maybe could change it to NPIV and migrate
gradually, but with two production LPARS we would have to share that new
NPIV'd channel at least until we can free the other one to change to NPIV.
Another thing we haven't really figured out is COOP, similar situation
there, we'll have a LUN that is a copy, but how do we get the Linux
guest to happily use it. That was easier with EDEV b/c we could get the
system up and fix the multipath config and whatever else they were doing
to get SLES11 to work.
On 9/9/2017 3:37 PM, Scott Rohling wrote:
EDEVICEs are z/VM's way to provide that virtualization and hide the ugly
details.... but in this case z/VM is simply supplying a path (FCP
subchannel) and it's up to guest OS to do what it needs to do to connect to
the storage using that path.
So to me the question would be - why aren't EDEVICEs being used?
Scott Rohling
On Fri, Sep 8, 2017 at 1:45 PM, Willemina Konynenberg <w...@konynenberg.org>
wrote:
To me, all this seems to suggest some weakness in the virtualisation
infrastructure, which seems odd for something as mature as z/VM.
So then the follow up question would be: is the host infrastructure
being used properly here? Is there not some other (managable) way to
set things up such that all the ugly technical details of the underlying
host/san infrastructure is completely hidden from the (clone) guests,
and that the guests cannot accidentally end up accessing resources they
shouldn't be allowed to access? This should be the responsibility of
the host system, not of each and every single guest.
To me, that seems a fairly basic requirement for any sensible virtual
machine host infrastructure, so I would think that would already be
possible in z/VM somehow.
Willemina
On 09/08/17 22:28, Robert J Brenneman wrote:
Ancient history: http://www.redbooks.ibm.com/redpapers/pdfs/redp3871.pdf
Without NPIV you're in that same boat.
Even if you had NPIV you would still have to mount the new clone and fix
the ramdisk so that it points to the new target device instead of the
golden image.
This is especially an issue for DS8000 type storage units that give every
LUN a unique LUN number based on which internal LCU its on and the order
it
gets created. Storwize devices like SVC and V7000 do it differently: each
LUN is numbered starting from 0000 and counts up from there for each host,
so the boot LUN is always LUN 0x0000000000000000 for every clone and you
don't have to worry about that part so much.
The gist of your issue is that you need to:
mount the new clone volume on a running Linux instance
chroot into it so that your commands are 'inside' that cloned linux
environment
fix the udev rules to point to the correct lun number
fix the grub kernel parameter to point to the correct lun if needed
fix the /etc/fstab records to point to the new lun if needed
?? re-generate the initrd so that it does not contain references to the
master image ??
( I'm not sure whether that last one is required on SLES 12 )
On Fri, Sep 8, 2017 at 3:30 PM, Alan Altmark <alan_altm...@us.ibm.com>
wrote:
On Friday, 09/08/2017 at 04:46 GMT, Scott Rohling
<scott.rohl...@gmail.com> wrote:
Completely agree with you .. I might make an exception if the only
FCP
use is for z/VM to supply EDEVICEs
AND the PCHID is configured in the IOCDS as non-shared.
Alan Altmark
Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
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/
--
Jay Brenneman
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://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/
