Print-friendly Version

Migrating Non-Global Zones in the Solaris 10 OS

Sudhakar Ramakrishnan, December 2008

This document explains the process of migrating Solaris non-global zones from an old LUN to a new LUN. The target audience is system administrators for the Solaris Operating System and storage administrators.

This article covers the following topics:

• Overview
• Migration Theory
• Prerequisites
• Migration Procedure
• References

Overview

Migration is the process of moving a zone from a disk to another. The need to move a zone might arise for any of the following reasons:

• More disk space needs to be provided to the zone because of high data growth.
• Modifications in data read/write speed will allow the zone to be moved to a higher-tier or lower-tier LUN.
• You are adding a new file system to an existing zone.
• You are adding new applications to an existing zone.

This document is focused only on the following zone architectures:

• Zone root file systems mounted on a metadevice
• Zone application file systems mounted on a separate metadevice with dedicated space

Migration Theory

Migration happens in two phases:

• Migrating the application file system
• Migrating the root file system

Migration be visualized as shown in Figure 1.

Figure 1: Diagram of Migration Process

In Figure 1, before migration, the root and application file systems reside on a metadevice, and in the new LUN, a metaset is used to accommodate the file systems. Metasets provide the following advantages:

• More than one LUN can be included in the set to accommodate data growth.
• A file system can be created on soft partitions that can be logically spread out on different LUNs.
• If a new file system or application needs to be added to the zone, it can be done just by adding new LUNs to the metaset and creating the required number of soft partitions.

Prerequisites

Before you start the zone migration process, capture the output of the following commands. The output would be helpful in a backout plan.

df -kh (For both global and non-global zones)

metaset
metaset -s SetName -p
metastat
format
metastat -p
luxadm probe

Also capture the output of the following commands for Veritas Volume Manager:

vxdisk list
vxprint -g <diskgroup> -hmQqs
vxdg list

If any of the file systems from the zone are shared as NFS file systems, unshare them before the migration to prevent the file systems from being locked at the target.

Migration Procedure

Follow these steps to perform the migration process:

1. Create a metaset:

metaset -s s10-12 -a -h <HostName>

2. Add the new LUN to the metaset:

metaset -s s10-12 -a /dev/rdsk/<NewLUN>

3. Create a RAID-0 (stripe) volume on the new LUN:

metainit -s s10-12 d300 1 1 /dev/rdsk/<NewLUN>

d300 is the RAID-0 volume name.

4. Enable the metaset; then the volume is ready to be used by soft partitions.

metaset -s s10-12 -A enable

5. Create the required number of soft partitions with the required space.

The number of soft partitions equals the number of zone root file systems plus the number of zone application file systems.

metainit -s s10-12 d200 -p d300 4gb
metainit -s s10-12 d201 -p d300 50gb

Initialize the soft partitions with the required storage space that has to be allocated.

6. Create new directories for the zone root and application file systems:

mkdir /zones/TestZone_new
mkdir /zones/TestZone/root/app_new

7. Create a new file system on all new soft partitions:

newfs /dev/md/s10-12/rdsk/d200
newfs /dev/md/s10-12/rdsk/d201

8. Mount the soft partition /dev/md/s10-12/dsk/200 to the respective mount point, /zones/TestZone_new:

mount /dev/md/s10-12/rdsk/d200 /zones/TestZone_new

9. Similarly, mount the application file system, /dev/md/s10-12/dsk/201, on /zones/TestZone/root/app_new:

mount /dev/md/s10-12/rdsk/d201 /zones/TestZone/root/app_new

Now, you can see the mountpoint /dev/md/s10-12/rdsk/d200 in df -k from the global zone, whereas /dev/md/s10-12/rdsk/d201 is visible in df -k under the zone.

The new file systems are ready to be synchronized with the zone file systems that are in use now. Synchronization happens in two steps:

• During first-level synchronization, you sync up the application file system while the zone is up and running
• During the final synchronization, after halting the zone with approval, you sync up the zone root file system.

10. Do the first-level sync:

/usr/local/bin/rsync -av -e /usr/local/bin/ssh \
/zones/TestZone/root/app/ /zones/TestZone/root/app_new

Verify both the application file system sizes. In this example, app_new might differ in size from app, but not by more than few megabytes.

11. Confirm that all the applications and databases running on the zone are shut down, and then halt the zone.

12. Do the final sync:

/usr/local/bin/rsync -av -e /usr/local/bin/ssh \
/zones/TestZone/ /zones/TestZone_new

Note: A forward slash (/) must be appended at the end of the source file system while synchronizing.

13. Unmount both the zone root file systems.

umount /zones/TestZone
umount /zones/TestZone_new

14. Make a backup of the zone configuration file (TestZone.xml):

cd /etc/zones
cp TestZone.xml /export/home/User/ TestZone.xml.bakup

15. Replace the raw and block device of the old application file system with the new application file system in the zone configuration file (/etc/zones/TestZone.xml):

a. Edit the /app file system device information:

vi TestZone.xml

b. Change the information from this:

<filesystem special="/dev/md/dsk/d101"
raw="/dev/md/rdsk/d101" directory="/app" type="ufs">

To this:

<filesystem special="/dev/md/s10-12/dsk/d201"
raw="/dev/md/s10-12/rdsk/d201" directory="/app" type="ufs">

16. Cross mount the zone root file system, that is, mount the new zone root file system (/dev/md/s10-12/dsk/200) in /zones/TestZone. Note that previously it was mounted under /zones/TestZone_new.

mount /dev/md/s10-12/rdsk/d200 /zones/TestZone

Now, we have the new file system for the zone root.

We have already defined in the zone configuration file that /dev/md/s10-12/rdsk/d201 should be mounted in /app. So, now the zone has a new file system for both the root and application file systems.

17. Boot up the zone, log in, and verify the file system:

Zoneadm -z TestZone boot

18. Edit the vfstab file and modify the entries as follows:

Change this:

/dev/md/s10-12/dsk/d301 /dev/md/s10-12/rdsk/d301 /TestZone
ufs 2 yes -

To this:

/dev/md/s10-12/dsk/d200 /dev/md/s10-12/rdsk/d200 / TestZone
ufs 2 yes -

19. Start up and verify the status of the applications and databases.

References

• Solaris Volume Manager Administration Guide, which is a reference for Logical Volume Manager operations and provides information on metadevices, metasets, soft partitions, and RAID volumes

• Zones section of the System Administration Guide: Solaris Containers-Resource Management and Solaris Zones, which is a reference for zone concepts and provides information for non-global zone operations, such as modifying zone configuration and halting or booting zones

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.