WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Setting up a more complex system scenario

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