Articles
Server and Storage Administration
by Jeff McMeekin
Published October 2012
|
This article explains how to script the creation of Oracle Solaris Zones with an emphasis on network configuration. It covers how to most efficiently create Oracle Solaris Zones, which is through cloning them, and how to configure networking interfaces for maximum flexibility so the Oracle Solaris Zones can be migrated between systems.
Before starting the example, we need to review the ways we can create zones, create interfaces, and assign IP addresses, plus discuss why we are choosing the particular methods that we use in the example.
There are two basic ways to create a zone.
And, as you know if you have worked with Oracle Solaris 10 zones, there are two types of network interfaces for zones:
"Shared" was initially the only choice and it is the default for Oracle Solaris 10. It has both advantages and disadvantages. The advantages are that it can be completely configured from the global zone. Among the disadvantages are that its network stack is indeed shared by other connections. This means it is possible to snoop other IP traffic using the shared stack. Also, a dedicated hardware interface is required for each shared-IP stack.
Programmatically, creating a shared-IP stack address is simple. You simply need to script the zonecfg commands to run in the global zone, which will create the interface and then assign an IP address. From a scripting standpoint, this is quite straightforward.
We won't be using this approach in this article, because the power of Oracle Solaris 11 is that you can create virtual NICs (VNICs), and they work only with exclusive-IP stacks. In a real-world deployment, VNICs give you far more flexibility, because there is no one-to-one relationship of VNIC to physical NIC. Also, the exclusive-IP stack interface approach has a very strong similarity to a physical link stack.
Keeping the architectural model the same for VNICs as for physical NICs means that application developers don't have to think about any new set of issues. And the application doesn't have to worry about whether it is on a physical NIC or a VNIC—things work the same on both, the security model is the same, and the commands used to operate on the interfaces are the same (although there are some additional commands due to additional capabilities of VNICs).
There are several ways to programmatically configure a network interface on Oracle Solaris 11 using the (now) default exclusive-IP stack approach. Here are the options:
# sysconfig create-profile -o sc_profile.xml
This command presents the same configuration screens an operator would see when installing a new system. The tool records all the operator's responses and saves the selections in the sc_profile.xml file.
To script a solution that can be used to create a variety of configured zones, you could then edit the sc_profile.xml file to replace specific settings with a character string that is easily identified (for example, $$IP_ADDRESS$$) and then use a script that would substitute the actual IP address for that string. Your script would take as input all the values you want to specify at zone configuration time, and then do the substitution so that sc_profile.xml is a valid configuration file.
For more complex configuration issues, for example, creating additional users at configuration time, this is the best approach.
You can find information and examples for sc_profile.xml in the "Configuring the Client System" section of Installing Oracle Solaris 11.1 Systems.
In Step 4 below, we will describe how to apply the sc_profile.xml file to configure a zone.
sysidcfg file, just as for Oracle Solaris 10, although with some minor differences. Then, when you are done, you would run that through the new Oracle Solaris 11 js2ai(1M) tool and follow the process in Step 4 below.We will use this approach for this article, because writing a script to operate on a simple ASCII file of configuration settings, one configuration to a line, is easy. See Step 4 below for more information about the format of the sysidcfg file.
The only drawback to either of these first two approaches is that you can create only one network interface through this mechanism. This drawback is planned to be addressed in a subsequent release of Oracle Solaris 11.
zonecfg command running in the global zone for exclusive zones. The way you create and configure an interface is to log in to the zone and configure the interface using ipadm(1M). Configuring a network interface in a zone is very straightforward, but it gets more complicated using a scripting approach, because your overall script running in the global zone will have to copy another script into the zone to configure that zone's network interface. Typically, you would copy the script to configure the zone's network interface via scp(1), the ssh(1) copy utility.allowed-address that will set the interface IP address if you supply only one address for that property. There is a limitation with this approach, though. The allowed-address setting means that no packet with a source address not matching the setting will be allowed through the interface. This means that you cannot route traffic through this. For the following example, we will require a router zone, and we will have to use the ipadm approach for setting the IP address for the second interface.In the following example, we will use the last three approaches.
Oracle Solaris 11 provides new networking features for network virtualization. Network virtualization takes server virtualization to the next level by providing the ability to virtualize entire network topologies of servers, routers, switches, and firewalls all running on a single platform and requiring no additional investment in networking hardware. Network virtualization can be used for a variety of purposes, from prototyping, to developing and testing, to service deployment. In the following example, we will walk through creating an entire network topology that will run in a single system.
Figure 1 shows an example of a multitiered application. In this example, there are two Web servers running on dedicated systems that are exposed to the external network, and there are several database servers running on dedicated systems that are not directly connected to the external network.

