Skip Navigation Links | |
Exit Print View | |
System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones |
1. Introduction to Solaris 10 Resource Management
2. Projects and Tasks (Overview)
3. Administering Projects and Tasks
4. Extended Accounting (Overview)
5. Administering Extended Accounting (Tasks)
6. Resource Controls (Overview)
7. Administering Resource Controls (Tasks)
8. Fair Share Scheduler (Overview)
9. Administering the Fair Share Scheduler (Tasks)
10. Physical Memory Control Using the Resource Capping Daemon (Overview)
11. Administering the Resource Capping Daemon (Tasks)
13. Creating and Administering Resource Pools (Tasks)
14. Resource Management Configuration Example
15. Resource Control Functionality in the Solaris Management Console
16. Introduction to Solaris Zones
17. Non-Global Zone Configuration (Overview)
18. Planning and Configuring Non-Global Zones (Tasks)
19. About Installing, Halting, Cloning, and Uninstalling Non-Global Zones (Overview)
20. Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks)
21. Non-Global Zone Login (Overview)
22. Logging In to Non-Global Zones (Tasks)
23. Moving and Migrating Non-Global Zones (Tasks)
Solaris 10 11/06: Moving a Non-Global Zone
Solaris 10 11/06: Migrating a Non-Global Zone to a Different Machine
How to Migrate A Non-Global Zone
How to Move the zonepath to a New Host
Solaris 10 5/08: About Validating a Zone Migration Before the Migration Is Performed
Solaris 10 5/08: How to Validate a Zone Migration Before the Migration Is Performed
Migrating a Zone From a Machine That Is not Usable
Using Update on Attach as a Patching Solution
24. Solaris 10 9/10: Migrating a Physical Solaris System Into a Zone (Tasks)
25. About Packages and Patches on a Solaris System With Zones Installed (Overview)
26. Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Tasks)
27. Solaris Zones Administration (Overview)
28. Solaris Zones Administration (Tasks)
29. Upgrading a Solaris 10 System That Has Installed Non-Global Zones
30. Troubleshooting Miscellaneous Solaris Zones Problems
31. About Branded Zones and the Linux Branded Zone
32. Planning the lx Branded Zone Configuration (Overview)
33. Configuring the lx Branded Zone (Tasks)
34. About Installing, Booting, Halting, Cloning, and Uninstalling lx Branded Zones (Overview)
35. Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks)
36. Logging In to lx Branded Zones (Tasks)
37. Moving and Migrating lx Branded Zones (Tasks)
38. Administering and Running Applications in lx Branded Zones (Tasks)
Note that with the Solaris 10 5/08 release, you can do a trial run of a zone migration before you actually move the zone to a different machine. For more information, see Solaris 10 5/08: About Validating a Zone Migration Before the Migration Is Performed.
New information has been added to this section since the Solaris 10 11/06 release.
The zonecfg and zoneadm commands can be used to migrate an existing non-global zone from one system to another. The zone is halted and detached from its current host. The zonepath is moved to the target host, where it is attached.
The following restrictions apply to zone migration:
The global zone on the target system must be running the same Solaris release as the original host.
To ensure that the zone will run properly, the target system must have the same versions of the following required operating system packages and patches as those installed on the original host.
Packages that deliver files under an inherit-pkg-dir resource
Packages where SUNW_PKG_ALLZONES=true
Other packages and patches, such as those for third-party products, can be different.
Solaris 10 10/08: If the new host has later versions of the zone-dependent packages and their associated patches, using zoneadm attach with the -u option updates those packages within the zone to match the new host. The update on attach software looks at the zone that is being migrated and determines which packages must be updated to match the new host. Only those packages are updated. The rest of the packages, and their associated patches, can vary from zone to zone. This option also enables automatic migration between machine classes, such as from sun4u to sun4v.
Solaris 10 9/10: If the new host has later versions of the packages and their associated patches, using zoneadm attach with the -U option updates those packages within the zone to match what would be seen with a newly installed non-global zone on this host. Any packages installed inside the zone but not installed in the global zone are ignored, and left as-is. This option also enables automatic migration between machine classes, such as from sun4u to sun4v.
Solaris 10 5/09: The -b option can be used to specify patches to be backed out of the zone before the update.
The host and target systems must have the same machine architecture unless the -u option, which can be used to migrate between sun4u and sun4v machine classes, is used.
Solaris 10 5/09:The -b option can be used to specify patches, either official or Interim Diagnostics/Relief (IDR), to be backed out of the zone during the attach. Multiple -b options can be specified. If any of the patches cannot be backed out for any reason, then the attach will fail and none of the patches will be backed out.
This option only applies to zone brands using SVr4 packaging.
To verify the Solaris release and the machine architecture, type:
#uname -m
The zoneadm detach process creates the information necessary to attach the zone on a different system. The zoneadm attach process verifies that the target machine has the correct configuration to host the zone.
Because there are several ways to make the zonepath available on the new host, the actual movement of the zonepath from one system to another is a manual process that is performed by the global administrator.
When attached to the new system, the zone is in the installed state.
You must be the global administrator in the global zone to perform this procedure.
To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
host1# zoneadm -z my-zone halt
host1# zoneadm -z my-zone detach
The detached zone is now in the configured state.
See How to Move the zonepath to a New Host for more information.
host2# zonecfg -z my-zone
You will see the following system message:
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> info zonename: my-zone zonepath: /export/zones/my-zone autoboot: false pool: inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr net: address: 192.168.0.90 physical: bge0
For example, the network physical device is different on the new host, or devices that are part of the configuration might have different names on the new host.
zonecfg:my-zone> select net physical=bge0 zonecfg:my-zone:net> set physical=e1000g0 zonecfg:my-zone:net> end
zonecfg:my-zone> commit zonecfg:my-zone> exit
host2# zoneadm -z my-zone attach
The system administrator is notified of required actions to be taken if either or both of the following conditions are present:
Required packages and patches are not present on the new machine.
The software levels are different between machines.
host2# zoneadm -z my-zone attach -u
Tip - Solaris 10 10/08: If the source system is running an older version of the Solaris system, it might not generate a correct list of packages when the zone is detached. To ensure that the correct package list is generated on the destination, you can remove the SUNWdetached.xml file from the zonepath. Removing this file will cause a new package list to be generated by the destination system.
This is not necessary with the Solaris 10 5/09 and later releases.
host2# zoneadm -z my-zone attach -U
host2# zoneadm -z my-zone attach -u -b IDR246802-01 -b 123456-08
Note that you can use the -b option independently of the -u or -U options.
host2# zoneadm -z my-zone attach -F
Caution - The -F option allows you to force the attach with no validation performed. This is useful in certain cases, such as in a clustered environment or for backup and restore operations, but it does require that the system be properly configured to host the zone. An incorrect configuration could result in undefined behavior later. |
There are many ways to create an archive of the zonepath. For example, you can use the cpio or pax commands described in the cpio(1)) and pax(1) man pages.
There are also several ways to transfer the archive to the new host. The mechanism used to transfer the zonepath from the source host to the destination depends on the local configuration. In some cases, such as a SAN, the zonepath data might not actually move. The SAN might simply be reconfigured so the zonepath is visible on the new host. In other cases, the zonepath might be written to tape, and the tape mailed to a new site.
For these reasons, this step is not automated. The system administrator must choose the most appropriate technique to move the zonepath to the new host.
To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
Example 23-1 Archiving and Moving the zonepath Using the tar Command
Create a tar file of the zonepath on host1 and transfer it to host2 by using the sftp command.
host1# cd /export/zones host1# tar cf my-zone.tar my-zone host1# sftp host2 Connecting to host2... Password: sftp> cd /export/zones sftp> put my-zone.tar Uploading my-zone.tar to /export/zones/my-zone.tar sftp> quit
On host2, unpack the tar file.
host2# cd /export/zones host2# tar xf my-zone.tar
For more information, see sftp(1) and tar(1).
See Resolving Problems With a zoneadm attach Operation for troubleshooting information on the following:
Patches and packages are out of sync.
Operating system releases do not match.
If you have copied the data instead of reconfiguring a SAN, then the zonepath data will still be visible on the source host even though the zone is now in the configured state. You can either manually remove the zonepath from the source host after you have finished moving the data to the new host, or you can reattach the zone to the source host and use the zoneadm uninstall command to remove the zonepath.
You can perform a trial run before the zone is moved to the new machine by using the “no execute” option,-n.
The zoneadm detach subcommand is used with the -n option to generate a manifest on a running zone without actually detaching the zone. The state of the zone on the originating system is not changed. The zone manifest is sent to stdout. The global administrator can direct this output to a file or pipe it to a remote command to be immediately validated on the target host. The zoneadm attach subcommand is used with the -n option to read this manifest and verify that the target machine has the correct configuration to host the zone without actually doing an attach.
The zone on the target system does not have to be configured on the new host before doing a trial-run attach.
You must be the global administrator in the global zone to perform this procedure.
To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.
global# zoneadm -z my-zone detach -n | ssh remotehost zoneadm attach -n -
The hyphen (—) at the end of the line specifies stdin for the path.
The validation is output to the source host screen, which is stdout.
global# zoneadm -z my-zone detach -n > filename
Copy the manifest to the new host system as described in How to Move the zonepath to a New Host, and perform the validation:
global# zoneadm attach -n path_to_manifest
The path can be — to specify stdin.