SUMMARY: This fast-track enhances the Solaris Zones [1] subsystem to address an existing RFE[2] requesting the ability to migrate an installed non-global zone from one machine to another. We will implement the concept of detaching and attaching a zone. An installed non-global zone must be detached prior to moving it from one system to another. The process of detaching the zone will create the information necessary to attach the zone on a different system. Attaching the zone will first validate that the new machine is capable of properly hosting the zone. Patch binding is requested for the new sub-commands and the stability of these interfaces is "evolving". DETAILS: Overview Migrating a zone from one system to another involves the following steps: 1. Detaching the Zone. This leaves the zone on the originating system in the "configured" state. Behind the scenes, the system will generate a "manifest" of the information needed to validate that the zone can be successfully attached to a new host machine. 2. Data Migration. The system administrator moves the data which represents the zone to a new host system (more details below). 3. Zone Configuration. The system administrator creates the zone configuration on the new host using zonecfg(1m). 4. Attaching the zone. This will validate that the host is capable of supporting the zone before the attach can succeed. The zone is left in the "installed" state. Validation The validation will check that the exact version of the required packages and patches are installed on the new host. The algorithm to determine the packages and patches that must be validated is: For each package installed in the global zone: - ignore the package if SUNW_PKG_THISZONE is 'true' otherwise, - validate the package if a) SUNW_PKG_ALLZONES is 'true', or b) any file delivered by the package is in a file system that is inherited from the global zone. If the zone does not inherit any file systems (whole root) then (b) will be skipped. For each of the packages that is being validated we will also validate all of the associated patches. In the future we plan to extend this so that we might upgrade the zone or add patches to the zone when we attach, but initially we will only validate the new host and inform the sys-admin if there are packages or patches that are out of sync with what was installed on the original host machine. In order to validate the package and patch versions from the original host and new host, we will read this information from the pkginfo files in /var/sadm/pkg. We will also need to read the /var/sadm/install/contents file to determine which packages are within inherited-pkg-dirs. While some of this information is public, the contents file format and the existence of the pkginfo files within /var/sadm/pkg is not. These are contract private interfaces and a contract with the Install group, to allow us to access these files, is part of this case. zoneadm Sub-Commands We will add two new sub-commands to the zoneadm command and one new option to the create subcommand within zonecfg. The syntax for detaching a zone will be: # zoneadm -z my-zone detach The zone must be halted before being detached. During detach we will generate metadata describing the versions of the packages and patches installed on the host. This will be stored in an XML file in the zonepath, alongside the root and dev directories. This facilitates easy movement of the zonepath from one system to another. We will not implement any kind of archive for a detached zone. We will document what the sys-admin must do to move the zone bits around, but they can move this any way they choose. In some cases, such as a SAN environment, the bits might not have to move at all. When we detach, we leave the zone in the configured state. The sys-admin can then delete the configured zone or attach to it later. The syntax for attaching a zone will be: # zoneadm -z my-zone attach [-F] Attaching a zone is analogous to installing a zone. That is, you first must configure the new zone using the zonecfg command. Once you have the new zone in the configured state you can use attach to set up the zone root instead of installing. During attach we will perform the package and patch sanity checks described above. This will validate that the attach can occur. If the packages and patches don't match we will list which packages and patches are out of sync and the zone will be left in the configured state. The sys-admin can then apply any required packages or patches to the host to enable the attach to succeed. Or, they may not be able to attach to the specific host if the installed software is sufficiently incompatible with the environment on the original machine. Once the attach has completed successfully, the XML file describing the zone will be removed. If you try to install or clone to a configured zone and there is an XML description for a detached zone in the zonepath, we will give an error and won't proceed. The -F option for attach allows the sys-admin to force the attach with no validation. This is useful in certain cases such as a clustered environment or for backup/restore, but it does require that the sys-admin is certain that the system is properly configured to host the zone or undefined behavior may later occur. zonecfg create option To facilitate configuring the detached zone on a new host we will add a new '-a' option to the create subcommand within zonecfg. The subcommand for creating a new zone from the detached XML data will be: zonecfg:my-zone> create -a path_to_zone_root The -a option will used the XML description of the detached zone to configure the new zone instance. It is not required to to configure the new zone this way. That is, the new zone can be configured using the traditional zonecfg operations and then "zoneadm attach" can be used to attach the zone root. All of the validation of the zone happens during attach, not during configuration of the zone. EXAMPLE host1# zoneadm -z my-zone detach - move the my-zone zonepath from host1 to host2 host2# zonecfg -z my-zone my-zone: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:my-zone> create -a /export/zones/my-zone zonecfg:my-zone> commit zonecfg:my-zone> exit host2# zoneadm -z my-zone attach Here is an example where some packages and patches are out of sync between the source host and the local host we are attempting to attach to. The actual syntax of the error messages will be different in the final implementation, this is just an example to give an idea of what might happen. host2# zoneadm -z my-zone attach source host packages inconsistent with local host SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch (2.6.0,REV=101.0.3.2005.12.19.21.22) SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch (11.11,REV=2006.01.03.00.45) SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch (11.11,REV=2006.01.03.00.45) NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed local host packages inconsistent with source host SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed source host patches inconsistent with local host 120081 is not installed 118844 is not installed 118344 is not installed local host patches inconsistent with source host 118669 was not installed 118668 was not installed 116299 was not installed EXPORTED INTERFACES zoneadm subcommands detach Evolving attach [-F] Evolving zonecfg create subcommand option -a path Evolving <zonepath>/SUNWdetached.xml Stable <zonepath>/SUNWattached.xml Stable zonecfg.dtd Committed Private IMPORTED INTERFACES /var/sadm/install/contents Contracted Unstable (LSARC/2004/464) /var/sadm/pkg/*/pkginfo Contracted Unstable A contract is part of this case. pkginfo(4) public VERSION keyword evolving (pkginfo(4)) PATCHLIST keyword public (psarc/1995/063) REFERENCES 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 2. RFE: Ability to migrate zones across machines Bugid 5022513