Subject: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] To: PSARC-ext@Sun.Com Cc: gerald.jelinek@sun.com Bcc: one-pager-list@sac.sfbay one-pager-log@sac.sfbay sac-bar@sac.sfbay 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