I'm sponsoring this fast-track for myself.
Thanks,
Jerry
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
native zones p2v
1.2. Name of Document Author/Supplier:
Author: Gerald Jelinek
1.3 Date of This Document:
12 December, 2008
4. Technical Description
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'. To the user, this simply looks like a new way
to install a zone, using an image of a physical system.
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 as a native-branded zone 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.
The system image is intended to be from the same minor release as is
running on the host system. That is, a nv system image for installing
into an nv-based zone or an S10 system image for installing into an
S10-based zone. We do not currently support updating an earlier system
image (e.g. Solaris 8) into a zone. While zone 'update on attach' can
currently update S10 images onto nv, its unclear how long that will
continue to work as nv evolves. If the system image does not match the
same minor release as is running in the global zone, the zone installation
will result in an error. Hosting a zone from a different minor release
is a different project [6] from this proposal.
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 that are automatically performed fall into the
following areas:
1) SMF services that are not usable within a zone should be deleted or
disabled as necessary. The information about which SMF services to
disable is primarily driven by the manifests that are delivered in
SVr4 pkgs with the SUNW_PKG_HOLLOW=true attribute.
2) Network configuration must be adjusted depending on if the zone is
shared-stack or exclusive.
3) NFS serving must be disabled [7].
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.
Information about all of these customizations to the zone is also logged
into the zone's installation log file, which is saved as
/var/tmp/{zonename}.install.{pid}.log.
Depending on what the original system did, the sysadmin may need to
perform other, manual, customizations to the zone after it has been
installed. For example, the privileges assigned to the zone may need
to be modified. This is not done automatically. Because not all system
services work inside zones, not every physical system is a good candidate
for migration into a zone.
The main user-visible interfaces are new native-brand zone installation
options. These options are the same as with the solaris8 and solaris9
brands.
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 (representing a system's
root) 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 -a and -d options are mutually exclusive. 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.
As with the solaris8 and solaris9 brands, the archive can be a flar,
cpio (optionally compressed), UFS dump, or pax (xustar) format.
Also, as with the solaris8 and solaris9 brands, the zone must be configured
as a whole-root zone to be installed using a system image.
=== Interface Table ===
Exported Interfaces Stability
----------------------------------------------------------------------
For the native brand
brand-specific install options Committed
documented in this case
Imported Interfaces Stability
----------------------------------------------------------------------
flar(1m) Evolving
svccfg(1M), svcadm(1M) Evolving [8]
______________________________________________________________________________
REFERENCES
______________________________________________________________________________
1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. 6667924 physical to virtual utility for native zones
3. PSARC/2007/350 Etude: Migration Technology
4. PSARC/2008/125 Etude Part Deux
5. PSARC/2007/621 zone update on attach
6. 6666646 Solaris 10 zones on OpenSolaris binary (supported) distributions
7. 4964859 RFE: Zones should be able to be NFS servers
8. PSARC 2002/547 Greenline
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
