First of all, /bin and /sbin have to be on the boot volume.  They need to be available 
during the boot process before other filesystems are mounted.

For /usr, let me refer you to

http://linuxvm.org/present/SHARE101/S9343GWa.pdf

yes, read-only systems have to be remounted if anything on them changes.  If this 
isn't acceptable, try mounting them "ro" through NFS rather than just linking to a 
disk and mounting it.  Much slower, but others use this all the time.  The 
disadvantage is that the NFS server has to be up all the time.

"The Definition of a gentleman is a man who can play the banjo -- and don't!"
-Mark Twain

Gordon Wolfe, Ph. D. (425)865-5940
VM Technical Services, The Boeing Company

> ----------
> From:         Cameron, Thomas
> Reply To:     Linux on 390 Port
> Sent:         Friday, February 27, 2004 10:04 AM
> To:   [EMAIL PROTECTED]
> Subject:      Shared DASD for guests?
> 
> Hi all -
> 
> Let me begin by saying I am still very new to z/VM.  I am a Linux guy, not a 
> mainframe fellow, so bear with me if I ask silly questions.
> 
> We are considering using one chunk of DASD space to install RHEL 3 and then having 
> multiple guests access /usr, /bin, /sbin and so on read-only.  That way we apply 
> updated RPMs to the "master" all the read-only guests will be updated as well.  The 
> sticking point is that it seems that the read-only guests have to re-access the DASD 
> before they see the updates that have been applied.
> 
> Am I understanding this correctly?  To me this sounds very problematical.  In 
> Linux/Intel, when a new RPM is installed, in most cases it simply involves 
> restarting the updated service for the new software to be used.  In z/Linux it seems 
> that a simple update of code will require each guest to re-IPL in order to access 
> the read-only DASD of the "master" image.
> 
> Can someone clarify this for me?
> 
> Thanks!
> --
> Thomas Cameron, RHCE, CNE, MCSE, MCT
> Assistant Vice President
> Linux Design and Engineering
> Bank of America
> (972) 997-9641
> 
> The opinions expressed in this message are mine alone and do not necessarily reflect 
> the opinions of my employer, Bank of America.
> 
> 

Reply via email to