Temporary disruption to channel paths - impact on z/Linux?

[Ranga Nathan]

We have a problem in our disk array. One of the ficon channel controller
cards is down. Our ops wants to swap it today. This will require downing
3 channel paths out of 6 that are shared to z/VM.

In the past, I have always shutdown all Linux instances and z/VM and
brought it back after the card swap.

If three out of the six are suddenly unavailable, would z/VM ignore them
and use the only three that are available? When all the six are
available when both cards are functioning, will z/VM auto-detect and use
the channels?

Would this all be transparent to the Linux guests?

Apparently this is not an issue on the z/OS side.

--
__________________
Ranga Nathan
Work: 714-442-7591

[Schuh, Richard]

You probably ought to vary the paths and chpids offline (VARY OFF PATH xx FROM ALL followed by VARY OFF CHPID nn) for the ones in question. When service is restored, vary them back on in the reverse order, CHPID then PATH.

It isn't as issue with VM, either. If the Linux guests are using minidisks (as opposed to dedicated or attached disks), the only thing that they might notice is an increase in I/O contention.

If Linux is using dedicated disks, then you will need to address its needs to. I cannot give you any insight into that.

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Ranga Nathan
Sent: Friday, February 17, 2006 1:47 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Temporary disruption to channel paths - impact on z/Linux?

We have a problem in our disk array. One of the ficon channel controller
cards is down. Our ops wants to swap it today. This will require downing
3 channel paths out of 6 that are shared to z/VM.

In the past, I have always shutdown all Linux instances and z/VM and
brought it back after the card swap.

If three out of the six are suddenly unavailable, would z/VM ignore them
and use the only three that are available? When all the six are
available when both cards are functioning, will z/VM auto-detect and use
the channels?

Would this all be transparent to the Linux guests?

Apparently this is not an issue on the z/OS side.

--
__________________
Ranga Nathan
Work: 714-442-7591

[Judson West]

X2

We have had card issues with our array also. We just vary
off the effected CHPIDs, replace the cards and vary them
back on.

-----------------
Judson West
Teradata, a division of NCR Corporation
-----Original Message-----
From: VM/ESA and z/VM Discussions
[mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Schuh,
Richard
Sent: Friday, February 17, 2006 1:58 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Re: Temporary disruption to channel paths - impact
on z/Linux?

You probably ought to vary the paths and chpids offline
(VARY OFF PATH xx FROM ALL followed by VARY OFF CHPID nn)
for the ones in question. When service is restored, vary
them back on in the reverse order, CHPID then PATH.

It isn't as issue with VM, either. If the Linux guests are
using minidisks (as opposed to dedicated or attached disks),
the only thing that they might notice is an increase in I/O
contention.

If Linux is using dedicated disks, then you will need to
address its needs to. I cannot give you any insight into
that.

Regards,
Richard Schuh

-----Original Message-----
From: VM/ESA and z/VM Discussions
[mailto:VMESA-***@LISTSERV.UARK.EDU] On Behalf Of Ranga
Nathan
Sent: Friday, February 17, 2006 1:47 PM
To: VMESA-***@LISTSERV.UARK.EDU
Subject: Temporary disruption to channel paths -
impact on z/Linux?

We have a problem in our disk array. One of the ficon
channel controller
cards is down. Our ops wants to swap it today. This will
require downing
3 channel paths out of 6 that are shared to z/VM.

In the past, I have always shutdown all Linux instances and
z/VM and
brought it back after the card swap.

If three out of the six are suddenly unavailable, would z/VM
ignore them
and use the only three that are available? When all the six
are
available when both cards are functioning, will z/VM
auto-detect and use
the channels?

Would this all be transparent to the Linux guests?

Apparently this is not an issue on the z/OS side.

--
__________________
Ranga Nathan
Work: 714-442-7591

[Ranga Nathan]

Alan Altmark wrote:
> On Friday, 02/17/2006 at 02:45 PST, Judson West
> <***@tervm3.sandiegoca.ncr.com> wrote:
>
>> We have had card issues with our array also. We just vary
>> off the effected CHPIDs, replace the cards and vary them
>> back on.
>>
>
> But Richard has the right of it: VARY OFF PATH xx FROM ALL, then VARY OFF
> CHPID xx. Never pull the chpid out from under CP without warning.
I played with this in our test lpar. z/VM 5.1 does not let you vary off
the chpid before varying off the path. Also, it is not possible to vary
off all the chpids. z/VM wants (understandably!) at least one path to
the volumes that are online. We performed the card swap successfully
after varying off the paths and the chpids and then varying them back on.
I want to thank all on this mailing list who have been very helpful.
Rock on z/VMers!
> It's
> like Uncle Charlie's parlor trick of pulling the tablecloth out from under
> the dishes: the odds of success are low and you risk breaking the dishes.
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>
>

--
__________________
Ranga Nathan
Work: 714-442-7591

[Richard Schuh]

Ranga Nathan wrote:

> Alan Altmark wrote:
>
>> On Friday, 02/17/2006 at 02:45 PST, Judson West
>> <***@tervm3.sandiegoca.ncr.com> wrote:
>>
>>
>>> We have had card issues with our array also. We just vary
>>> off the effected CHPIDs, replace the cards and vary them
>>> back on.
>>>
>>
>>
>> But Richard has the right of it: VARY OFF PATH xx FROM ALL, then VARY
>> OFF CHPID xx. Never pull the chpid out from under CP without warning.
>
> I played with this in our test lpar. z/VM 5.1 does not let you vary
> off the chpid before varying off the path. Also, it is not possible to
> vary off all the chpids. z/VM wants (understandably!) at least one
> path to the volumes that are online. We performed the card swap
> successfully after varying off the paths and the chpids and then
> varying them back on.
> I want to thank all on this mailing list who have been very helpful.
> Rock on z/VMers!
>
>> It's like Uncle Charlie's parlor trick of pulling the tablecloth out
>> from under the dishes: the odds of success are low and you risk
>> breaking the dishes.
>>
>> Alan Altmark
>> z/VM Development
>> IBM Endicott
>>
>>
>
>
I believe my initial post specified the correct order for the vary
commands. Anyway, glad we could help. We all like to avoid taking down
our systems unnecessarily.