Steve,
Just a suggestion, check the storage itself to make sure that the
volumes are not set to r/o.
I've been plagued with read-only situations due to a myriad of
reasons but the 'write protected' reminds me of the one situation where
the storage itself were set to read-only as they were DR volumes.
Thanx,
Joe Comitini
TD Ameritrade - Senior SystemZ Engineer
Office: (201) 369 - 8436
Cell: (551) 200 - 7781
________________________________
From: The IBM z/VM Operating System [mailto:[email protected]] On
Behalf Of Perez, Steve S
Sent: Tuesday, March 01, 2011 6:00 PM
To: [email protected]
Subject: Re: zLinux OS disk read-only
When my zLinux Admin issued this command in the zLinux guest machine, he
got the "write-protected" message indicating to him that the OS disk is
read-only...
# mount -o remount,rw /dev/VolGroup01/LogVol00
mount: block device /dev/VolGroup01/LogVol00 is write-protected,
mounting read-only
He said it wasn't like that yesterday. The likelihood of a finger check
is very minimal since the way we have these guest machines start up,
which is directly IPL it's OS disk (addr 200). My zLinux Admin tells me
that it was fine Monday before the D/R test started this morning. He
himself I guess could have finger checked, but he knows very little
about how VM works let alone issue the command to link the OS disk
device R/O.
Thank you for the suggestion on IPLing the guest into CMS first. I will
look into it again at some point when more time allows. But in the
meantime, this bizarre occurrence has puzzled us. I have since set the
console to start at IPL/startup of the guest machine to get some console
activity log to see what he's doing at startup.
Thanks for you assistance.
Kind Regards,
Steve.
________________________________
From: The IBM z/VM Operating System [mailto:[email protected]] On
Behalf Of RPN01
Sent: Tuesday, March 01, 2011 4:29 PM
To: [email protected]
Subject: Re: zLinux OS disk read-only
You said you ended up with the disk in read-only mode, but M would imply
that if you couldn't get it in read-write mode, you wouldn't get it at
all. This would lead me to believe that there might have been fingers at
work on the console after the log-in and before the boot that might have
subsequently linked the disk, possibly with a "LINK * 200 200 MR",
maybe? Again, the console log would lead to the footprint of the perp
that would tell all.
Another fine way to handle the situation and allow some control would be
to IPL the guest into CMS before starting the Linux guest. Set up the
machine using the CMS profile and do your sanity checks there, then IPL
the Linux boot disk when you know things will go well. Given our two CEC
environment, and our history before going into CSE, we use this method
to check that the image was last run on the current LPAR before IPLing
the Linux image, to be sure that it can't be running in the other CEC.
We had the same image booted on both systems at the same time once too
often, destroying the image (i.e... Once) We use a read-only CMS 191
with a profile to perform this vital sanity check (for us) before
allowing the Linux image to start. (In fact, all our linux images share
the same 191 minidisk.) Checking the Linux disks to be sure they are RW
certainly wouldn't hurt as well. It would be a simple task, especially
if you stuck to a standard addressing scheme for all your images.
Just an idea to think about.
--
Robert P. Nix Mayo Foundation .~.
RO-OC-1-18 200 First Street SW /V\
507-284-0844 Rochester, MN 55905 /( )\
----- ^^-^^
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
On 3/1/11 3:40 PM, "Perez, Steve S" <[email protected]> wrote:
I issued a LINK RR against it and did a Q LINKS and it shows no
other link access to that disk. Would it be possible that when we
paused PPRC and suspended Global Mirror on the z/OS LPAR (shared volumes
between all LPARS) that it may have accessed the dasd the minidisk is on
in write mode and caused the access mode on the z/VM LPAR to go into a
READ-MODE? Is that probable?
Steve.
________________________________
From: The IBM z/VM Operating System
[mailto:[email protected]] On Behalf Of Mark Pace
Sent: Tuesday, March 01, 2011 2:57 PM
To: [email protected]
Subject: Re: zLinux OS disk read-only
M Multiple-write access. Write access is established unless
another user holds
a write, a stable (SR, SW, SM) or an exclusive (ER, EW) mode
access to
the disk.
Looks like some other VM has that disk linked in write mode.
On Tue, Mar 1, 2011 at 3:53 PM, Perez, Steve S
<[email protected]> wrote:
The disk is defined as follows. This is an excerpt from
the CP directory:
IPL 200
.....
LINK RHMASTER 199 199 RR
MDISK 200 3390 1 10016 LX53B5 M
Unfortunately, the console log did not get spooled so I
don't know what the log would have indicated for that disk when the
guest machine came up. That's on my follow-up list. The guest machine
is IPL'd off of its OS (disk 200) disk when it comes up (in its CP
Directory) so I need to find a way to spool the console when it starts
and not later after it has gone through its initialization.
Thanks,
Steve
-----Original Message-----
From: The IBM z/VM Operating System
[mailto:[email protected]] On Behalf Of RPN01
Sent: Tuesday, March 01, 2011 2:33 PM
To: [email protected]
Subject: Re: zLinux OS disk read-only
How is the disk defined in the CP Directory entry (i.e.
What is the mode of the disk), and what is in the console log when the
user was logged in that could give a clue about the status of the disk
when the user was initialized?
The mode will tell you the condition(s) that could lead
to it being read only (other users having it read/write or even read
only), and the log may even tell you which or how many users gummed up
the works, or when things when oval on you.
In any case, it had to have happened at some point, and
there has to be a footprint, if you keep your logs.
--
Robert P. Nix Mayo Foundation .~.
RO-OC-1-18 200 First Street SW /V\
507-284-0844 Rochester, MN 55905 /( )\
----- ^^-^^
"In theory, theory and practice are the same, but in
practice, theory and practice are different."
On 3/1/11 2:23 PM, "Steve Perez"
<[email protected]> wrote:
> Hello All,
>
> Has anyone run into a situation where the zLinux OS
disk has become
> READ-
>
> ONLY access? We are running z/Linux under z/VM 5.4
Redhat 5.4.
>
> My zLinux Admin were doing compares between the
production environment
>
> versus the Test D/R environment and noticed it. He
issued the
> following
>
> on the prod zLinux guest environment:
>
> # mount -o remount,rw /dev/VolGroup01/LogVol00
> mount: block device /dev/VolGroup01/LogVol00 is
write-protected,
> mounting
>
> read-only
>
> Since we are testing our D/R process at the moment
for the z/VM LPAR
> we
>
> are unsure at this point whether that is a
contributing factor. It
> shoul d not be but we can't rule it out. We paused
our PPRC/Global
> mirroring fro m the z/OS side before starting the D/R
activities to
> perform recovery of
>
> the z/VM & z/Linux. The problem was found while in
the middle of
> verifying/comparing environments on the zLinux side.
I can link to
> the
>
> minidisk that is used to IPL that zLinux guest and it
shows R/W when I
>
> issue Q LINKS. All other minidisks owned by that
zLinux guest are R/W a
> s
> well. From my perspective (z/VM) all looks good.
>
> Any input would be appreciated, if anything to rule
out that PPRC/GM
> woul d have contributed to this.
>
> Thanks.
> Steve.
************************************************************************
******************
This message may contain confidential or proprietary
information intended only for the use of the
addressee(s) named above or may contain information that
is legally privileged. If you are
not the intended addressee, or the person responsible
for delivering it to the intended addressee,
you are hereby notified that reading, disseminating,
distributing or copying this message is strictly
prohibited. If you have received this message by
mistake, please immediately notify us by
replying to the message and delete the original message
and any copies immediately thereafter.
Thank you.
************************************************************************
******************
CLLD
