Hi Tim, What you want to do is feasible, but require good planning.
For an example, you can share RO the /usr filesystem. When you apply a patch on the main system which owns the disk in RW, your other machines ARE NOT aware of the changes until you re-mount the filesystem on each Linux machine. You will need to carefully watch changes with some program like Tripwire to know specifically which file were changed outside of the shared filesystem (config file, doc, etc). Most of the times, it will be non-critical files. Some patches are trickier to apply that way, for example the kernel patches. Only some files in /usr/src are applied in the /usr filesystem when you update the kernel, so you will need to patch every machine. Anyway, you need to mkinitrd and zipl after installing a new kernel, which is automatically done by the rpm scripts. So, Tripwire and rpm -ql "package-name" are your friends to achieve this. I hope this helps a little. Regards. On 7/27/06, MOEUR TIM C <[EMAIL PROTECTED]> wrote:
Hello List, I'm pursuing an architecture for multiple guests under VM and I'd like to know if anyone else has done the same, or if this is just an accident waiting to happen. I invite your thoughts, comments, and witty remarks. Here's what I'm considering: I'd like to create multiple VM Linux guests that each have read access to a set of common minidisks. On those common minidisks will be what I'm calling the shared Linux file systems, such as stuff in /sbin, /bin, /boot, /lib. Each VM Linux guest will also have an exclusive minidisk (WRITE) that will contain the file systems needed to update and operate (/etc, /proc, /sys, /tmp and so on). The assumption is that each Linux guest will use the same level of OS, patches, and add-on programs. I have two goals with this idea - 1) to limit maintenance procedures. I'd only have to apply patches to one image and all of the Linux guests would be affected. 2) conserve DASD. I can think of several good reasons not to do this: 1) Each Linux guest will probably need to run with the largest allocation of memory. 2) I'd likely have to shut down ALL guests in order to apply maintenance, since updating executables on the fly (from some other maintenance system) would probably invite abnormal results. I haven't experimented or detailed the specifics of what directories are shared and which are exclusive, but I wanted to first pose the question to this group to see if this is a good way to invite a system crash across all of my production Linux servers. Tim ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
