<chapter id="gdqnv"><title>Moving and Migrating <literal>lx</literal> Branded
Zones (Tasks)</title><highlights><para>This chapter describes how to:</para><itemizedlist><listitem><para>Move an existing <literal>lx</literal> branded zone to a new
location on the same machine</para>
</listitem><listitem><para>Validate what will happen in an <literal>lx</literal> branded
zone migration before the actual migration is performed.</para>
</listitem><listitem><para>Migrate an existing <literal>lx</literal> branded zone to
a new machine.</para>
</listitem>
</itemizedlist>
</highlights><sect1><title>Moving an <literal>lx</literal> Branded Zone</title><para>This procedure is used to move a zone to a new location on the same
system by changing the <literal>zonepath</literal>. The zone must be halted.
The new <literal>zonepath</literal> must be on a local file system. The normal <literal>zonepath</literal> criteria described in <olink targetptr="gdahx" remap="internal">Resource
and Property Types</olink> apply.</para><task id="gdqsp"><title>How to Move a Zone</title><procedure><step><para>Become superuser, or assume the Primary Administrator role.</para><para>Roles are described in <olink targetdoc="sysadv1" targetptr="smcover-95" remap="external"><citetitle remap="section">Using the Solaris Management Tools With RBAC (Task Map)</citetitle> in <citetitle remap="book">System Administration Guide: Basic Administration</citetitle></olink>.</para>
</step><step><para>Halt the zone to be moved, <literal>db-zone</literal> in this
procedure.</para><screen>global# <userinput>zoneadm -z db-zone halt</userinput></screen>
</step><step><para>Use the <command>zoneadm</command> command with the <literal>move</literal> subcommand
to move the zone to a new <literal>zonepath</literal>, <literal>/export/zones/db-zone</literal>.</para><screen>global# <userinput>zoneadm -z db-zone move /export/zones/db-zone</userinput></screen>
</step><step><para>Verify the path.</para><screen>global# <userinput>zoneadm list -iv</userinput>
  ID NAME             STATUS         PATH                  BRAND      IP
   0 global           running        /                     native     shared
   - lx-zone          installed      /export/home/lx-zone  lx         shared
   - db-zone          installed      /export/zones/db-zone lx         shared</screen>
</step>
</procedure>
</task>
</sect1><sect1 id="gdqsr"><title>Migrating an <literal>lx</literal> Branded Zone to
a Different Machine</title><para>You can do a trial run of a zone migration before you actually move
the zone to a different machine. For more information, see <olink targetptr="gcxfx" remap="internal">About Validating a Zone Migration Before the Migration Is
 Performed</olink>.</para><para>Note that the trial run does not validate the processor type, so you
must verify that the target machine is running a supported processor.</para><sect2 id="gdqsz"><title>About Migrating an <literal>lx</literal> Branded
Zone</title><para>The <command>zonecfg</command> and <command>zoneadm</command> 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 <literal>zonepath</literal> is moved to the target host, where it
is attached.</para><para>The following requirements apply to <literal>lx</literal> branded zone
migration:</para><itemizedlist><listitem><para>The global zone on the target system must be running the same
Solaris release as the original host.</para>
</listitem><listitem><para>To ensure that the zone will run properly, the target system
must have the same versions of the required operating system packages and
patches that were installed on the original host.</para>
</listitem><listitem><para>The brand must be the same on the original host and on the
target system.</para>
</listitem><listitem><para>The target system must have one of the following supported
i686 processor types:</para><itemizedlist><listitem><para>Intel</para><itemizedlist><listitem><para>Pentium Pro</para>
</listitem><listitem><para>Pentium II</para>
</listitem><listitem><para>Pentium III</para>
</listitem><listitem><para>Celeron</para>
</listitem><listitem><para>Xeon</para>
</listitem><listitem><para>Pentium 4</para>
</listitem><listitem><para>Pentium M</para>
</listitem><listitem><para>Pentium D</para>
</listitem><listitem><para>Pentium Extreme Edition</para>
</listitem><listitem><para>Core</para>
</listitem><listitem><para>Core 2</para>
</listitem>
</itemizedlist><para>AMD</para><itemizedlist><listitem><para>Opteron</para>
</listitem><listitem><para>Athlon XP</para>
</listitem><listitem><para>Athlon 64</para>
</listitem><listitem><para>Athlon 64 X2</para>
</listitem><listitem><para>Athlon FX</para>
</listitem><listitem><para>Duron</para>
</listitem><listitem><para>Sempron</para>
</listitem><listitem><para>Turion 64</para>
</listitem><listitem><para>Turion 64 X2</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist><para>The <command>zoneadm</command> <literal>detach</literal> process creates
the information necessary to attach the zone on a different system. The <command>zoneadm</command> <literal>attach</literal> process verifies that the target
machine has the correct configuration to host the zone. Because there are
several ways to make the <literal>zonepath</literal> available on the new
host, the actual movement of the <literal>zonepath</literal> from one system
to another is a manual process that is performed by the global administrator.</para><para>When attached to the new system, the zone is in the installed state.</para>
</sect2><task id="gdqtd"><title>How to Migrate an <literal>lx</literal> Branded Zone</title><procedure><step><para>Become superuser, or assume the Primary Administrator role.</para><para>To create the role and assign the role to a user, see <olink targetdoc="sysadv1" targetptr="smcover-95" remap="external"><citetitle remap="section">Using the Solaris Management Tools With RBAC (Task Map)</citetitle> in <citetitle remap="book">System Administration Guide: Basic Administration</citetitle></olink>.</para>
</step><step><para>Halt the zone to be migrated, <literal>lx-zone</literal> in this
procedure.</para><screen>host1# <userinput>zoneadm -z lx-zone halt</userinput></screen>
</step><step><para>Detach the zone.</para><screen>host1# <userinput>zoneadm -z lx-zone detach</userinput></screen><para>The detached zone is now in the configured state.</para>
</step><step><para>Move the <literal>zonepath</literal> for <literal>lx-zone</literal> to
the new host.</para><para>See <olink targetptr="gdqse" remap="internal">How to Move the zonepath
to a new Host</olink> for more information.</para>
</step><step><para>On the new host, configure the zone.</para><screen>host2# <userinput>zonecfg -z lx-zone</userinput></screen><para>You will see the following system message:</para><screen>lx-zone: No such zone configured
Use 'create' to begin configuring a new zone.</screen>
</step><step><para>To create the zone <literal>lx-zone</literal> on the new host,
use the <command>zonecfg</command> command with the <option>a</option> option
and the <literal>zonepath</literal> on the new host.</para><screen>zonecfg:lx-zone> <userinput>create -a /export/zones/lx-zone</userinput></screen>
</step><step><para>View the configuration.</para><screen>zonecfg:lx-zone> <userinput>info</userinput>
zonename: lx-zone
zonepath: /export/zones/lx-zone
brand: lx
autoboot: false
bootargs:
pool:
limitpriv:
net:
         address: 192.168.0.90
         physical: bge0</screen>
