P2V Migration From Solaris 10 Global Zone to Oracle Solaris 11 Local Zone (Solaris 10 Branded Zone)

The aim of this post is to describe a Physical to Virtual (P2V) migration of a Bare-Metal Solaris 10 (a Physical Node) on a Solaris 11 Global Zone (Solaris 10 Branded Zone on Oracle Solaris 11). The scenario describes below involves a Solaris 10 Physical node named oranode (hosts an Oracle Database 10G and another Oracle application) and a Solaris 11 Global Zone named sol11-gz (already hosting some other Local Zones). 

In order to make this migration easily understandable, It has been technically divided in in 03 parts, the first parts deals with Analysis of the Source System, the second is about System/Data Collection and the third is about Target Zone Configuration and Installation.

I. Analysis of the Source System

The Data Analysis phase aims to collect some initial analysis Data. Oracle has provided a very nice tool for that phase, namely zonep2vchk. zonep2vchk serves two functions. First, it can be used to report issues on the source which might prevent a successful p2v migration. Second, it can output a template zonecfg, which can be used to assist in configuring the non-global zone target (man page).

The /usr/sbin/zonep2vchk script is belonging to pkg:/system/zones on Solaris 11 and can be copied from an Oracle Solaris 11 system to an Oracle Solaris 10 system. It is not required to run this utility from a specific location on the system.

Below, we're copying this utility to our Solaris 10 (oranode) and then we're running it with the option -T S11 which specifies that the target node for our planned migration of this Solaris 10 System is running on Oracle Solaris 11.

root@s11-gz:~# scp /usr/sbin/zonep2vchk stivesso@oranode: Password: zonep2vchk 100% |*******************************| 142 KB 00:00 root@oranode # chmod ug+x /export/home/stivesso/zonep2vchk root@oranode # /export/home/stivesso/zonep2vchk -T S11 --Executing Version: 1.0.5-11-16135 - Source System: oranode Solaris Version: Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC Solaris Kernel: 5.10 Generic_147440-01 Platform: sun4u SUNW,Sun-Fire-15000 - Target System: Solaris_Version: Solaris 11 Zone Brand: solaris10 (Solaris 10 Container) IP type: exclusive --Executing basic checks - The following /etc/system tunables exist. These tunables will not function inside a zone. The /etc/system tunable may be transfered to the target global zone, but it will affect the entire system, including all zones and the global zone. If there is an alternate tunable that can be configured from within the zone, this tunable is described: forceload: drv/emcpsf No alternate tunable exists. forceload: drv/sd No alternate tunable exists. forceload: drv/ssd No alternate tunable exists. forceload: drv/emcp No alternate tunable exists. forceload: misc/emcpgpx No alternate tunable exists. forceload: misc/emcpmpx No alternate tunable exists. forceload: misc/emcpvlumd No alternate tunable exists. forceload: misc/emcpxcrypt No alternate tunable exists. forceload: misc/emcpdm No alternate tunable exists. forceload: misc/emcpioc No alternate tunable exists. set emcp:bPxEnableInit=1 zonep2vchk has no information on tunable set shmsys:shminfo_shmmax=4294967295 zonep2vchk has no information on tunable project.max-shm-memory set shmsys:shminfo_shmmin=1 Tunable is obsolete on target host set shmsys:shminfo_shmmni=100 zonep2vchk has no information on tunable project.max-shm-memory set shmsys:shminfo_shmseg=10 Tunable is obsolete on target host set semsys:seminfo_semmns=1024 Tunable is obsolete on target host set semsys:seminfo_semmsl=256 Alternate tunable exists inside a non-global zone: rctl process.max-sem-nsems set semsys:seminfo_semmni=100 Alternate tunable exists inside a non-global zone: rctl project.max-sem-ids set semsys:seminfo_semvmx=32767 Tunable is obsolete on target host set noexec_user_stack=1 zonep2vchk has no information on tunable - The following SMF services will not work in a zone: svc:/network/iscsi/initiator:default svc:/system/iscsitgt:default - The system is configured with the following non-root ZFS pools. Pools cannot be configured inside a zone, but a zone can be configured to use a pool that was set up in the global zone: swappool zpool_oracle zpool_oracle2 Basic checks compete, 25 issue(s) detected --Total issue(s) detected: 25

