Re: Gold On LUN
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 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 and counts up from there for each host, so the boot LUN is always LUN 0x 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 wrote: On Friday, 09/08/2017 at 04:46 GMT, Scott Rohling 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 Managin
Re: Gold On LUN
Did I stutter? I said "I'm leaving out details" which left the door open
for someone to throw a n..n..ay, nay, nay.
It's the equivalent of a 190/490 flip. (My age is showing, and don't you
say a word about my metalic blonde hair.)
+ You don't upgrade the linked copy. Ever.
+ You upgrade the maintenance copy. Always.
+ With a shared OS, you then *point* instead of c..c..copy, copy, copy.
I've given up fighting the myriad maintenance models for Linux. (You
thought there was only One True Maint Model?)
Follow the steps Jay outlined (roughly) and apply maintenance to the
master copy. Call it Gold.
Within the 'chroot', run the _stock maint_ ('zypper up' in this case).
How does this "not fit the maintenance model for Linux"?
You want to be able to shutdown a single target guest, point it at the
updated OS disk and reboot.
I'm still leaving out details. Lord of the Protocols should return
another sparring move so we can continue the handshake.
Greg --
Keep it simple.
I find that shared OS saves me time and effort and defends my sanity.
But it's not something you'll get guidance for from your distributor.
You'll have to own the process and do some figgering out. You certainly
won't get help with shared OS from your storage vendor. (They seem to be
keen on boosting their flash capable systems business and can't think
outside that box.)
You got bitten by embedded WWPNs in the INITRD, which I also hate.
-- R; <><
On 09/09/2017 08:52 PM, Alan Altmark wrote:
> No, don't. You can't upgrade the linked copy without umounting it from all
> the servers using it. While cool and highly efficient, it just doesn't fit
> the maintenance model for Linux.
>
> You want to be able to shutdown a single target guest, flashcopy the golden
> master to the target disk and reboot.
> Alan
>
> Sent from my iPhone using IBM Verse
>
> On Sep 9, 2017, 6:14:02 PM, r...@casita.net wrote:
>
> From: r...@casita.net
> To: LINUX-390@VM.MARIST.EDU
> Cc:
> Date: Sep 9, 2017, 6:14:02 PM
> Subject: Re: [LINUX-390] Gold On LUN
>
>
>Don't clone! Just link!
> I do, and have done, a fair bit of cloning. But I don't recommend it for
> production systems. (dev, test, recovery, sure)
> Instead, _share the OS disk or LUN_. Give each "client" (for lack of a
> better term) its own root.
> Less to backup, less to push with Puppet, more consistent flock o
> penguins, more reliable results.
> Good tips from several people, including this from Jay.
> On 09/08/2017 04:28 PM, Robert J Brenneman wrote:
> > 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.
> INITRD gets too much info stamped into it.
> But if the OS is configured to share then you can boot any number of
> times from the same LUN, no problem!
> > ...
> >
> > 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 ??
> Re-gen the INITRD so it points to the shared boot disk. But find,
> activate, and mount the "real root", whether minidisk, EDEV, or LUN.
> I'm leaving out details, but it's not rocket surgery. Bind or sym-link
> /bin, /lib, and others, swing the OS to a sub-dir, and run.
> -- R; <><
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M&m=-pp4eUuJSsuOhrDEP5ZEgbahpLsO1xiq95OzcroSNzE&s=HLErO0gdQJ-npqjE80wp7vaGmoU11ncrDxyEbpe2-50&e=
> --
> For more information on Linux on System z, visit
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M&m=-pp4eUuJSsuOhrDEP5ZEgbahpLsO1xiq95OzcroSNzE&s=JfVfMkaUZrgq09nxfn7wORqQaDY9ceGis4OZmuzmid4&e=
>
> --
> 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
