Reaching back into long ago memory about diskless workstations, a diskless client mounts it's root and other file systems from a master. In the simplest case (homogeneous machines, same versions and configurations) you could share all the non-writable parts of the image in place, but since all the client really knows is an initial boot image location (retrieved using tftp or the like) and config files, that remote location can be anywhere in the masters disk pool.
So the basic trick for heterogeneous machines is to setup different kernel images/configs and a separate virtual disk image for the client machines with different needs, and configure the boot server daemon (tftpd, ...) to provide the required image for each machine that contacts it.
In a simplified example lets say that you have 3 machines with 3 different architectures, A is the master disk server, B is the first client, and C is the second client. On A's disk there are 4 partitions, home shared by all the machines, A's own root, and roots for machines B and C.
Code: +----------+
| / for A |
+----------+
| / for B |
+----------+
| / for C |
+----------+
| /home |
+----------+
A would provide the appropriate kernel and configs to B and C when they started up and contact it's boot server process. B and C would download and run those images and remote mount the appropriate file systems. A real system would generally have a more complicated layout but this should give you the basic idea. There were also all sorts of clever tricks to reduce the amount of redundancy but that's less necessary than it used to be given KM's small installed size relative to modern disks.
|
Any tips much appreciated....