</step><step><para>(Optional) Make any required adjustments to the configuration.</para><para>For example, the network physical device might be different on the new
host, or devices that are part of the configuration might have different names
on the new host.</para><screen>zonecfg:lx-zone> <userinput>select net physical=bge0</userinput>
zonecfg:lx-zone:net> <userinput>set physical=e1000g0</userinput>
zonecfg:lx-zone:net> <userinput>end</userinput></screen>
</step><step><para>Commit the configuration and exit.</para><screen>zonecfg:lx-zone> <userinput>commit</userinput>
zonecfg:lx-zone> <userinput>exit</userinput></screen>
</step><step><para>Attach the zone on the new host.</para><stepalternatives><step><para>Attach the zone with a validation check. </para><screen>host2# <userinput>zoneadm -z lx-zone attach</userinput></screen><para>The system administrator is notified of required actions to be taken
if either or both of the following conditions are present:</para><itemizedlist><listitem><para>Required packages and patches are not present on the new machine.</para>
</listitem><listitem><para>The software levels are different between machines.</para>
</listitem>
</itemizedlist>
</step><step><para>Force the attach operation without performing the validation.</para><screen>host2# <userinput>zoneadm -z lx-zone attach -F</userinput></screen><caution><para>The <option>F</option> option allows you to force the <literal>attach</literal> 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.</para>
</caution>
</step>
</stepalternatives>
</step>
</procedure>
</task><task id="gdqse"><title>How to Move the <literal>zonepath</literal> to a new
Host</title><tasksummary><para>There are many ways to create an archive of the <literal>zonepath</literal>.
For example, you can use the <command>cpio</command> or <command>pax</command> commands
described in the <olink targetdoc="group-refman" targetptr="cpio-1" remap="external"><citerefentry><refentrytitle>cpio</refentrytitle><manvolnum>1</manvolnum></citerefentry></olink>)
and <olink targetdoc="group-refman" targetptr="pax-1" remap="external"><citerefentry><refentrytitle>pax</refentrytitle><manvolnum>1</manvolnum></citerefentry></olink> man
pages.</para><para>There are also several ways to transfer the archive to the new host.
The mechanism used to transfer the <literal>zonepath</literal> from the source
host to the destination depends on the local configuration. In some cases,
such as a SAN, the <literal>zonepath</literal> data might not actually move.
The SAN might simply be reconfigured so the <literal>zonepath</literal> is
visible on the new host.  In other cases, the <literal>zonepath</literal> might
be written to tape, and the tape mailed to a new site.</para><para>For these reasons, this step is not automated. The system administrator
must choose the most appropriate technique to move the <literal>zonepath</literal> to
the new host.</para>
</tasksummary><procedure><step><para>Become superuser, or assume the Primary Administrator role.</para><para>To create the role and assign the role to a user, see <olink targetdoc="sysadv1" targetptr="smcover-95" remap="external"><citetitle remap="section">Using the Solaris Management Tools With RBAC (Task Map)</citetitle> in <citetitle remap="book">System Administration Guide: Basic Administration</citetitle></olink>.</para>
</step><step><para>Move the <literal>zonepath</literal> to the new host. You can
use the method described in this procedure, or use another method of your
choice.</para>
</step>
</procedure><example id="gdqsd"><title>Archiving and Moving the <literal>zonepath</literal> Using the <command>tar</command> Command</title><orderedlist><listitem><para>Create a <command>tar</command> file of the <literal>zonepath</literal> on <literal>host1</literal> and transfer it to <literal>host2</literal> by using the <command>sftp</command> command.</para><screen>host1# <userinput>cd /export/zones</userinput>
host1# <userinput>tar cf lx-zone.tar lx-zone</userinput>
host1# <userinput>sftp host2</userinput>
Connecting to host2...
Password:
sftp> <userinput>cd /export/zones</userinput>
sftp> <userinput>put lx-zone.tar</userinput>
Uploading lx-zone.tar to /export/zones/lx-zone.tar
sftp> <userinput>quit</userinput></screen>
</listitem><listitem><para>On <literal>host2</literal>, unpack the <command>tar</command> file.</para><screen>host2# cd <userinput>/export/zones</userinput>
host2# <userinput>tar xf lx-zone.tar</userinput></screen>
</listitem>
</orderedlist><para>For more information, see <olink targetdoc="group-refman" targetptr="sftp-1" remap="external"><citerefentry><refentrytitle>sftp</refentrytitle><manvolnum>1</manvolnum></citerefentry></olink> and <olink targetdoc="group-refman" targetptr="tar-1" remap="external"><citerefentry><refentrytitle>tar</refentrytitle><manvolnum>1</manvolnum></citerefentry></olink>.</para>
</example><taskrelated role="troubleshooting"><para>See <olink targetptr="gchbp" remap="internal">Resolving Problems With a zoneadm attach
Operation</olink> for troubleshooting information on the following:</para><itemizedlist><listitem><para>Patches and packages are out of sync.</para>
</listitem><listitem><para>Operating system releases do not match.</para>
</listitem>
</itemizedlist><para>The user must verify that the processor type in the new machine is supported.
See <olink targetptr="gdqsz" remap="internal">About Migrating an lx Branded Zone</olink> for
more information.</para>
</taskrelated>
</task><sect2 id="gdqtm"><title>About Validating an <literal>lx</literal> Branded
 Zone Migration Before the Migration Is  Performed</title><para>You can perform a trial
