James,
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.
Yes, not everything that runs in the global zone works in a
non-global zone. NFS serving or non-global zones are the most obvious
examples.
For SMF services, the services to be deleted are the the ones
delivered in SVr4 pkgs with SUNW_PKG_HOLLOW=true since that matches
what happens when a zone is installed using the existing technique.
> Can a user predict what these automatic changes will be? After
> import, is there a log of the changes or "adjustments" made?
I assume you really mean which SMF services will be off, since
the other changes are listed here in the case? We can describe which
SMF services will be deleted or disabled in general terms, but we
really want this to be driven by the pkg metadata itself. We'll probably
also have a list of some well-known 3rd party services that don't work
inside a zone, such as vxvm, which we'll turn off. As with the S8 and
S9 brands, there may need to be some manual tweaking of the services
as part of the p2v process, although we've generally had good results
with the S8 and S9 brands without a lot of manual work.
There will also be a log file for this p2v process. I'll add that info to
the case.
> 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?)
I am not planning on making any automated changes to the privileges available
to the zone. If this turns out to be an important issue, then we could
look at that as a possible future enhancement. The problem I see is that
we don't have any data to automatically drive which services and apps need
which privs.
>> -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?
Yes, -d points to a system root, so your idea of turning a BE
into a zone should work just fine.
Thanks,
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
