Tjere are some SMF services known to break when moving into a zone from 
a physical server.  Things like sysevent, FMA-ish stuff, ldom manager, 
etc. (I don't have my notes in front of me, but I seem to remember 
around 4-5 from a SUNWall vanilla installation).  Mostly stuff tied to 
the hardware platform itself.

I had a customer ask about the BE idea just a couple weeks ago.  :)


James Carlson wrote:
> Jerry Jelinek writes:
>>      1) SMF services that are not usable within a zone should be deleted or
>>         disabled as necessary (for S8 and S9 we dealt with rc scripts 
>> instead).
>>      2) Network configuration must be adjusted depending on if the zone is
>>         shared-stack or exclusive.
> Depending on what the original archived server once did, it seems at
> least possible that some of the changes that occur here could cause
> damage to the services that the image will provide when run inside a
> zone.
> Can a user predict what these automatic changes will be?  After
> import, is there a log of the changes or "adjustments" made?
> S10 has a number of new features over S8 and S9.  How do these factor
> in?  For instance, what happens to the privileges required in order to
> run the services contained in an archive?  (The user might need to
> configure the zone so that the right set of non-default privileges are
> granted.  Is there some new way to do this, or does the user need to
> trouble-shoot failing services?)
>>      -a {path} - specifies a path to an archive to unpack into the zone
>>      -d {path} - specifies a path to a tree of files as the source for the
>>                  installation.
> Just for clarification: does that '-d {path}' option point to a system
> root?  Could I use "lumount" to mount up an inactive BE and turn it
> into a zone?

zones-discuss mailing list

Reply via email to