Figure 1. Network to Be Virtualized on a Single Server
A good place to start the process of configuring this physical scenario on a single Oracle Solaris 11 system, would be to name all the entities that we must configure. So we will redraw the diagram as a virtual scenario, as shown in Figure 2, with an emphasis on all the component and interface names and, where appropriate, IP addresses.

Figure 2. Converting from a Physical Topology to a Virtual Network-in-a-Box Topology
The Web servers share a back-end etherstub called webswitch0 in the Figure 2. Technically, an etherstub is not a virtual switch, but effectively it allows a switch to be created. So labeling an etherstub as a switch makes the diagram clear without adding extra details.
The database servers also share a back-end etherstub, labeled dbswitch0. The network will be configured so the database servers running in dedicated Oracle Solaris Zones (zdb1, zdb2, and zdb3) have no direct access to the physical network, which securely insulates them from outside communications.
The single physical interface is represented in this example as net0. For the vphys1 and vphys2 VNIC addresses, you should use addresses that are known outside the vphys subnet (129.200.9) if you are actually going to install a Web server in the zweb1 and zweb2 zones.
In this step, we create the two etherstubs that are used to enable communication between the database zones and between the Web server zones shown in Figure 2. Let's start by looking at the physical network:
# dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE net0 Ethernet up 1000 full bge0
For this system, there is only one physical interface, bge0. Note that the link name is net0. By default, Oracle Solaris 11 creates a link named net0 for the first physical interface, one named net1 for the second physical interface, and so on. This is a useful simplification because we no longer have to worry about the actual physical NIC hardware and the link names for various hardware platforms. When we want to configure anything to do with this physical interface, we will use net0.
We start by creating two etherstubs that will enable the virtual switching to occur to match our diagrammed architecture:
# dladm create-etherstub webswitch0 # dladm create-etherstub dbswitch0
In Oracle Solaris 11, each Oracle Solaris Zone comes with a VNIC already enabled, that is, another net0. For the purposes of this example, we name the VNICs in Figure 2 to reflect their place in the overall architecture. So rather than label all the interfaces in the diagram net0, net1, and so on, we use more descriptive names, such as vdb1, vdb2, and so on.
There is a larger issue here: whether or not to define the VNICs in the global zone. In Oracle Solaris 11 Express, you had to define all the VNICs from the global zone. In this case, there are nine VNICs, so there would be nine dladm create-vnic statements.
However, with an emphasis on building for dynamic environments in which Oracle Solaris Zones can be migrated between systems, a much better approach to VNIC creation is to create the VNICs used by a zone in that zone. When the zone goes away, the VNICs go away. Even more important, when the zone is migrated to another system, the zone carries the information about the interfaces it expects.
In our example, the global zone does need to provide some things, for example, the etherstubs are defined in the global zone. But the rest of the networking configuration is dynamic because the configuration is carried within the individual non-global zones, not the global zone.
After configuring all the etherstubs, check the setup:
# dladm show-etherstub -Z LINK ZONE dbswitch0 global webswitch0 global
We are going to create a single Oracle Solaris Zone and then, to reduce the time to create additional ones, we will clone the first to make the zones needed for our example. Cloned zones require sharing a ZFS data set, so creating the data set is the first step:
# zfs create -o mountpoint=/zonefs rpool/zonefs # chmod 700 /zonefs
As mentioned earlier, it is much faster to clone an Oracle Solaris Zone than to create one from scratch, because building an image from packages takes longer than, in essence, copying an existing zone. We will use the cloning technique in this example to first create one Oracle Solaris Zone and then clone it six times.
First, configure the Oracle Solaris Zone we will clone, zclone, as follows:
# zonecfg -z zclone zclone: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:zclone> create create: Using system default template 'SYSdefault' zonecfg:zclone> set zonepath=/zonefs/zclone zonecfg:zclone> set ip-type=exclusive zonecfg:zclone> exit
The default setting for ip-type for Oracle Solaris 11 is exclusive so we did not actually have to specify it.
Now install zclone:
# zoneadm -z zclone install
A ZFS file system has been created for this zone.
Progress being logged to /var/log/zones/zoneadm.20111007T223740Z.zclone.install
.
.
.
Done: Installation completed in 407.653 seconds.
Next Steps: Boot the zone, then log into the zone console
(zlogin -C) to complete the configuration process.
Note: Install times vary depending on the network and the Image Packaging System (IPS) repository.
Now boot zclone:
# zoneadm -z zclone boot; zlogin -C zclone [Connected to zone 'zclone' console] Loading smf(5) service descriptions: 112/112
We put the zlogin command on the same line as the boot command so that the zlogin command will be immediately executed and you will see the zclone zone boot, including the initial configuration of the Service Management Facility (SMF) services. You want this step to complete so that when you clone this zone, you won't have to wait for each new zone to configure all the SMF services.
The output should eventually disappear and be replaced by the initial screen of the System Configuration Tool (see Figure 3), where you can do the final configuration.
|
Important: Do not use the tool. At this point, we won't do further configuration, so escape to the global zone using ~. (press the tilde key followed by the period key). |

