How to Script Oracle Solaris 11 Zones Creation for a Network-in-a-Box Configuration

Updated for Oracle Solaris 11.1

by Jeff McMeekin

Through this "network-in-a-box" example, learn how to efficiently create Oracle Solaris Zones by cloning them and use scripts to set up a virtual network.

Published October 2012

If you'd like to download software, participate in forums, and get access to other technical how-to goodies in addition to content like this, become an OTN member. No spam!

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.

Creating Zones, Configuring Network Interfaces, and Assigning IP Addresses

There are two basic ways to create a zone.

  • You can create a zone from scratch. Oracle Solaris 11.1 has a number of optimizations to speed this process including caching packages after one zone has been created so that subsequent zone creation goes much faster.
  • You can clone an existing zone and then, before actually using it, configure it. Cloning is the fastest way to create a zone because cloning does not require any interaction with the package repository. And, unlike when creating a zone from scratch, the initial zone booting is much faster, because the majority of Service Management Facility services have already been configured.

And, as you know if you have worked with Oracle Solaris 10 zones, there are two types of network interfaces for zones:

  • Shared-IP stack
  • Exclusive-IP stack

Shared-IP Stack Interfaces

"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).

Exclusive-IP Stack Interfaces

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:

  • You can configure a single network interface for an Oracle Solaris 11 zone using the new Oracle Solaris 11 approach for specifying all install-time system configuration settings. There is a new tool for creating a file to configure a system (to answer any configuration questions) so the system boots completely without further operator intervention. To do this, you invoke the tool as follows:

    # 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.

  • You can configure a single network interface using an approach you used to configure Oracle Solaris 10 zones so that no manual intervention was required. You would generate a 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.

  • There is no simple "assign this IP address to the interface" functionality through the 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.
  • While you can't generically assign an IP address to a zone's network interface from the global zone, there is a property called 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.

Example: Network in a Box

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

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

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.

Step 1: Create the Etherstubs

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
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 

Step 2: Create the ZFS Data Set for Storing the Oracle Solaris Zones

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 

Step 3: Create an Oracle Solaris Zone for Cloning

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

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.

Step 4: Create the First Oracle Solaris Zone for Our Example

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 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 zdb1 vdb1 dbswitch0

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.

Table 1. Before and After Versions of the sysidcfg File
Example Oracle Solaris 10 sysidcfg File After Converting for Use with js2ai
network_interface=PRIMARY {
network_interface=vdb1 {primary

Note that we did the following:

  • We removed the nfs4 response, which is not needed for Oracle Solaris 11.
  • We made a slight change to the syntax for the network_interface entry.

Important: The password for all the Oracle Solaris Zones is crossbow.

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 

Step 5: Create the Rest of the Oracle Solaris Zones

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 

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 zdb2 vdb2 dbswitch0  
# sh zdb3 vdb3 dbswitch0 

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 zrouter vdb0 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 zweb1 vweb1 webswitch0 vphys1 net0 
# sh zweb2 vweb2 webswitch0 vphys2 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 
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.

Step 6: Set Up Routing for the Oracle Solaris Zones

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> 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 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  
 vdb0/v4           static   ok  
 vweb0/web         static   ok  
 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

Figure 4. Network Virtualization Diagram Again

Use the ping or traceroute command between various zones, as follows:

  • Try to reach the vphys1 address of zweb1 from an external system on the same subnet as those addresses (129.200.1, in this example). You should succeed.
  • Try to reach one of the IP addresses on the 192.168.0 or 192.168.7 networks from an external system. You should not be successful, as explained previously. Even if you turned off allowed-address, you would still need to turn on IP forwarding, as we did when configuring the zrouter zone.
  • Try to reach one of the database zones, zdb1, zdb2, or zdb3 (,, or, respectively) from zweb1 or zweb2. Because IP forwarding is turned on for zrouter, you should be successful.
  • Try the opposite. From zdb1, zdb2, or zdb3, try to reach or Again, because of the zrouter configuration, you should succeed.

Cleaning Up

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.

See Also

Here are some additional resources:

About the Author

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:

# Create a zone with a VNIC attached to an etherstub
# Usage:
# <zone name> <VNIC> <IP address for VNIC> 
#                     <etherstub to which VNIC is attached> <default route>
if [ $# != 5 ]
    echo "Usage: <zone name> <VNIC>"
    echo "       <IP address for VNIC> <etherstub to which VNIC is attached>"
    exit 1


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


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:

# Usage:
# <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 ]
  echo "usage: <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

echo "Create zone $ZONENAME"
echo "  Interface $VNIC1, IP address $VNIC1IP on etherstub $ETHERSTUB," 
echo "  default route to $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


Listing 2: Script for Creating an Oracle Solaris Zone with Two VNICs

Listing 3 is a script used by the first two scripts:

# Create a zone with a VNIC attached to an etherstub.
# This script does most of the work for and 
# Usage:
# <zone name> <VNIC> <IP address for VNIC> <etherstub to which VNIC is attached>
#                  <default route>
if [ $# != 5 ]
  echo "Usage: <zone name> <VNIC> <IP address for VNIC>"
  echo "    <etherstub to which VNIC is attached> <default route>"
  exit 1
#  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_
network_interface=$VNIC {primary
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
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" 

Listing 3: Script Used by the First Two Scripts

Listing 4 is a script for completely removing a zone:

# Usage: <zone name> 
# This will completely remove a zone from the system
if [ $# != 1 ] 
      echo "Usage: cleanupzone <zone name>" 
      exit 1
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

Listing 4: Script for Completely Removing a Zone

Listing 5 is a script for removing all the zones:

# Usage: 
# This will completely remove all the demo zones
sh zweb1 
sh zweb2 
sh zrouter 
sh zdb1
sh zdb2
sh zdb3 
sh zclone

Listing 5: Script for Removing All the Zones

Listing 6 is a script for removing the two etherstubs:

# Usage: cleanupdladm 
# This will remove the etherstubs 
dladm delete-etherstub webswitch0 
dladm delete-etherstub dbswitch0

Listing 6: Script for Removing the Two Etherstubs

Revision 1.2, 10/22/2012

facebook banner twitter banner