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/
