Mike Gerdts wrote:
[Removed OP from reply, added zones-discuss, updated subject]

On 3/29/07, Dave Miner <[EMAIL PROTECTED]> wrote:
Are there any parts of flash that can be opened?  Any interface specs,
ARC cases, etc?  These would be great improvements that the community
could work on.

Flash has some unresolved issues in opening the code.  However, now that
you mention it, the specs and ARC cases actually should be clean, such
that you and other interested parties could work on a clean-room
version.  I'll look into that a bit and see what I can sort out.
Cool - that would be extremely helpful.  Initially I was resigned to
just wait for the next generation of the related technologies to come
out.  Then I noticed that there were lots of lu* commands used during
zone creation.  With zone creation being such a key part of life with
Solaris, it really seems as though this needs to be open for the
community to work with it.

Yeah, that piece is somewhat problematic, though the reliance on LU
there is mostly for infrastructure, and not much on the actual LU
functionality.  The "plan" kicking around in my head was to break the
connection by cutting zone installation over to using essentially the
same code as zone cloning; there's a fair amount of similarity already,
anyway.

Sounds good on the surface, but some details suggest a devil is
lurking somewhere nearby.  How does this play with zones that use
inherit-pkg-dir?  How about files that are added but not part of a
package?


It strongly relates to going to ZFS as the root file system, as that's where I'd expect there to be significant improvement. By basing the install of non-global zones off a snapshot of the original installed file systems in the global (which is something we expect to keep), you avoid the files that aren't part of packages. Patching remains interesting, of course; it's probably in the same realm of difficulty as what we already do with the spooled originals of editable & volatile files, but possibly a bit cleaner. Yes, there are plenty of devilish details left there ;-)

When  a zone is cloned, there is the implication that you want all of
the customizations (sans sysidcfg stuff) to come over as well.  If the
global zone is cloned, this is likely not the case and as such more
care should be taken to only take what is part of the package
database.  That puts us in a situation where we are doing something
like reading /var/sadm/install/contents filtering out all of the
files/dirs in an inherit-pkg-dir, removing /dev entries, etc. to
generate a list of files to give to cpio.  I suspect this is pretty
much what ludo/lucreatezone is already doing.


Essentially.

An interesting question comes up when ZFS root comes about.  Could the
global zone be cloned to form full-root non-global zones?  If /usr,
/lib, /platform and /sbin are separate zfs file systems in the global
zone, could the global zone be cloned to form sparse non-global zones?
 Arguably the value of sparse zones goes down substantially when ZFS
clones are involved, but it does provide interesting food for thought.


Sparse zones present some problems in packaging that we haven't solved, so I wouldn't mind if they went away ;-) Doubt it's that simple, though.

Dave
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to