Figure 3. System Configuration Tool
Then halt zclone:
# zoneadm -z zclone halt
To review, we created an Oracle Solaris Zone, zclone, which has gone through the initial install and first boot, and we configured the SMF services. At that point, we stopped the process, because we don't want to further configure zclone.
As you will see, creating zclone will save us the time associated with initially provisioning a zone and much of the time for the first boot. All we will need to do to use zclone is to base a new Oracle Solaris Zone on it and then give the new zone its network identity and other configuration information through a scripted process instead of a manual process.
In Figure 2, we see six Oracle Solaris Zones. To simplify the typing, the approach we will take is to walk through setting up one Oracle Solaris Zone as an example and then use some scripts that are provided in the Appendix to automate the process for the others.
If you would rather not type in all the commands for creating the first Oracle Solaris Zone, you can read about the commands below but actually use the createzone-1vnic.sh script in the Appendix to do the work. This approach avoids the inevitable typing mistakes that result from entering many commands. See Step 5 for more information about extracting and using the scripts.
|
Note: If you elect to avoid typing in the commands for the first Oracle Solaris Zone, invoke the script as follows: # sh createzone-1vnic.sh zdb1 vdb1 192.168.7.1 dbswitch0 192.168.7.254 If you use the script, you should still go through the rest of this section to understand what has been done. |
We are going to first create one of the Oracle Solaris Zones that will contain a database in our example network, zdb1. We aren't actually going to provision the zone with a database server, however, since this example is only about setting up the networking infrastructure.
As mentioned in the "Creating Zones, Configuring Network Interfaces, and Assigning IP Addresses" section, one way to configure a network interface is to do it via the standard initial boot configuration process that allows substituting a file of settings rather than manually going through each configuration screen. For the sake of simplicity, we are using the Oracle Solaris 10 approach; in other words, we will have our script create the sysidcfg file in a manner that is very similar, but not exactly identical, to the Oracle Solaris 10 version.
Unlike for Oracle Solaris 10, this approach can be used to configure only a single network interface. Later, we will see an alternate approach for creating a network interface using the anet subcommand of zonecfg(1).
On the left column of Table 1 is the sysidcfg file we might have used for Oracle Solaris 10 to configure an Oracle Solaris Zone. However, before we can use the js2ai utility to convert it to sc_profile.xml, we have to make a few modifications to the sysidcfg file. The right column of Table 1 shows the sysidcfg file after we remove the lines that are not supported and we slightly alter the syntax.
sysidcfg File
Example Oracle Solaris 10 sysidcfg File |
After Converting for Use with js2ai |
|---|---|
terminal=vt100
system_locale=C
timezone=US/Pacific
nfs4_domain=dynamic
security_policy=NONE
root_password=rJmv5LUXM1OcU
network_interface=PRIMARY {
hostname=zdb1
ip_address=192.168.7.1
netmask=255.255.255.0
protocol_ipv6=no
default_route=192.168.7.254
}
name_service=NONE
|
terminal=vt100
system_locale=C
timezone=US/Pacific
security_policy=NONE
root_password=rJmv5LUXM1OcU
network_interface=vdb1 {primary
hostname=zdb1
ip_address=192.168.7.1
netmask=255.255.255.0
protocol_ipv6=no
default_route=192.168.7.254
}
name_service=NONE
|
Note that we did the following:
nfs4 response, which is not needed for Oracle Solaris 11.network_interface entry.|
Important: The password for all the Oracle Solaris Zones is |
This password was created by creating a user with password crossbow on an Oracle Solaris 10 system and then copying the encrypted password from /etc/shadow to the root_password setting in the sysidcfg file. An Oracle Solaris 11 encrypted password could also have been used.
Change to the /tmp directory:
# cd /tmp
Then, using your favorite editor, create the sysidcfg file by copying all the sysidcfg settings shown in the right column of Table 1 (starting with the terminal=vt100 line) and pasting them into the new sysidcfg file.
Then execute the js2ai command, which will convert sysidcfg to the sc_profile.xml file:
# js2ai -s
By default, the command will look for the sysidcfg file in the current directory, and it will output sc_profile.xml to the current directory. The sc_profile.xml file is the Oracle Solaris 11 file for storing configuration settings prior to applying them to a system or zone.
You might find it interesting to look at the sc_profile.xml that was created.
Next, we create the zdb1 zone from the zclone zone:
# zonecfg -z zdb1 "create -t zclone"
Then we designate where to set up the zone files and add the VNIC, vdb1.
# zonecfg -z zdb1 "set zonepath=/zonefs/zdb1" # zonecfg -z zdb1 "select anet linkname=net0; set linkname=vdb1; set lower-link=dbswitch0; end"
The last command above essentially says "select the automatically created VNIC, net0, and first change its name to vdb1; then associate it through the lower-link property to the etherstub dbswitch0." In other words, make the configuration match Figure 2.
Now it is time to apply the /tmp/sc_profile.xml configuration file created previously, to the new zdb1 zone:
# zoneadm -z zdb1 clone -c /tmp/sc_profile.xml zclone
Then boot the zdb1 zone and check that it is running:
# zoneadm -z zdb1 boot
# zoneadm list --cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
78 zdb1 running /zonefs/zdb1 solaris excl
- zclone installed /zonefs/zclone solaris excl
As you can see from Step 4, generating the configuration takes a fair amount of typing. The Appendix provides scripts to simplify creating (and cleaning up) Oracle Solaris Zones. You should copy and paste those scripts into the appropriate file names (shown in each script). See the Appendix for more instructions.
If you put the scripts in /opt/crossbowhowto/scripts, you can see them all using the following commands:
# cd /opt/crossbowhowto/scripts # ls cleanupallzones.sh cleanupzone.sh createzone-2vnic.sh cleanupdladm.sh createzone-1vnic.sh new-zone-vnic.sh
You already created zdb1 database zone in Step 4, so now create the other two database zones, zdb2 and zdb3. See the Appendix for an explanation of the arguments.
# sh createzone-1vnic.sh zdb2 vdb2 192.168.7.2 dbswitch0 192.168.7.254 # sh createzone-1vnic.sh zdb3 vdb3 192.168.7.3 dbswitch0 192.168.7.254
Next, we need to create an Oracle Solaris Zone for the router, zrouter. To keep the example simple, we are going to use the default Oracle Solaris router for handling routing tasks. If the routing were more complex or we wanted to use other routing protocols, we could use the open source Quagga project, which can be found in the Oracle Solaris 11 package repository. See quagga(8).
Note that the zrouter zone has two VNICs, but we are going to use the script that creates only one VNIC. Create the zrouter zone and one of its interfaces now using the following command. Later, we will configure the second interface and the routing.
# sh createzone-1vnic.sh zrouter vdb0 192.168.7.254 dbswitch0 NONE
And finally, create the two zones in which the Web servers would be run: zweb1 and zweb2. You will need to replace the 129.200.9 addresses in the following commands with addresses on your subnet, since the vphys1 and vphys2 addresses are seen by external systems.
# sh createzone-2vnics.sh zweb1 vweb1 192.168.0.1 webswitch0 192.168.0.254 vphys1 129.200.9.1 net0 # sh createzone-2vnics.sh zweb2 vweb2 192.168.0.2 webswitch0 192.168.0.254 vphys2 129.200.9.2 net0
Note: We won't actually install a Web server, but the article "How to Get Started Creating Oracle Solaris Zones in Oracle Solaris 11" shows how to install the Apache Web server. And then the server is easy to turn on using svcadm.
Returning to our example, verify the setup:
# zoneadm list --cv ID NAME STATUS PATH BRAND IP 0 global running / solaris shared 78 zdb1 running /zonefs/zdb1 solaris excl 81 zdb2 running /zonefs/zdb2 solaris excl 82 zdb3 running /zonefs/zdb3 solaris excl 83 zrouter running /zonefs/zrouter solaris excl 84 zweb1 running /zonefs/zweb1 solaris excl 85 zweb2 running /zonefs/zweb2 solaris excl - zclone installed /zonefs/zclone solaris excl
Another useful check is to show all the VNICs that are using an etherstub. First, we will look at what VNICs are assigned to dbswitch0:
# dladm show-vnic -l dbswitch0 LINK OVER SPEED MACADDRESS MACADDRTYPE VID zrouter/vdb0 dbswitch0 0 2:8:20:c2:d5:7 random 0 zdb1/vdb1 dbswitch0 0 2:8:20:c6:31:48 random 0 zdb2/vdb2 dbswitch0 0 2:8:20:79:62:95 random 0 zdb3/vdb3 dbswitch0 0 2:8:20:46:b1:c6 random 0
You could also check webswitch0, but since you haven't configured the second interface for zrouter, you won't see all the components of the webswitch0 etherstub.
We can now finish configuring zrouter, which should route packets between the Web server zones, zweb1 and zweb2, and the three database zones, zdb1, zdb2, and zdb3. The issue here is that if we use the script for creating two VNICs, the second one is created via the allowed-address property, and that means the VNIC will transmit packets only with that address. But we need it to forward packets to fulfill the routing function. So we are going to manually create the second interface without using the allowed-address property, as follows.
First, do the following from the global zone to create the vweb0 VNIC that sits on the webswitch0 etherstub.
# zonecfg -z zrouter zonecfg:zrouter> add anet zonecfg:zrouter:anet> zonecfg:zrouter:anet> set linkname=vweb0 zonecfg:zrouter:anet> set lower-link=webswitch0 zonecfg:zrouter:anet> end zonecfg:zrouter> exit
Next, reboot the zrouter zone and log back in.
Log in to an Oracle Solaris Zone the first time using the -C flag. This will invoke the configuration tool to prompt you for input. You provided configuration information prior to booting through the sysidcfg file, so you shouldn't be prompted. But if you made any changes to the sysidcfg or sc_profile.xml file contents, that might trigger a prompt. That would imply you need to tweak your script to make sure you are not prompted for any information when booting.
If you don't see the following login prompt, press the Enter key.
# zlogin -C zrouter [Connected to zone 'zrouter' console] root@zrouter:~# reboot zweb1 console login: root Password: crossbow
We now have to specify the IP address for the zrouter zone. As mentioned, we can't use the approach we used before, because assigning an IP address through allowed-address is too restrictive. And we can't use the sc_profile.xml approach, since we can create one only interface with that file. Those are the only two ways we can assign an IP address to an exclusive stack zone from the global zone, so the third approach is to log in to the zone directly and configure the IP address.
root@zrouter: ipadm create-ip vweb0 root@zrouter: ipadm create-addr -T static -a 192.168.0.254/24 vweb0/web
The final manual configuration is to enable forwarding packets. Before enabling them, you might find it interesting to log in to zdb1 and try to ping all other VNICs. You will be able to ping vdb2 and vdb3, as well as the router interfaces, vdb0 and vweb0. After you enable packet forwarding in the zrouter zone, you will be able to ping vweb1 from zdb1 and vice versa.
However, you will not be able to ping vphys1 or vphys2, because both were created via the allowed-address property. So packets won't be forwarded across. In this case, since we did not want the database zones to have access to the external network, and vice versa, we are getting the desired result.
To turn on IP forwarding in the zrouter zone, do the following:
root@zrouter: ipadm set-prop -p forwarding=on ipv4
After setting this, check the addresses assigned for both interfaces:
root@zrouter: ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 vdb0/v4 static ok 192.168.7.254/24 vweb0/web static ok 192.168.0.254/24 lo0/v6 static ok ::1/128
Use ~. to escape to the global zone.
You can now try various experiments while referring to Figure 4.

