Robert,
You don't have to use the VMSYS filepool. You can create a new filepool
that doesn't start with "VMSYS" and share it between systems. The only
drawback is that if the system that hosts the filepool server isn't up,
the filepool isn't accessible to the other system.
We have filepool servers on every system. They have unique names that
don't start with "VMSYS". If we had production Linux on multiple
systems, we'd use SFS A-disks in a filepool that's on the same system as
the Linux guests. Because the pools are sharable, if we had to make a
change to PROFILE EXEC, we could do that for all systems from one place.
For our z/OS guests, we have one PROFILE EXEC on each system that has an
alias for each guest. If I were setting up Linux guests, I'd do them
the same way.
Dennis
We are Borg of America. You will be assimilated. Resistance is futile.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of RPN01
Sent: Tuesday, October 28, 2008 12:28
To: [email protected]
Subject: Re: [IBMVM] Linux guest 191/200 disk question
One problem w/ SFS is that we don't run it on our second LPAR at all.
Anything that we want to be able to run on both systems has to reside on
a
minidisk. SFS isn't a choice.
If IBM would allow the vmsys: pool to be shared between systems, we'd be
more likely to use it.
--
Robert P. Nix Mayo Foundation .~.
RO-OE-5-55 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 10/28/08 2:13 PM, "Tom Duerbusch" <[EMAIL PROTECTED]> wrote:
> True about another point of failure.
>
> However, how many times a year is your SFS server(s) down?
> I find an occasional crash (usually due to me) about once every year
or two.
> It's really a pain, as my CMS type servers, don't auto reconnect. So
I have
> to manually force off the servers and let the be brought up by
AUDITOR.
> (easiest way to do this)
>
> But, for a guest, such as Linux, when you (x)autolog them, they
connect to
> SFS, access the PROFILE EXEC and disconnect (via IPL) in a matter of a
second
> or two.
>
> However, your point, is good, especially in a near 24X7 Linux shop. A
shared
> 191 minidisk is better. Until you have two users, access the shared
disk in
> R/W mode, to update it. No protection. SFS will always protect you.
Manual
> procedures can minimized the R/W problem, but can't eliminate it.
Just like
> SFS problems can be minimized but not eliminated.
>
> But thinking of this...
> There is one SFS combination of problems, which would be a major
concern.
> Backing up SFS via the VM supplied utilities and the backup (or VM)
crashes.
> SFS will come up, but that storage pool is locked. It is easy to
unlock it,
> when you know to do that.
> During this time, if a guest tries to access their SFS directory that
is on a
> SFS pool that is locked (would be a much more frequent occurrence if
there was
> a VM crash), it could lead to a lot of heart burn.
>
> A 191 minidisk can be much better. And of course, not to IPL CMS, but
to IPL
> 190, just in case the CMS saved segment is lost <G>.
>
> Tom Duerbusch
> THD Consulting
>
>>>> Scott Rohling <[EMAIL PROTECTED]> 10/28/2008 1:56 PM >>>
> Just curious why you think SFS is better than a 1 cylinder shared
minidisk?
> To me - it's a point of failure as an SFS pool server must be running
just
> to get to the PROFILE EXEC...
>
> Scott Rohling
>
> On Tue, Oct 28, 2008 at 11:32 AM, Tom Duerbusch
> <[EMAIL PROTECTED]>wrote:
>
>> 1. As has been said, you don't need a R/W disk to IPL. R/O is good.
SFS
>> directory is even better.
>> 2. Once you IPL Linux, you are not in CMS anymore. You won't be
doing
>> anything with your a-disk anymore. So make it easy on your self,
when you
>> need to make changes to the profile exec. Put it in a SFS directory.
>>
>> Tom Duerbusch
>> THD Consulting
>>
>>
>>
