Re: New LUNs on SLES 11 SP4

2016-01-23 Thread Offer Baruch
Did you try simply taking the fcp devices offline and then online again?
That should be enough... (although that shouldn`t be necessary in the first
place).

Offer Baruch
On Jan 23, 2016 5:48 PM, "Jorge Fábregas"  wrote:

> Hi,
>
> We have an issue with new deployed systems from our SLES 11 SP4 template
> (They all have "zfcp.allow_lun_scan=1" on their zipl.conf file).
> Whenever the z/VM admin deploys a new image, he would assign two FCP
> devices.  After that we take control of the system and:
>
> 1) verify FCP devices are present
> 2) enable them via "zfcp_host_configure 0.0.fxxx 1"
> 3) take note of their WWPN and request LUNs from our storage team
>
> The problem is that after they assign LUNs we'll do a
> "rescan-scsi-bus.sh" and nothings shows up.
> "lsluns" & "multipath -ll" doesn't show anything as well.  It is not
> until a reboot of the system that we start seeing these LUNs.
>
> The strange thing is that after that initial reboot, whenever the
> storage team assigns new extra LUNs, we'll see them right away with
> rescan-scsi-bus.sh.
>
> I know zfcp_host_configure places the necessary FCP activation rules on
> the udev directory but I thought it would load all necessary modules as
> well (so there was no need for a restart).
>
> Does anyone knows what are we missing?  How can we avoid that initial
> reboot after activating HBAs?
>
> Thanks,
> Jorge
>
> --
> 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: SSI guest best practice

2016-01-23 Thread Quay, Jonathan (IBM)
We have to use static MACIDs because our servers are behind load balancers that 
require it.  But SSI is very convenient and lets us work on hardware and zVM 
without taking application outages.  You do have to remember to do the SYSTEM 
CONFIG work to set up your EQIDs for your VSWITCHes.
--
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/


New LUNs on SLES 11 SP4

2016-01-23 Thread Jorge Fábregas
Hi,

We have an issue with new deployed systems from our SLES 11 SP4 template
(They all have "zfcp.allow_lun_scan=1" on their zipl.conf file).
Whenever the z/VM admin deploys a new image, he would assign two FCP
devices.  After that we take control of the system and:

1) verify FCP devices are present
2) enable them via "zfcp_host_configure 0.0.fxxx 1"
3) take note of their WWPN and request LUNs from our storage team

The problem is that after they assign LUNs we'll do a
"rescan-scsi-bus.sh" and nothings shows up.
"lsluns" & "multipath -ll" doesn't show anything as well.  It is not
until a reboot of the system that we start seeing these LUNs.

The strange thing is that after that initial reboot, whenever the
storage team assigns new extra LUNs, we'll see them right away with
rescan-scsi-bus.sh.

I know zfcp_host_configure places the necessary FCP activation rules on
the udev directory but I thought it would load all necessary modules as
well (so there was no need for a restart).

Does anyone knows what are we missing?  How can we avoid that initial
reboot after activating HBAs?

Thanks,
Jorge

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