run before the zone is moved to the new machine by using the &ldquo;no execute&rdquo;
option, <option>n</option>.</para><para>The <command>zoneadm</command> <literal>detach</literal> subcommand
is used with the <option>n</option> 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 <literal>stdout</literal>.
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 <command>zoneadm</command> <literal>attach</literal> subcommand is used with the <option>n</option> option
to read this manifest and verify that the target machine has the correct configuration
to host the zone without actually doing an attach.</para><para>The zone on the target system does <emphasis>not</emphasis> have to
be configured on the new host before doing a trial-run attach.</para>
</sect2><task id="gdqsm"><title>How to Validate an <literal>lx</literal> Branded Zone
Migration Before the Migration Is  Performed</title><tasksummary><para>You must be the global administrator in the global zone to perform this
procedure.</para>
</tasksummary><procedure><step><para>Become superuser, or assume the Primary Administrator role.</para><para>To create the role and assign the role to a user, see <olink targetdoc="sysadv1" targetptr="smcover-95" remap="external"><citetitle remap="section">Using the Solaris Management Tools With RBAC (Task Map)</citetitle> in <citetitle remap="book">System Administration Guide: Basic Administration</citetitle></olink>.</para>
</step><step><para>Use one of the following methods.</para><stepalternatives><step><para>Generate the manifest on a source host named <literal>lx-zone</literal> and
pipe the output to a remote command that will  immediately validate the target
host:</para><screen>global# <userinput>zoneadm -z lx-zone detach -n | ssh remotehost zoneadm attach -n -</userinput></screen><para>The hyphen (<literal>&mdash;</literal>) at the end of the line specifies <literal>stdin</literal> for the path.</para>
</step><step><para>Generate the manifest on a source host named <literal>lx-zone</literal> and
direct the output to a file:</para><screen>global# <userinput>zoneadm -z lx-zone detach -n </userinput></screen><para><emphasis role="strong">Copy the manifest to the new host system as
described in </emphasis><olink targetptr="gdqse" remap="internal">How to Move the zonepath
to a new Host</olink><emphasis role="strong">, and perform the validation:</emphasis></para><screen>global# <userinput>zoneadm attach -n path_to_manifest</userinput></screen><para>The path can be <literal>&mdash;</literal> to specify <literal>stdin</literal>.</para>
</step>
</stepalternatives>
</step>
</procedure>
</task>
</sect1>
</chapter>