Re: [zones-discuss] zone p2v proposal

2008-12-13 Thread Jerry Jelinek
Mike Gerdts wrote:
 On Fri, Dec 12, 2008 at 6:45 PM, Jerry Jelinek gerald.jeli...@sun.com wrote:
 Mike Gerdts wrote:
 On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek gerald.jeli...@sun.com
 wrote:
The native brand installer will accept the following new arguments:

-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.
-p- preserve system configuration (either -p or -u required).
-s- install silently
-u- sys-unconfig(1M) the zone after installing it
-v- verbose output from the install process

The -p, -s, -u and -v options are only allowed when -a or -d is
provided.  If -a or -d is not given, then the zone is installed using
 the
existing mechanism.
 Can an option be added to not make another copy of the data?  That is,
 if I have already gotten the bits in place on disk that I am happy
 with, please don't copy them again (mv and zfs set mountpoint are OK
 if needed).
 Mike,

 I'll think about that.  What if -d {zonepath} just skipped the
 copy of the bits?

 Thanks,
 Jerry

 
 That sounds reasonable.  This seems to imply that the argument to -d
 will be a directory that has a subdirectory named root which is the
 actual root of the thing to be turned into a zone.

Mike,

I was thinking about this more last night and I think '-d -' would be
even simpler.  It would just mean, use the directory tree already in
place in the zonepath.

Thanks,
Jerry

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-13 Thread Mike Gerdts
On Sat, Dec 13, 2008 at 9:56 AM, Jerry Jelinek gerald.jeli...@sun.com wrote:
 Mike Gerdts wrote:

 On Fri, Dec 12, 2008 at 6:45 PM, Jerry Jelinek gerald.jeli...@sun.com
 wrote:

 Mike Gerdts wrote:

 On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek gerald.jeli...@sun.com
 wrote:

   The native brand installer will accept the following new arguments:

   -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.
   -p- preserve system configuration (either -p or -u required).
   -s- install silently
   -u- sys-unconfig(1M) the zone after installing it
   -v- verbose output from the install process

   The -p, -s, -u and -v options are only allowed when -a or -d is
   provided.  If -a or -d is not given, then the zone is installed using
 the
   existing mechanism.

 Can an option be added to not make another copy of the data?  That is,
 if I have already gotten the bits in place on disk that I am happy
 with, please don't copy them again (mv and zfs set mountpoint are OK
 if needed).

 Mike,

 I'll think about that.  What if -d {zonepath} just skipped the
 copy of the bits?

 Thanks,
 Jerry


 That sounds reasonable.  This seems to imply that the argument to -d
 will be a directory that has a subdirectory named root which is the
 actual root of the thing to be turned into a zone.

 Mike,

 I was thinking about this more last night and I think '-d -' would be
 even simpler.  It would just mean, use the directory tree already in
 place in the zonepath.

 Thanks,
 Jerry

Excellent point - I like that.  With this in place I think that we
will be at a point where the same flash archive that is used for
installing global zones will be nicely usable for installing full root
zones.  The big bonus here is that a path toward more consistent
installation mechanisms between non-virtualized servers, zones, and
ldoms starts to be more realistic.

I am most excited about the ability to (zfs) clone the global zone to
create a master non-global zone from which future non-global zones are
cloned.  On typical sun4v hardware this looks like it will cut the
time to image + create master non-global zone in half.  Assuming this
plays forward in the IPS world, it means that non-global zones should
be easily created without access to the repository.  This will likely
make those that are bandwidth constrained (or pay per bit) very happy.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-12 Thread Mike Gerdts
On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek gerald.jeli...@sun.com wrote:
 The native brand installer will accept the following new arguments:

 -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.
 -p- preserve system configuration (either -p or -u required).
 -s- install silently
 -u- sys-unconfig(1M) the zone after installing it
 -v- verbose output from the install process

 The -p, -s, -u and -v options are only allowed when -a or -d is
 provided.  If -a or -d is not given, then the zone is installed using the
 existing mechanism.

Can an option be added to not make another copy of the data?  That is,
if I have already gotten the bits in place on disk that I am happy
with, please don't copy them again (mv and zfs set mountpoint are OK
if needed).

Usage scenarios:

1) I restored a physical system from backups and need to attach it as
a zone.  For example

mkdir /zones/oops
metainit d1234 -p d50 8G
echo /dev/md/dsk/d1234 /dev/md/rdsk/d1234 /zones/oops ufs 1 yes -  /etc/vfstab
mount /zones/oops
chmod 700 /zones/oops
mkdir /zones/oops/root
use your favorite backup/restore tool to restore to /zones/oops/root
p2v it