Quite verbose! Indeed this initial analysis give us a lot of insights for the whole p2v procedure. For example, we can see that in this study case, we have much more than 01 ZFS Zpool (beside the initial rpool). These are File-system which host the Oracle Database 10G (mentioned above) Data Files.

Thus, we must decide how these  application Data's file-systems will be migrated. The strategy we're applying here is to migrate just the Operating System (excluding the Application Data File-System), and use SAN replication for the Application Data. Note that this decision is based on the source system architecture (we may for example decide to go for a zfs send/receive if these Data file-system are not located on an external storage…).

Once done with that, we complete this analysis phase by creating a template file for the Target Zone Creation (using the same zonep2vchk tool with the option -c). This is just a template , it is used to ease the creation of the target Zone and should be adjusted to suit with the requirement of the target environment.

root@oranode # /export/home/stivesso/zonep2vchk -T S11 -c create -b set zonepath=/zones/oranode set brand=solaris10 add attr set name="zonep2vchk-info" set type=string set value="p2v of host oranode" end set ip-type=exclusive # Uncomment the following to retain original host hostid: # set hostid=94a76031 # Max procs and lwps based on max_uproc/v_proc set max-processes=20000 set max-lwps=40000 add attr set name=num-cpus set type=string set value="original system had 4 cpus" end # Only one of dedicated or capped cpu can be used. # Uncomment the following to use cpu caps: # add capped-cpu # set ncpus=4.0 # end # Uncomment the following to use dedicated cpu: # add dedicated-cpu # set ncpus=4 # end # Uncomment the following to use memory caps. # Values based on physical memory plus swap devices: # add capped-memory # set physical=16384M # set swap=119823M # end # Original ce0 interface configuration: # Statically defined oranode (oranode) # Factory assigned MAC address 0:14:4f:1e:a2:90 add anet set linkname=ce0 set lower-link=change-me # Uncomment the following to retain original link configuration: # set mac-address=0:14:4f:1e:a2:90 end # Original dman0 interface configuration: # Statically defined 192.168.1.3/27 # Factory assigned MAC address 0:0:be:a9:66:71 add anet set linkname=dman0 set lower-link=change-me # Uncomment the following to retain original link configuration: # set mac-address=0:0:be:a9:66:71 end exit

II. System/Data Collection

This phase aims to collect Source System's Data (Solaris 10 System - oranode) and transferred them to the Target System (Solaris 11 Global Zone - s11-gz). As discussed during the analysis phase, I have decided to migrate System Data and Application Data in separate processes.

For the system, I’m making use of the classic flarcreate to generate system archive (due to the presence of Data File-System that i'd like to exclude, i'm using CPIO as method to archive the file). For the Application Data, they're being migrated using External Storage Cloning features (not described here!). 

root@oranode # flarcreate -S -n oranode -x /oracle -x /zpool_oracle -x /zpool_oracle2 -L cpio /zpool_oracle/$(hostname)-$(/usr/bin/date +"%Y-%m-%d").flar Archive format requested is cpio Full Flash Checking integrity... Integrity OK. Running precreation scripts... Precreation scripts done. Creating the archive... cpio: cpio: var/adm/lastlog: too large to archive in current mode 14429359 blocks 1 error(s) Archive creation complete. Running postcreation scripts... Postcreation scripts done. Running pre-exit scripts... Pre-exit scripts done.

The transfer of this archive to the target Global Zone can be done using any conventional method (scp/sftp/ftp, SAN Replication...). Once completed, we can move to the last part.

III. Target Zone Configuration and Installation

Now that we've the Data Collection phase completed, we’re going to create the target zone and start the restoration of the flararchive that was created. We’ll also add the Zpool Dataset which were migrated using the SAN replication features.

