| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Multiple Domains Sharing Root System
Hi,
I've been having a play with this idea too:
My plan is to have an NFS root server as a domain, using multiple LVM
partitions. (I could run it in dom0 if required).
Using a UnionFS-patched kernel I hope to combine a (writable) domain-
specific partition with a (read-only) generic image for each domain.
This would allow each domain to have custom configs and apps.
>From the NFS Root Server's point of view the filesystems might be
something like this:
................ ............... ...............
' domU1 Union ' ' domU2 Union ' ' domU3 Union '
' 640MB ' ' 640MB ' ' 640MB '
'''''''''''''''' ''''''''''''''' '''''''''''''''
/|\ /|\ /|\
________|_______ _______|_______ _______|_______
| domU1fs | | domU2fs | | domU3fs |
| (128MB rw) | | (128MB rw) | | (128MB rw) |
|______________| |_____________| |_____________|
|_______________|_______________|
/|\
________|________
| domUgenfs |
| (512MB ro) |
|_______________|
So in this example, total virtual filesystem usage is 1920MB with only
896MB actually used.
I've actually been trying to do this with uclibc (without success so far)
to minimise the size of the NFS root server itself, but might give up
and just use a minimal Debian sarge. Any suggestions?
Sound like an idea?
Marcus.
Mark Williamson wrote:
>>* ...NFS exporting a read-only copy of /usr. This is usually your largest
>>partition where most updates occur. Well-written programs will not require
>>/usr be mounted read-write and you should be able to export at least that
>>partition. You can do updates very quickly. This is the direction I want
>>to go.
>>
>
> You could also read-only share a block device for /usr between all domains.
> This gives good performance and you still only have one image of the
> filesystem. The trouble is that with block-level sharing you can't update
> the filesystem whilst there are more than one domains accessing it :-(
>
> I used to do this, now I just have multiple complete installs.
>
> There are a number of people here working on other solutions for filesystem
> sharing that may be better in some circumstances.
>
> Cheers,
> Mark
>
>
>
>>You could even use thin-client network boot technology so that your domains
>>don't use *any* hard drive space.
>>
>>You can test your app by installing a new installation of linux or unix and
>>giving /usr its own partition. Install the program you want to test. Edit
>>/etc/fstab and give the /usr partition the ro flag something like this:
>>LABEL=/usr /usr ext3 defaults,ro 1 2
>>Remount /usr:
>>mount -o remount /usr
>>
>>Or do it without editing fstab (does not persist over reboots):
>>mount -o ro,remount /usr
>>
>>Then run your app and see if it bombs. If it works, you can use a
>>read-only NFS-mounted /usr partition.
>>
>>Note: This only shares /usr. If you install an update that modifies a file
>>under /etc /var or /boot you will need to manually copy those updates. It
>>is not wise to share /etc or /var (they are usually thought of as the place
>>where system-specific and variable data lives) and /boot /sbin and /lib is
>>usually needed before NFS filesystems can be mounted (usually). So any
>>updates to these partitions must be done manually.
>>
>>I suppose the main server could run an update and then the NFS clients
>>could run the same update, ignoring any /usr "read-only" errors. Seems
>>like it would work, but then that takes the same amount of time as updating
>>individual servers.
>>
>>
>>Or you could just...
>>
>>* ...bite the bullet and do it the old-fashioned way. A well-tuned OS
>>doesn't take up much room compared to swap and data. Most of my installs
>>are a few hundred MB (I kill the documentation and only install what I
>>need). The average Xen system probably has a dozen domains, so that's
>>around 10GB. That's nothing with today's drives.
>>
>>Doesn't give you quick-update ability but you can use something like yum or
>>apt. I've installed both yum and apt servers; they're no big deal.
>>
>>Hope that helps!
>>
>>CD
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home