to clarify, I don't want to mount a root-zone exported filesystem, but, from
within the zone, I want to simply leverage the root-zone's automount tree to
provide access to each non-global zone to our (seperate) NFS fileservers.
I think the technical discussion above gets into the details of this scenario.
I'm glad you feel the same and also want to speak up about about it!
(I started a thread in the brandz forum, it's now on the topic of 64bit lx,
there are more details there of our environment)
Here are the details of my goals: (2 flavors)
I would like to build a display-server with 100 users, each with their own
personal brandz-Linux zone. Their /pkg or /app space would be a (replicated to
the display server) zfs filesystem in the root zone. (lofs this, the simple
part). Their /prj or /project space would be the same auto.projects map which
all other solaris and linux boxes have. (the heart of this discussion.. I don't
want 100 autofs5 daemons running))
the other flavor goes like this:
in our LSF farm we generally have 2 kinds of queues (or Job Profiles): large
mem (32-64GB) single-core, and multi-core ( <=4 core) small-memory <4GB.
with a 16 thread, 144GB Nehalem server, we need to have job-slots for both
kinds of these; currently with LSF it is impossible for us to have a single
machine in both kinds of queues. To go further with my idea, I want to use
Solaris resource-controls to help buffer the load, in addition to LSF or Sun
Grid Engine to buffer and schedule the jobs before dispatch.
You spread those two flavors over a bunch of new modern hardware, and you have
a new model which (IMHO) implements "virtualization done right".
This message posted from opensolaris.org
zones-discuss mailing list