On 10 Nov 2003, at 23:30, Gregory Newby wrote:
- I'd like them to share as much of the core OS as is reasonable: /,
/boot, /etc, /usr, /usr/local etc. This can be by NFS, or (better)
mounting ro. This is for convenience in administration.
- They must have one or more shared data directories (/globus and
/shared), again via NFS or ro. (r+w is not needed). This is
for getting applications running.
- They'll each have their own /data partition, r+w, which will be a
physically separate drive. /dev/sdk1, /dev/sdl1, /dev/sdm1, etc.
- I'm not sure how to handle /home. It would be nice for a user to
get his *same* home directory r+w on each system. NFS r+w?
So, things I need to do are:
1) Get a correct /usr etc. on hard drive, so I can boot virtual
domains that will run off of hard drive. (Currently, they're
running in RAMfs via CD.)
2) Give each virtual domain a different /etc/fstab or other
configuration so that they mount the right drives ro and rw and NFS.
To summarize, you want new domains to share /, /boot, /etc, /usr etc
but mount different partitions under /data for 'personal' use.
The main problem is: because new domains share /etc, they will read
the same /etc/fstab. How to have domain-specific /etc/fstab
automatically?
Fortunately, you can use ClusterNFS (http://clusternfs.sourceforge.net)
ClusterNFS is a patched version of "Universal NFS Daemon" (UNFSD)
server to allow multiple diskless clients to NFS mount the same root
filesystem
by providing "interpreted" file names.
When a client requests the file "/path/filename" , the ClusterNFS
server checks
for the existence of files of the form "/path/filename$$KEY=value$$".
If such a file exists and the clients has a matching value for KEY,
this file is returned.
If the client does not have the matching value or no such file exists,
the file request
proceeds as normal. Currently supported keys include, HOST (hostname),
IP (IP number), UID (user id), GID (group id), and CLIENT (matches any
NFS client).
ClusterNFS does not require any kenel changes. It runs only on the
server. Clients
run (any) standard NFS client.
As a result, you can download the latest release of ClusterNFS, compile
it
and use it to export a shared root partition. In this shared root
partition, you have
a series of /etc/fstab$$IP=137.229.71.N$$ files, each containing domain
specific
mount table entry such as mounting /dev/sdN1 on /data (N stands for
domain ID).
So when doman N (assigned IP address 137.229.71.N) accesses the root
partition
via ClusterNFS server and tries to read mount table from /etc/fstab, it
actally reads
/etc/fstab$$IP=137.229.71.N$$ and mount /dev/sdN1 on /data for personal
use.
It should work and I'll try it myself later today.
Bin
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home