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. :)
bill.
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
zones-discuss@opensolaris.org