Figure 4. Network Virtualization Diagram Again
Use the ping or traceroute command between various zones, as follows:
vphys1 address of zweb1 from an external system on the same subnet as those addresses (129.200.1, in this example). You should succeed.allowed-address, you would still need to turn on IP forwarding, as we did when configuring the zrouter zone.zdb1, zdb2, or zdb3 (192.168.7.1, 192.168.7.2, or 192.168.7.3, respectively) from zweb1 or zweb2. Because IP forwarding is turned on for zrouter, you should be successful.zdb1, zdb2, or zdb3, try to reach 192.168.0.1 or 192.168.7.2. Again, because of the zrouter configuration, you should succeed.See the Appendix for three scripts that can be used to clean up (remove) the zones and the VNICs and restore the system to its original state.
We hope this step-by-step guide will give you some ideas for future experimentation. With Oracle Solaris 11 capabilities, you can easily set up fairly complex environments. And using additional facilities not discussed here but available through the Oracle Solaris 11 repository, such as the IP Filter firewall, the quagga routing package, and a new load balancer, you can address very complex networking requirements.
Here are some additional resources:
Jeff McMeekin is the last of a long line of Oracle Solaris 10 product managers and also dabbles in Oracle Solaris 11 as part of an earlier stint as OpenSolaris product manager.
This section provides six scripts. The recommendation is to copy their contents and paste that into the suggested file names using gedit to create the files on Oracle Solaris 11.
Listing 1 is a script for creating an Oracle Solaris Zone with one VNIC:
#!/bin/sh
#
# FILENAME: createzone-1vnic.sh
# Create a zone with a VNIC attached to an etherstub
# Usage:
# createzone-1vnic.sh <zone name> <VNIC> <IP address for VNIC>
# <etherstub to which VNIC is attached> <default route>
if [ $# != 5 ]
then
echo "Usage: createzone-1vnic.sh <zone name> <VNIC>"
echo " <IP address for VNIC> <etherstub to which VNIC is attached>"
exit 1
fi
ZONENAME=$1
sh new-zone-vnic.sh $ZONENAME $2 $3 $4 $5
# Now create the new zone from the clone and apply the config file
zoneadm -z $ZONENAME clone -c /tmp/sc_profile.xml zclone
zoneadm -z $ZONENAME boot
#END FILE createzone-1vnic.sh
Listing 1: Script for Creating an Oracle Solaris Zone with One VNIC
Listing 2 is a script for creating an Oracle Solaris Zone with two VNICs:
#!/bin/sh # # FILENAME: createzone-2vnics.sh # # Usage: # create2zones.sh <zone name> <vnic1> <IP address for vnic1> # <etherstub for vnic1> <default route> <vnic2> # <IP address for vnic2> <physical VNIC to associate with vnic2> if [ $# != 8 ] then echo "usage: createzone-2vnics.sh <zone name> <vnic1> <IP address for vnic1>" echo " <etherstub for vnic1> <vnic2> <IP address for vnic2>" echo " <physical VNIC or etherstub to associate with vnic2>" exit 1 fi ZONENAME=$1 VNIC1=$2 VNIC1IP=$3 ETHERSTUB=$4 DEF_ROUTE=$5 VNIC2=$6 VNIC2IP=$7 PHYSNIC=$8 echo "Create zone $ZONENAME" echo " Interface $VNIC1, IP address $VNIC1IP on etherstub $ETHERSTUB," echo " default route to $DEF_ROUTE" sh new-zone-vnic.sh $ZONENAME $VNIC1 $VNIC1IP $ETHERSTUB $DEF_ROUTE echo " Interface $VNIC2, IP address $VNIC2IP on physical NIC $PHYSNIC" zonecfg -z $ZONENAME "add anet; set linkname=$VNIC2; set lower-link=$PHYSNIC; set allowed-address=$VNIC2IP; end" # Now create the new zone from the clone and apply the config file zoneadm -z $ZONENAME clone -c /tmp/sc_profile.xml zclone zoneadm -z $ZONENAME boot # END FILE createzone-2vnics.sh
Listing 2: Script for Creating an Oracle Solaris Zone with Two VNICs
Listing 3 is a script used by the first two scripts:
#!/bin/sh
#
# FILENAME: new-zone-vnic.sh
# Create a zone with a VNIC attached to an etherstub.
# This script does most of the work for createzone-1vnic.sh and
# createzone-2vnics.sh
# Usage:
# new-zone-vnic.sh <zone name> <VNIC> <IP address for VNIC> <etherstub to which VNIC is attached>
# <default route>
if [ $# != 5 ]
then
echo "Usage: createzone-1vnic.sh <zone name> <VNIC> <IP address for VNIC>"
echo " <etherstub to which VNIC is attached> <default route>"
exit 1
fi
ZONENAME=$1
VNIC=$2
VNICIP=$3
ETHERSTUB=$4
DEF_ROUTE=$5
# We are using the Oracle Solaris 10 sysidcfg file to organize
# all the config information for a zone, and then convert to Oracle
# Solaris 11 format via the js2ai utility.
# Note that you cannot generate a root password under Oracle Solaris 11
# and use that encrypted string for the root_password property
# of the sysidcfg file (since sysidcfg is an Oracle Solaris 10 feature
# not an Oracle Solaris 11 one). The recommended approach is to
# generate a password on an Oracle Solaris 10 system and grab it
# from the /etc/shadow file.
cat > /tmp/sysidcfg << _EOF_
system_locale=C
timezone=US/Pacific
security_policy=NONE
root_password=rJmv5LUXM1OcU
network_interface=$VNIC {primary
hostname=$ZONENAME
ip_address=$VNICIP
netmask=255.255.255.0
protocol_ipv6=no
default_route=$DEF_ROUTE
}
name_service=NONE
_EOF_
cd /tmp
# Convert the sysidcfg file to sc_profile.xml
js2ai -s
if [ $? != 0 ]
then echo "Error converting sysidcfg file, see js2ai.log";exit 1
fi
zonecfg -z $ZONENAME "create -t zclone"
zonecfg -z $ZONENAME "set zonepath=/zonefs/$ZONENAME"
zonecfg -z $ZONENAME "select anet linkname=net0;
set linkname=$VNIC; set lower-link=$ETHERSTUB; end"
#END FILE new-zone-vnic.sh
Listing 3: Script Used by the First Two Scripts
Listing 4 is a script for completely removing a zone:
#!/bin/sh
#
# FILENAME: cleanupzone.sh
#
# Usage: cleanupzone.sh <zone name>
#
# This will completely remove a zone from the system
#
if [ $# != 1 ]
then
echo "Usage: cleanupzone <zone name>"
exit 1
fi
echo 'zoneadm -z '$1' halt'
zoneadm -z $1 halt
echo 'zoneadm -z '$1' uninstall -F'
zoneadm -z $1 uninstall -F
echo 'zonecfg -z '$1' delete -F'
zonecfg -z $1 delete -F
#
# END FILE cleanupzone.sh
Listing 4: Script for Completely Removing a Zone
Listing 5 is a script for removing all the zones:
#!/bin/sh # # FILENAME: cleanupallzones.sh # Usage: cleanupallzones.sh # # This will completely remove all the demo zones sh cleanupzone.sh zweb1 sh cleanupzone.sh zweb2 sh cleanupzone.sh zrouter sh cleanupzone.sh zdb1 sh cleanupzone.sh zdb2 sh cleanupzone.sh zdb3 sh cleanupzone.sh zclone # # END FILE cleanupallzones.sh
Listing 5: Script for Removing All the Zones
Listing 6 is a script for removing the two etherstubs:
#!/bin/sh # # FILENAME: cleanupdladm.sh # # Usage: cleanupdladm # # This will remove the etherstubs # dladm delete-etherstub webswitch0 dladm delete-etherstub dbswitch0 # # END FILE cleanupdladm.sh
Listing 6: Script for Removing the Two Etherstubs
| Revision 1.2, 10/22/2012 |