2) Create zones as clones of /

zfs snapshot rpool/ROOT/snv_...@zonemaster
zfs clone rpool/ROOT/snv_1...@zonemaster rpool/zones/new
mkdir /zones/new/root
mv /zones/new/* /zones/new/root
p2v it, with sys-unconfig


-- 
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-12 Thread Jerry Jelinek
Mike Gerdts wrote:
 On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek gerald.jeli...@sun.com wrote:
 The native brand installer will accept the following new arguments:

 -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.
 -p- preserve system configuration (either -p or -u required).
 -s- install silently
 -u- sys-unconfig(1M) the zone after installing it
 -v- verbose output from the install process

 The -p, -s, -u and -v options are only allowed when -a or -d is
 provided.  If -a or -d is not given, then the zone is installed using the
 existing mechanism.
 
 Can an option be added to not make another copy of the data?  That is,
 if I have already gotten the bits in place on disk that I am happy
 with, please don't copy them again (mv and zfs set mountpoint are OK
 if needed).

Mike,

I'll think about that.  What if -d {zonepath} just skipped the
copy of the bits?

Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-12 Thread Mike Gerdts
On Fri, Dec 12, 2008 at 6:45 PM, Jerry Jelinek gerald.jeli...@sun.com wrote:
 Mike Gerdts wrote:

 On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek gerald.jeli...@sun.com
 wrote:

The native brand installer will accept the following new arguments:

-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.
-p- preserve system configuration (either -p or -u required).
-s- install silently
-u- sys-unconfig(1M) the zone after installing it
-v- verbose output from the install process

The -p, -s, -u and -v options are only allowed when -a or -d is
provided.  If -a or -d is not given, then the zone is installed using
 the
existing mechanism.

 Can an option be added to not make another copy of the data?  That is,
 if I have already gotten the bits in place on disk that I am happy
 with, please don't copy them again (mv and zfs set mountpoint are OK
 if needed).

 Mike,

 I'll think about that.  What if -d {zonepath} just skipped the
 copy of the bits?

 Thanks,
 Jerry


That sounds reasonable.  This seems to imply that the argument to -d
will be a directory that has a subdirectory named root which is the
actual root of the thing to be turned into a zone.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread James Carlson
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?

-- 
James Carlson, Solaris Networking  [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Bill Walker

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


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
Bill Walker wrote:
 
 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.

Bill,

Things like sysevent or FMA stuff are delivered in hollow pkgs,
so we know that those services should not exist inside the zone
and we'll get rid of them.

Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Mike Gerdts
On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek [EMAIL PROTECTED] wrote:
 SUMMARY:

 This fast-track enhances the Solaris Zones [1] subsystem to address an
 existing RFE [2] requesting a physical to virtual (or p2v) capability
 for installing native-branded zones based on an existing system image.

 This capability is very similar to what already exists for solaris8 and
 solaris9 branded zones [3,4], which are installed using an archive of an
 existing system image, but in this case there is no brand module and the
 zone brand is 'native'.

 Patch binding is requested for this native p2v capability.  The
 stability of these interfaces is documented in the interface table below.

 DETAILS:

 This new feature is primarily an extension to the native-brand zone
 installation code so that the zone can be installed using an archive of a
 system, as is already done with the solaris8 and solaris9 brands.
 However, because there is no brand module, part of the installation 
 process
 uses the zone update on attach [5] feature to sync the zone image up
 so that it is usable on the system.  Because update on attach does not
 allow zone downgrades, the system image being installed and p2v-ed must 
 not
 be newer than the host OS release or the installation will fail with an
 error.

 In addition to the update on attach during zone installation, there are
 a variety of other modifications which must be applied to the image so 
 that
 it is usable within a zone.  Again, this is very similar to what happens
 today with the solaris8 and solaris9 brands during installation.

 The image modifications fall into the following areas:
 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).

This implies that the source system can be S8, S9, or S10.  I don't
see anywhere else in the proposal that explicitly states that S8 and
S9 can be attached and upgraded, so I suspect I am reading my wishes
into your words.

Assuming the S8 and S9 are supported source systems, is there any real
difference in the resulting zone if the following paths are taken:

src-s9# lucreate -c s9 -n s10 ...
src-s9# luupgrade -s /mnt/s10media -n s10 ...
src-s9# luactivate s10
src-s10# flarcreate ... /net/server/src-10.flar
dst-s10# zoneadm install -a /net/server/src-10.flar ...

vs. (upgrade on attach - not branded)

src-s9# flarcreate ... /net/server/src-9.flar
dst-s10# zoneadm install -a /net/server/src-9.flar


 2) Network configuration must be adjusted depending on if the zone is
shared-stack or exclusive.
 3) NFS serving must be disabled [6].
 4) The vfstab must be adjusted so that local file systems from the 
 original
system are disabled.
 5) Any zones installed on the original system will be uninstalled and
deleted from the image (zones do not nest).

 All of these modifications happen transparently as part of the zone
 installation, as is the case with the solaris8 and solaris9 brands.

Will config files be removed or will services just be disabled (and
hollow packages removed)?  That is, will destructive things be done
that prevent the implementation of some future v2p (e.g. zone to ldom
or xen) transition?  Or is it believed that the typical packages that
are not appropriate for non-global zones lack configuration that would
be interesting in a p2v - v2p world?

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread James Carlson
Jerry Jelinek writes:
  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?

Exactly.

  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.

I can understand that some tweaking would end up being necessary, but
at least an outline of what's affected (if known) would probably be
good to include with the case materials.

 There will also be a log file for this p2v process.  I'll add that info to
 the case.

OK.

  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.

Right; that's what I was getting at.  We don't carry that sort of
metadata around in any convenient form.

I suppose it'd be possible to look through the SMF 'privileges' for
the services that are still enabled, and then attempt to union those
into the zone privileges ... but it's unclear if that's really the
right approach, particularly for services that might be aware enough
of zones to work in some other fashion when restricted by the
environment.

There are other things that work like this, such as ZFS delegations or
in network configuration, so there might be a broader issue here in
configuring the zone so that it can properly accept the archive.  I'm
not saying that I think it's unusable, but rather that there may be
non-trivial cases here where a good bit is left to the user's
imagination.

(Then there are other cases, such as NL7C.  You might possibly want to
use that if you're in the global zone, but since you can't use it in a
non-global zone, and since the web server itself is perfectly
serviceable _without_ NL7C, translating over means simply removing
that from the configuration.  I'm guessing that sort of thing is a
manual operation.)

   -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.

OK; should point out that this is intended to be a system root.  (I
know, it should be obvious, but since I had to ask anyway ...)

-- 
James Carlson, Solaris Networking  [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
Mike,

Mike Gerdts wrote:
 The image modifications fall into the following areas:
 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).
 
 This implies that the source system can be S8, S9, or S10.  I don't
 see anywhere else in the proposal that explicitly states that S8 and
 S9 can be attached and upgraded, so I suspect I am reading my wishes
 into your words.

That was not my intention.  I'll reword this.  The source system must
be a S10 or above (something that zone update on attach will handle).

 Will config files be removed or will services just be disabled (and
 hollow packages removed)?  That is, will destructive things be done
 that prevent the implementation of some future v2p (e.g. zone to ldom
 or xen) transition?  Or is it believed that the typical packages that
 are not appropriate for non-global zones lack configuration that would
 be interesting in a p2v - v2p world?

Where possible, things will be disabled, but for SMF services delivered
in hollow pkgs, those services must be removed due to the way the SMF
dependencies are defined.  Disabling those services doesn't work.  V2P is
something we've talked about but is outside the scope of this specific
proposal.  In general we'll try to leave enough info behind so that a future
v2p could be done, but that automated tool won't be part of this initial
project.  Also, hollow pkgs are not removed.  Those pkgs appear to be
installed within zones.  It is just the SMF services delivered by those
pkgs which will be removed.

Thanks,
Jerry

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Nicolas Williams
On Mon, Dec 08, 2008 at 10:14:26AM -0700, Jerry Jelinek wrote:
 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.

Why detect and delete them?  That sounds like a lot of pointless work.

Better leave them alone -- let them discover that they are not in the
global zone and fail to start accordingly (and disable themselves, and
log approapriately).

Nico
-- 
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
Nico,

Nicolas Williams wrote:
 On Mon, Dec 08, 2008 at 10:14:26AM -0700, Jerry Jelinek wrote:
 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.
 
 Why detect and delete them?  That sounds like a lot of pointless work.

Because the zone won't boot until those services are
deleted.  That doesn't seem pointless.  The whole idea is to try
to provided an automated tool which simplifies the task of p2v-ing
a system into a zone.  If 100% of these migrations will fail, then
solving that problem seems to be within the scope of the tool.
We have the pkg metadata which tells us which services should not
be run inside the zone, so I guess its not clear to me why we would
deliberately ignore that.

 Better leave them alone -- let them discover that they are not in the
 global zone and fail to start accordingly (and disable themselves, and
 log approapriately).

Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Nicolas Williams
On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote:
  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.
 
 Right; that's what I was getting at.  We don't carry that sort of
 metadata around in any convenient form.
 
 I suppose it'd be possible to look through the SMF 'privileges' for
 the services that are still enabled, and then attempt to union those
 into the zone privileges ... but it's unclear if that's really the
 right approach, particularly for services that might be aware enough
 of zones to work in some other fashion when restricted by the
 environment.

Shouldn't changes to privileges be backwards compatible?  I can't quite
tell if privilege names and semantics are intended to be Committed or
not.

In any case, even if privilege names and semantics not stable, surely
services can discover incompatible changes (e.g., if a service's
method_context refers to invalid privilege names then SMF can discover
this), and services that drop/retain specific privileges too will fail.
So at least the failures should be obvious.

No, I don't know how best to deal with such situations.

 There are other things that work like this, such as ZFS delegations or
 in network configuration, so there might be a broader issue here in
 configuring the zone so that it can properly accept the archive.  I'm
 not saying that I think it's unusable, but rather that there may be
 non-trivial cases here where a good bit is left to the user's
 imagination.

And if the image itself expects to have zones...  Yes, some things can
break, but maybe we should design the system so that using a system
image as a zone root should just work, with services that can't run in
NGZs disabling themselves, and services that can be configured
differently to run in zones either disabling themselves or changing
their configuration (as in your NL7C example, though why shouldn't NL7C
be available in NGZs?).

Nico
-- 
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread James Carlson
Jerry Jelinek writes:
 Mike Gerdts wrote:
  This implies that the source system can be S8, S9, or S10.  I don't
  see anywhere else in the proposal that explicitly states that S8 and
  S9 can be attached and upgraded, so I suspect I am reading my wishes
  into your words.
 
 That was not my intention.  I'll reword this.  The source system must
 be a S10 or above (something that zone update on attach will handle).

Update on attach just means apply saved patches, if any are
needed, right?

 Where possible, things will be disabled, but for SMF services delivered
 in hollow pkgs, those services must be removed due to the way the SMF
 dependencies are defined.  Disabling those services doesn't work.  V2P is

What maps packages to SMF services?  (I'm guessing it's a matter of
seeing the manifests in a hollow package and then reading the
manifests to determine what services they deliver, and disabling
those.  Is that right ... ?)

-- 
James Carlson, Solaris Networking  [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
James,

James Carlson wrote:
 Jerry Jelinek writes:
 Mike Gerdts wrote:
 This implies that the source system can be S8, S9, or S10.  I don't
 see anywhere else in the proposal that explicitly states that S8 and
 S9 can be attached and upgraded, so I suspect I am reading my wishes
 into your words.
 That was not my intention.  I'll reword this.  The source system must
 be a S10 or above (something that zone update on attach will handle).
 
 Update on attach just means apply saved patches, if any are
 needed, right?

Not really.  We see what pkgs are out of sync, either because of the
pkg version of because of patches applied to those pkgs, then we do
something similar to uninstalling and reinstalling those pkgs into the zone,
preserving the editable and volatile files.  This causes those pkgs
to be up-to-date with respect to the global zone, just as is the case
when a zone is newly installed.  Its a bit more complicated than that,
but we never actually apply patches to the zone.  The global zone files
are already patched and that is the source of the files for the non-global
zone.

 Where possible, things will be disabled, but for SMF services delivered
 in hollow pkgs, those services must be removed due to the way the SMF
 dependencies are defined.  Disabling those services doesn't work.  V2P is
 
 What maps packages to SMF services?  (I'm guessing it's a matter of
 seeing the manifests in a hollow package and then reading the
 manifests to determine what services they deliver, and disabling
 those.  Is that right ... ?)

Yes, thats the idea.

Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread James Carlson
Nicolas Williams writes:
 On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote:
  I suppose it'd be possible to look through the SMF 'privileges' for
  the services that are still enabled, and then attempt to union those
  into the zone privileges ... but it's unclear if that's really the
  right approach, particularly for services that might be aware enough
  of zones to work in some other fashion when restricted by the
  environment.
 
 Shouldn't changes to privileges be backwards compatible?  I can't quite
 tell if privilege names and semantics are intended to be Committed or
 not.

I'm not sure what you're talking about here, but I'm not referring to
any sort of version-related compatibility issue.  I'm explicitly
assuming that all such issues are dealt with by the upgrade-on-attach
feature (and that we're not yet addressing the S10-in-a-zone-on-OSOL
issue).

Instead, I'm talking about the required privileges in order to enable
a given service inside a non-global zone.  If a service is defined to
be run inside the zone (based on the archive presented), then someone
or something must make sure that the required privileges are granted
to the zone, or the service is going to fail.

It's a zone configuration issue.

Currently, there's a default set of privileges that are granted to
non-global zones.  It's possible to modify that set (up to a point)
with 'limitpriv'.  There are some that can never be granted, and if
those are needed, then enabling the service just isn't going to work
at all.  (Unless, somehow, the service itself detects this case
dynamically and falls back to some smaller set of zone-friendly
features.)

 NGZs disabling themselves, and services that can be configured
 differently to run in zones either disabling themselves or changing
 their configuration (as in your NL7C example, though why shouldn't NL7C
 be available in NGZs?).

I don't think anyone's bothered to make it zone-aware.

The reason I mentioned that one is because it's an interesting example
of an edge case: it could be in the archive being imported, but isn't
actually required for normal operation, so you can ignore it if you
don't know how to import it.

-- 
James Carlson, Solaris Networking  [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread James Carlson
Jerry Jelinek writes:
 James Carlson wrote:
  Update on attach just means apply saved patches, if any are
  needed, right?
 
 Not really.  We see what pkgs are out of sync, either because of the
 pkg version of because of patches applied to those pkgs, then we do
 something similar to uninstalling and reinstalling those pkgs into the zone,
 preserving the editable and volatile files.  This causes those pkgs
 to be up-to-date with respect to the global zone, just as is the case
 when a zone is newly installed.  Its a bit more complicated than that,
 but we never actually apply patches to the zone.  The global zone files
 are already patched and that is the source of the files for the non-global
 zone.

But you would _not_ do this across minor releases, so S9 installing on
S10 won't be upgraded nor (presumably) would S10 installing on
OpenSolaris/Nevada be upgraded at the package level.

Is that correct?  If so, then at least the administrative aspects of
patching are relevant here: the result is as though the required
patches were installed into the newly-attached zone, regardless of how
it's implemented internally.  (And just as patching doesn't work
across minor releases, it doesn't work here.)

I think answering that would answer the previous poster's question
about the difference between doing an upgrade before flar creation and
just importing a flar from S9: the former results in a native zone
using this new functionality, while the latter results in a non-native
brand without upgrade.

-- 
James Carlson, Solaris Networking  [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
James,

James Carlson wrote:
 Jerry Jelinek writes:
 James Carlson wrote:
 Update on attach just means apply saved patches, if any are
 needed, right?
 Not really.  We see what pkgs are out of sync, either because of the
 pkg version of because of patches applied to those pkgs, then we do
 something similar to uninstalling and reinstalling those pkgs into the zone,
 preserving the editable and volatile files.  This causes those pkgs
 to be up-to-date with respect to the global zone, just as is the case
 when a zone is newly installed.  Its a bit more complicated than that,
 but we never actually apply patches to the zone.  The global zone files
 are already patched and that is the source of the files for the non-global
 zone.
 
 But you would _not_ do this across minor releases, so S9 installing on
 S10 won't be upgraded nor (presumably) would S10 installing on
 OpenSolaris/Nevada be upgraded at the package level.

We can handle 'update on attach' from s10 to nv, although nv isn't an
official release yet and something might happen which breaks this (maybe
IPS?).  We don't support 'update on attach' of s8 or s9, although I have played
around with that and it kind of works.  There are some other issues there
which need to be looked at before we would support that.  One thing we've
considered, but which is not part of this proposal, is to use 'update
on attach' to convert an S8 or S9 branded zone into a native zone
running S10.  There hasn't been any demand for that feature yet, so
its not currently one we're working on.

 Is that correct?  If so, then at least the administrative aspects of
 patching are relevant here: the result is as though the required
 patches were installed into the newly-attached zone, regardless of how
 it's implemented internally.  (And just as patching doesn't work
 across minor releases, it doesn't work here.)

When crossing a minor release boundary (like s10 to nv) all of the pkg
version numbers change, so patches aren't a factor.  We see that there
are new versions of the pkgs, so we know those pkgs need to be updated.

 I think answering that would answer the previous poster's question
 about the difference between doing an upgrade before flar creation and
 just importing a flar from S9: the former results in a native zone
 using this new functionality, while the latter results in a non-native
 brand without upgrade.

As I said, we don't currently support 'update on attach' for pre-s10 images
but that might be something we could consider in the future.

Thanks,
Jerry

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Mike Gerdts
On Mon, Dec 8, 2008 at 12:37 PM, James Carlson [EMAIL PROTECTED] wrote:

 I think answering that would answer the previous poster's question
 about the difference between doing an upgrade before flar creation and
 just importing a flar from S9: the former results in a native zone
 using this new functionality, while the latter results in a non-native
 brand without upgrade.

I was asking under the assumption that an upgrade from a minor release
or two was supported.  Typically if I am moving a S8 or S9 physical
into a zone, I really want to do an upgrade (or similar) as well.  Not
being able to do this in one step is not that big of a deal - after
all I do seem to have workable alternatives:

1) On S8 or S9, use live upgrade to upgrade to S10, then
install/attach the S10 BE as unbranded.
2) Attach the S8 or S9 BE as a branded zone, then use live upgrade (?)
to populate a S10 BE which in turn gets installed/attached as an
unbranded zone.

I bet I can write a script to make that look like a single command.
Then, with time Jerry will follow up with a more elegant solution than
duct-tape and chewing gum one I come up with.  :)

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
Mike,

Mike Gerdts wrote:
 On Mon, Dec 8, 2008 at 12:37 PM, James Carlson [EMAIL PROTECTED] wrote:
 
 I think answering that would answer the previous poster's question
 about the difference between doing an upgrade before flar creation and
 just importing a flar from S9: the former results in a native zone
 using this new functionality, while the latter results in a non-native
 brand without upgrade.
 
 I was asking under the assumption that an upgrade from a minor release
 or two was supported.  Typically if I am moving a S8 or S9 physical
 into a zone, I really want to do an upgrade (or similar) as well.  Not
 being able to do this in one step is not that big of a deal - after
 all I do seem to have workable alternatives:

Since 'update on attach' isn't the same as a true upgrade, there
are some enhancements we would need to look at in order to really
make this work correctly.  These are the sorts of things we might
want to do as future enhancements once we have the basic s10 p2v
to a native zone working.

 1) On S8 or S9, use live upgrade to upgrade to S10, then
 install/attach the S10 BE as unbranded.
 2) Attach the S8 or S9 BE as a branded zone, then use live upgrade (?)
 to populate a S10 BE which in turn gets installed/attached as an
 unbranded zone.

The first option seems like it would be workable with what we
have today, plus this new p2v feature.

Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread James Carlson
Jerry Jelinek writes:
 We can handle 'update on attach' from s10 to nv, although nv isn't an
 official release yet and something might happen which breaks this (maybe
 IPS?).  We don't support 'update on attach' of s8 or s9, although I have 
 played
 around with that and it kind of works.  There are some other issues there
 which need to be looked at before we would support that.  One thing we've
 considered, but which is not part of this proposal, is to use 'update
 on attach' to convert an S8 or S9 branded zone into a native zone
 running S10.  There hasn't been any demand for that feature yet, so
 its not currently one we're working on.

Perhaps it's not this project, but it'd be interesting to see where
this feature set is headed.

I would expect that since we support non-native brand zones, the user
has to choose (somehow) whether he wants to have his imported zone
become upgraded to the current system or whether he wants it to stay
as-is.

Since we (intentionally?) make branded zones available only for minor
releases -- and not for individual KUs -- this means that the user
should expect that he's forced into an upgrade of some sort that
emulates patching when importing an S10 zone onto an S10 system.  But
should he expect this otherwise?  When we differ by a minor release,
there are two paths (as-is branded or upgrade to native), and it's not
clear which gets used or should be used.

Otherwise, if he's always forced into an upgrade, then that means
branded zones eventually go away, doesn't it?

Or does giving the user this sort of control open the possibility for
different zones on an S10 system that run different S10 Updates?

Obviously, I'm confused.  :-/

  Is that correct?  If so, then at least the administrative aspects of
  patching are relevant here: the result is as though the required
  patches were installed into the newly-attached zone, regardless of how
  it's implemented internally.  (And just as patching doesn't work
  across minor releases, it doesn't work here.)
 
 When crossing a minor release boundary (like s10 to nv) all of the pkg
 version numbers change, so patches aren't a factor.  We see that there
 are new versions of the pkgs, so we know those pkgs need to be updated.

I think that misses the point.  I wasn't expecting upgrade on attach
to do anything across a minor release boundary; I was expecting it to
do what it does on S10, which (from a user's point of view, not an
implementation view) is effectively upgrade the bits as though patches
were added due to the differing patch levels of the source archive and
the running machine.

I'm surprised that it might do something different.

-- 
James Carlson, Solaris Networking  [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
James,

James Carlson wrote:
 Jerry Jelinek writes:
 We can handle 'update on attach' from s10 to nv, although nv isn't an
 official release yet and something might happen which breaks this (maybe
 IPS?).  We don't support 'update on attach' of s8 or s9, although I have 
 played
 around with that and it kind of works.  There are some other issues there
 which need to be looked at before we would support that.  One thing we've
 considered, but which is not part of this proposal, is to use 'update
 on attach' to convert an S8 or S9 branded zone into a native zone
 running S10.  There hasn't been any demand for that feature yet, so
 its not currently one we're working on.
 
 Perhaps it's not this project, but it'd be interesting to see where
 this feature set is headed.

There are different possibilities, such as I've mentioned; updating
s8 and s9 branded zones to native, or p2v for pre-s10 systems, or
making update on attach be more like a true upgrade, or
update on attach between different pkging systems (svr4 to IPS).  What
we actually do will depend on the demand and the priority vs. other
features.

 I would expect that since we support non-native brand zones, the user
 has to choose (somehow) whether he wants to have his imported zone
 become upgraded to the current system or whether he wants it to stay
 as-is.

Yes, so if you configure the zone with the 'native' brand, then that
means something different than if you configure it to be a 'solaris8'
or 'solaris9' branded zone.

 Since we (intentionally?) make branded zones available only for minor
 releases -- and not for individual KUs -- this means that the user
 should expect that he's forced into an upgrade of some sort that
 emulates patching when importing an S10 zone onto an S10 system.  But
 should he expect this otherwise?  When we differ by a minor release,
 there are two paths (as-is branded or upgrade to native), and it's not
 clear which gets used or should be used.

When attaching a zone to a new system, the zone configuration's brand
dictates the behavior.  For solaris8 or solaris9 branded zones, nothing
is done to the zone.  For native-branded zones, either the zone is already
in sync with the global zone (making it usable) or it is not in sync
and you must use 'update on attach' to complete the migration.

 Otherwise, if he's always forced into an upgrade, then that means
 branded zones eventually go away, doesn't it?

No.  If the zone was a solaris8 or solaris9 branded zone to begin with,
then it remains that way (assuming the brand is supported on the new
host).

 Or does giving the user this sort of control open the possibility for
 different zones on an S10 system that run different S10 Updates?

We don't have a solaris10-brand at this time so the issue doesn't
apply.  It sounds like you might be thinking of the following RFE:

646 Solaris 10 zones on OpenSolaris binary (supported) distributions

 Obviously, I'm confused.  :-/
 
 Is that correct?  If so, then at least the administrative aspects of
 patching are relevant here: the result is as though the required
 patches were installed into the newly-attached zone, regardless of how
 it's implemented internally.  (And just as patching doesn't work
 across minor releases, it doesn't work here.)
 When crossing a minor release boundary (like s10 to nv) all of the pkg
 version numbers change, so patches aren't a factor.  We see that there
 are new versions of the pkgs, so we know those pkgs need to be updated.
 
 I think that misses the point.  I wasn't expecting upgrade on attach
 to do anything across a minor release boundary; I was expecting it to
 do what it does on S10, which (from a user's point of view, not an
 implementation view) is effectively upgrade the bits as though patches
 were added due to the differing patch levels of the source archive and
 the running machine.
 
 I'm surprised that it might do something different.

Yes, it does that.  I didn't mean to imply it did something different.
update on attach always uses the same mechanism to update pkgs within
the zone, whether the pkg varies by version number or by the patches
applied to the pkg.

Thanks,
Jerry


___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread James Carlson
Jerry Jelinek writes:
  Since we (intentionally?) make branded zones available only for minor
  releases -- and not for individual KUs -- this means that the user
  should expect that he's forced into an upgrade of some sort that
  emulates patching when importing an S10 zone onto an S10 system.  But
  should he expect this otherwise?  When we differ by a minor release,
  there are two paths (as-is branded or upgrade to native), and it's not
  clear which gets used or should be used.
 
 When attaching a zone to a new system, the zone configuration's brand
 dictates the behavior.  For solaris8 or solaris9 branded zones, nothing
 is done to the zone.  For native-branded zones, either the zone is already
 in sync with the global zone (making it usable) or it is not in sync
 and you must use 'update on attach' to complete the migration.

That's the key part I was missing -- the fact that native brand
dictates the behavior.  (Well, that and the word patch used in
2007/621.  ;-})

I think we're in sync now.

  Or does giving the user this sort of control open the possibility for
  different zones on an S10 system that run different S10 Updates?
 
 We don't have a solaris10-brand at this time so the issue doesn't
 apply.

Yep; understood.

  It sounds like you might be thinking of the following RFE:
 
 646 Solaris 10 zones on OpenSolaris binary (supported) distributions

Presumably, as a non-native zone, if such a thing existed, it would be
expected to result in no upgrade-on-attach behavior.  Right?

  I think that misses the point.  I wasn't expecting upgrade on attach
  to do anything across a minor release boundary; I was expecting it to
  do what it does on S10, which (from a user's point of view, not an
  implementation view) is effectively upgrade the bits as though patches
  were added due to the differing patch levels of the source archive and
  the running machine.
  
  I'm surprised that it might do something different.
 
 Yes, it does that.  I didn't mean to imply it did something different.
 update on attach always uses the same mechanism to update pkgs within
 the zone, whether the pkg varies by version number or by the patches
 applied to the pkg.

OK.  The surprise to me is that it doesn't seem to care about minor
release.  I guess that's obvious when the mechanism is explained,
but it certainly wasn't obvious to me.

-- 
James Carlson, Solaris Networking  [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Jerry Jelinek
James,

James Carlson wrote:
 Presumably, as a non-native zone, if such a thing existed, it would be
 expected to result in no upgrade-on-attach behavior.  Right?

Right, although the behavior is really dictated by the brand
definition, so some sort of behavior could be defined for
zone attachment.  That is just theoretical, since in practice
you would normally leave the zone alone since the brand module
in the kernel would handle the differences between the non-global
zone and the global zone.  For the native brand, since there is
no brand module in the kernel, the zone must be in sync.

 OK.  The surprise to me is that it doesn't seem to care about minor
 release.  I guess that's obvious when the mechanism is explained,
 but it certainly wasn't obvious to me.

'update on attach' really only cares about syncing up the
dependent pkgs between the the non-global and global zone.
When crossing minor release boundaries there can be more
complex stuff going on, so although it works right now for
s10 to nv, going from something like s8 to s10 has some issues
we'd need to figure out (e.g. pkgs changing around, no zone
pkg metadata in s8, etc.).

Thanks,
Jerry

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone p2v proposal

2008-12-08 Thread Nicolas Williams
On Mon, Dec 08, 2008 at 01:30:18PM -0500, James Carlson wrote:
 Nicolas Williams writes:
  On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote:
   I suppose it'd be possible to look through the SMF 'privileges' for
   the services that are still enabled, and then attempt to union those
   into the zone privileges ... but it's unclear if that's really the
   right approach, particularly for services that might be aware enough
   of zones to work in some other fashion when restricted by the
   environment.
  
  Shouldn't changes to privileges be backwards compatible?  I can't quite
  tell if privilege names and semantics are intended to be Committed or
  not.
 
 I'm not sure what you're talking about here, but I'm not referring to
 any sort of version-related compatibility issue.  I'm explicitly
 assuming that all such issues are dealt with by the upgrade-on-attach
 feature (and that we're not yet addressing the S10-in-a-zone-on-OSOL
 issue).

Ah, OK.

 Instead, I'm talking about the required privileges in order to enable
 a given service inside a non-global zone.  If a service is defined to
 be run inside the zone (based on the archive presented), then someone
 or something must make sure that the required privileges are granted
 to the zone, or the service is going to fail.
 
 It's a zone configuration issue.

Right.  And my proposal is that services like svc:/network/nfs/server,
which cannot run in NGZs should simply log and disable themselves if
started in an NGZ.  I.e., let the zone configuration here happen lazily.

The main rationale for doing that is that it's easier to do that at
runtime than at configuration time.  Not only is looking into such a
zone's SMF repository hard, but so is looking into its packaging
(besides, the switch to IPS will make that even more obnoxious: code
that needs to be thrown out later).  Of course, it may be harder to fix
all such services to self-disable in NGZs.

  NGZs disabling themselves, and services that can be configured
  differently to run in zones either disabling themselves or changing
  their configuration (as in your NL7C example, though why shouldn't NL7C
  be available in NGZs?).
 
 I don't think anyone's bothered to make it zone-aware.

I wasn't proposing that it be made to be zone aware (though I gather
that'd be nice).

 The reason I mentioned that one is because it's an interesting example
 of an edge case: it could be in the archive being imported, but isn't
 actually required for normal operation, so you can ignore it if you
 don't know how to import it.

Indeed.
___
zones-discuss mailing list
zones-discuss@opensolaris.org