> Seems like it should be the default
> I mean, except in very very specific cases,
> should the virtual machine EVER care about the hardware details?
Yeah ... David makes an excellent point.
Seems like a virtualization violation, in the pure sense.
Have always found it odd that guests can "se
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Bruce Hayden
> This is also why OPTION CHPIDVIRTUALIZATION ONE (and also the
> GLOBALOPTS
> statement) was invented, so that relocating guests don't see the real paths
> or care if the paths on th
It is strange. Rick types "lscss" and expects zLinux to give him the right
information. He gets
Device Subchan. DevType CU Type Use PIM PAM POM CHPIDs
--
0.0.01B0 0.0.000A 3390/0C 3990/E9 yes FF FF FF 444BA0B1 A1B06F4D
On Tue, 9 Jul 2013, Rick Barlow wrote:
> 2) Why doesn't Linux receive and handle pathing issues when they occur?
It does (after receiving a notification from the hardware/firmware or
hypervisor, or after beeing triggered by the admin). But it looks like it
didn't receive a notification that someth
This is also why OPTION CHPIDVIRTUALIZATION ONE (and also the GLOBALOPTS
statement) was invented, so that relocating guests don't see the real paths
or care if the paths on the LPAR they move to change. The notes in the CP
planning guide say "A single, virtualized CHPID is presented to the guest
f
Thank you Peter!
Apparently, use of chchp on any path causes Linux to validate all of the
CHPIDs.
Using lscss, I found that many guests still show status like this:
Device Subchan. DevType CU Type Use PIM PAM POM CHPIDs
--
0
This may not be of much help, but In our non mainframe environment
where we present NAS as SCSI, our filesystems drop into read only when they
experience time outs due to dasd controller performance and contention
issues, or underlying netiwork issues. You can see it in the kernel
message rin
On 09.07.2013 13:39, Rick Barlow wrote:
We have 8 FICON paths to the DASD subsystem shared through switches to 2
z196 machines each having 8 FICON paths to the switches. Of the 8 paths, 4
have been offline from all 8 LPARs for a couple of months while we waited
for IODF changes and physical cabl
As far as I know, zHPF is disabled. However, I do not know how to confirm
that.
We have 8 FICON paths to the DASD subsystem shared through switches to 2
z196 machines each having 8 FICON paths to the switches. Of the 8 paths, 4
have been offline from all 8 LPARs for a couple of months while we w
nal Message -
> From: Rick Barlow [mailto:rrhbar...@gmail.com]
> Sent: Monday, July 08, 2013 10:42 PM Central Standard Time
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] Where does Linux store path information for dasd
> devices?
>
> That is what I thought too. However,
Rick Barlow [mailto:rrhbar...@gmail.com]
> Sent: Monday, July 08, 2013 10:42 PM Central Standard Time
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] Where does Linux store path information for dasd
> devices?
>
> That is what I thought too. However, some guests are having
10:42 PM Central Standard Time
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Where does Linux store path information for dasd
devices?
That is what I thought too. However, some guests are having issues. Some
parts of lvm groups switched to r/o. Some page errors. It is not
consistent
<><><><><>
Perhaps the UUID' s of the DASD got changed or mangled at the CP level?
David Kreuter
Original message
From: Rick Barlow
Date:
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Where does Linux store path information for dasd devices?
That is what I thought too. However,
That is what I thought too. However, some guests are having issues. Some
parts of lvm groups switched to r/o. Some page errors. It is not
consistent. I'm confused!
Rick Barlow
Nationwide
On Mon, Jul 8, 2013 at 11:34 PM, Scott Rohling wrote:
> I would think this would be transparent to a gu
I would think this would be transparent to a guest it's path will be
the minidisk .. which won't change - unless I misunderstand what you mean
by switches. Are you presenting the DASD as minidisks, or attaching them?
Either way I don't see the pathing changing at the Linux level.
Scott Rohl
I have many Linux guests running on z/VM. We are in the process of
migrating ECKD DASD from old switches to new switches. I am trying to find
out how Linux stores the paths information, how to display what Linux
thinks and whether there is a way to tell Linux to re-validate its path
information.
17 matches
Mail list logo