Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

OpenIndiana supports several methods of virtualization:

  • Operating system-level virtualization with local zones (containers) allows to run processes using the same OpenIndiana kernel and system resources. Overheads are the lowest, while processes are isolated, but they are still UNIX processes. It is possible to use "branded" zones to emulate certain releases of other UNIX OSes, including Solaris 8, 9 and 10 (specify supported release-update numbers) and a Linux environment similar to kernel 2.4-based RHEL/CentOS.
  • (correction may be needed) Type-1 Hypervisor with QEMU-based KVM, where each VM is a kernel-space process with smaller latencies and overheads in comparison to Type-2 virtualization.
  • Type-2 Hypervisor with VirtualBox software running in a global or local zone. Each VM is a userspace process for the physical host, and may be managed as an SMF service with the project.

7.1 Zones/Containers

Zones are an OpenIndiana feature that provides operating system-level virtualization. Each zone is managed as a completely separate OpenIndiana machine. Zones have very low overhead and are one of the most efficient forms of OS virtualization.

The global zone is the first zone to boot and requires hardware access. From the global zone, non-global zones are created and booted. Boot time for non-global zones is very fast, often a few seconds. The CPU, network, and memory resources for each zone can be controlled from the global zone, ensuring fair access to system resources. As with other forms of virtualization, each zone is isolated from the other zones – zones cannot see processes or resources used in other zones. The low marginal cost of a zone allows large systems have tens or even hundreds of zones without significant overhead. The theoretical limit to the number of zones on a single platform is 8,192.

An easy way to implement zones is to use a separate ZFS file system as the zone root's backing store. File systems are easy to create in ZFS and zones can take advantage of the ZFS snapshot and clone features. Due to the strong isolation between zones, sharing a file system must be done with traditional file sharing methods (eg NFS).

When each zone is created  it comes with a minimal set of packages, and from there you can add and use most packages and applications as required.

Quick Setup Example

For each zone (in a simple configuration), you really only need a few bits of info.

  • The zone's name – something you can remember it by. For this example I'm naming the zone, example_zone;
  • The NIC – which physical or virtual network cards the zone will use exclusively or share. For this example I'm using e1000g0;
  • An IP address the zone will use – for this example of shared networking (in exclusive networking the zone sets its own IP address from inside, and can use DHCP);
  • The mount point in the global zone for the zone's file system. For this example I'm using /export/example_zone.

As a user with Primary Administrator role, you create the zone with


# zonecfg -z example_zone

This begins a configuration dialog, similar to the following:

zonecfg commandExplanation
createThis puts you inside the zone configuration program where you can change and update settings particular to the zone specified with -z.
zonecfg break different resource groups of data, you add a new resource with add.

add net  

set physical = e1000g0

set address =


The most important resource is a virtual network card, this is added with add net, then details are added and then end closes the editing of this resource.

This example configures networking in the ip-type=shared mode (default).
You specify the NIC or VNIC and the IP address here.
You can also optionally set a defrouter IP address, if it is different from one used by the global zone.

set zonepath=/export/example_zone

Then tell the zone where its root filesystem will be create and mounted in the global zone


Then verify the changes to generally check that no mistakes were made.



Then commit the changes and exit the zone configuration program.

Now all you have to do is install and boot your zone, the install process download the basic packages from your IPS repository and then boot performs a virtual hardware boot of your new zone.

While it is possible to infinitely complicate things (to use different IPS repositories, etc.), the simple installation method is:

# zoneadm -z example_zone install
# zoneadm -z example_zone boot

Whilst booting for the first time you will need to ask some basic configuration (you can set this all up via zone configuration beforehand in a /etc/sysidcfg file). To login is as the zone local console (as if you were sitting in front of a real machine as it boots), type:

# zlogin -C example_zone

Answer the questions (when it asks you for terminal type, the answer will be in most cases xterm for your interactivce GUI sessions, or ansi or vt100 for your headless SSH sessions).

Once done you can log in locally with zlogin example_zone (you will get a login prompt), or you can ssh in via the IP address you provided to zone config.

That is it, your zone is now up and running; as zones start with a minimal configuration, you will likely be missing many of the niceties you would expect. All are available via IPS packaging, for example if you miss the editor nano, then from your example_zones command prompt type:

# pkg install nano

In general you are likely to want to install lots of of packages depending on what your using the zone for.

7.2 xVM

7.3 Other.......


  • No labels