The zone will be created using the template that was generated by the zonep2vchk tool (we'll obviously customize it to fit the target environment). Before starting, we have to create the zonepath needed for the target zone and import the zpool that was migrated through the SAN replication.

root@sol11-gz:~# zpool create zpool_oranode <local_device> root@sol11-gz:~# zfs create zpool_oranode/oranode root@sol11-gz:~# chmod 700 /zpool_oranode/oranode root@sol11-gz:~# zpool import -f zpool_oracle zpool_oranode_data

Let’s now configure our new local zone by using the template generated by zonep2vchk tool during the first phase.

root@sol11-gz:~# cat /export/zonecfg/oranode.cfg create -b set zonepath=/zpool_oranode/oranode set brand=solaris10 add attr set name="zonep2vchk-info" set type=string set value="p2v of host oranode" end set ip-type=exclusive # Uncomment the following to retain original host hostid: # set hostid=94a76031 # Max procs and lwps based on max_uproc/v_proc set max-processes=20000 set max-lwps=40000 add attr set name=num-cpus set type=string set value="original system had 4 cpus" end # Only one of dedicated or capped cpu can be used. # Uncomment the following to use cpu caps: # add capped-cpu # set ncpus=8.0 # end # Uncomment the following to use dedicated cpu: add dedicated-cpu set ncpus=8 end # Uncomment the following to use memory caps. # Values based on physical memory plus swap devices: add capped-memory set physical=16384M set swap=119823M end # Added by Steve ESSO # for the new network configuration add anet set linkname=oranode_net0 set vlan-id=10 set lower-link=net0 end add anet set linkname=oranode_net1 set vlan-id=10 set lower-link=net1 end exit root@sol11-gz:~# zonecfg -z oranode -f /export/zonecfg/oranode.cfg root@sol11-gz:~# zonecfg -z oranode zonecfg:oranode> info zonename: oranode zonepath: /zpool_oranode/oranode brand: solaris10 autoboot: false bootargs: file-mac-profile: pool: limitpriv: scheduling-class: ip-type: exclusive hostid: fs-allowed: [max-lwps: 40000] [max-processes: 20000] anet: linkname: oranode_net0 lower-link: net0 allowed-address not specified configure-allowed-address: true defrouter not specified allowed-dhcp-cids not specified link-protection: mac-nospoof mac-address: random mac-prefix not specified mac-slot not specified vlan-id: 10 priority not specified rxrings not specified txrings not specified mtu not specified maxbw not specified rxfanout not specified anet: linkname: oranode_net1 lower-link: net1 allowed-address not specified configure-allowed-address: true defrouter not specified allowed-dhcp-cids not specified link-protection: mac-nospoof mac-address: random mac-prefix not specified mac-slot not specified vlan-id: 10 priority not specified rxrings not specified txrings not specified mtu not specified maxbw not specified rxfanout not specified dedicated-cpu: ncpus: 8 capped-memory: physical: 16G [swap: 117G] attr: name: zonep2vchk-info type: string value: "p2v of host oranode" attr: name: num-cpus type: string value: "original system had 4 cpus" rctl: name: zone.max-processes value: (priv=privileged,limit=20000,action=deny) rctl: name: zone.max-lwps value: (priv=privileged,limit=40000,action=deny) rctl: name: zone.max-swap value: (priv=privileged,limit=125643522048,action=deny)

Having the configuration done, we can start the zone Installation

root@sol11-gz:~# zoneadm -z oranode install -p -a /zpool_oranode_data/oranode-25nov2013.flar root@sol11-gz:~# zoneadm -z oranode install -p -a /zpool_oranode_data/oranode-25nov2013.flar Progress being logged to /var/log/zones/zoneadm.20131126T212904Z.oranode.install Installing: This may take several minutes... Postprocessing: This may take a while... Postprocess: Updating the image to run within a zone Postprocess: Migrating data from: zpool_oranode/oranode/rpool/ROOT/zbe-0 to: zpool_oranode/oranode/rpool/export Postprocess: A backup copy of /export is stored at /export.backup.20131126T213800Z. It can be deleted after verifying it was migrated correctly. Postprocess: Migrating data from: zpool_oranode/oranode/rpool/ROOT/zbe-0 to: zpool_oranode/oranode/rpool Postprocess: A backup copy of /rpool is stored at /rpool.backup.20131126T213856Z. It can be deleted after verifying it was migrated correctly. Result: Installation completed successfully. Log saved in non-global zone as /zpool_oranode/oranode/root/var/log/zones/zoneadm.20131126T212904Z.oranode.install

Finally, We are adding the ZFS dataset migrated through SAN Replication,

root@sol11-gz:~# zonecfg -z oranode zonecfg:oranode> add dataset zonecfg:oranode:dataset> set name=zpool_oranode_data zonecfg:oranode:dataset> set alias=zpool_oranode_data zonecfg:oranode:dataset> end zonecfg:oranode> commit zonecfg:oranode> exit

And the big moment! Boot the new zone...

root@sol11-gz:~# zoneadm -z oranode boot root@sol11-gz:~# zlogin -C oranode