Faster zone provisioning using zoneadm clone and Dtrace to monitoring zone

There is a wonderful blog on zone, I am transfering one engineer's
test below:

Faster zone provisioning using zoneadm clone

creating zones in parallel to reduce the time it takes to provision multiple zones, it was suggested that the new zoneadm clone subcommand could be of help. The zoneadm clone subcommand (available from build 33 onwards) copies an installed and configured zone. Cloning a zone is faster than installing a zone, but how much faster? To find out an Engineer did some quick experiments creating and cloning both whole root and sparse root zones on a V480:

Creating a whole root zone:

# zonecfg -z zone1
zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1> create -b
zonecfg:zone1> set zonepath=/zones/zone1
zonecfg:zone1> exit
# time zoneadm -z zone1 install
time zoneadm -z zone1 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <123834> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <986> packages on the zone.
Initialized <986> packages on zone.
Zone is initialized.
Installation of these packages generated errors:
The file contains a log of the zone installation.

real 13m40.647s
user 2m49.840s
sys 4m43.221s

Cloning a whole root zone:

# zonecfg -z zone1 export|sed -e 's/zone1/zone2/'|zonecfg -z zone2
zone2: No such zone configured
Use 'create' to begin configuring a new zone.
# time zoneadm -z zone2 clone zone1
Cloning zonepath /zones/zone1...

real 8m4.615s
user 0m9.780s
sys 2m18.334s

For the whole root zone cloning is almost twice a fast as a regular install.

Creating a sparse root zone:

# zonecfg -z zone2
zone3: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone3> create
zonecfg:zone3> set zonepath=/zones/zone3
zonecfg:zone3> exit
# time zoneadm -z zone3 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <2535> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <986> packages on the zone.
Initialized <986> packages on zone.
Zone is initialized.
Installation of these packages generated errors:
The file contains a log of the zone installation.

real 6m3.227s
user 1m45.902s
sys 2m47.717s

Cloning a sparse root zone:

# zonecfg -z zone3 export|sed -e 's/zone3/zone4/'|zonecfg -z zone4
zone4: No such zone configured
Use 'create' to begin configuring a new zone.
# time zoneadm -z zone4 clone zone3
Cloning zonepath /zones/zone3...

real 0m11.535s
user 0m0.706s
sys 0m6.440s

For the sparse root zone, cloning is more than thirty times faster then installing!

So if you need to provision multiple zones of a certain configuration, zoneadm clone is clearly the way to go.

Note that the current clone operation does not (yet) take advantage of ZFS. To see what ZFS can do for zone cloning, have a look at Mike Gerdts' blog: Zone created in 0.922 seconds. Goodness indeed.

T: OpenSolaris Zones
( Mar 18 2006, 07:12:17 PM CET ) Permalink Comments [1]
20050525 Wednesday May 25, 2005
Monitoring zone boot and shutdown using DTrace

Several people have expressed a desire for a way to monitor zone state transitions such as zone boot or shutdown events. Currently there is no way to get notified when a zone is booted or shutdown. One way would be to run zoneadm list -p at regular intervals and parse the output, but this has some drawbacks that make this solution less ideal:

* it is inefficient because you are polling for events,
* you will probably start at least two processes for each polling cycle (zoneadm(1M) and nawk(1)),
* more importantly, you could miss transitions if your polling interval is too large. Since a zone reboot might take only seconds, you would need to poll often in order not to miss a state change.

A better, much more efficient solution can be built using DTrace, the 'Swiss Army knife of system observability'. As mentioned in this message on the DTrace forum, the zone_boot() function looks like a promising way to get notifications when a zone is booted. Listing all FBT probes with the string 'zone_' in their name (dtrace -l fbt|grep zone_) turns up another interesting function: zone_shutdown(). To verify that these probes are fired when a zone is either booted or shutdown, let's enable both probes:

# dtrace -n 'fbt:genunix:zone_boot:entry, fbt:genunix:zone_shutdown:entry {}'
dtrace: description 'fbt:genunix:zone_boot:entry, fbt:genunix:zone_shutdown:entry ' matched 2 probes

When zoneadm -z zone1 boot is executed we see that the zone_boot:entry probe fires:

CPU ID FUNCTION:NAME
0 6722 zone_boot:entry

The zone_shutdown:entry probe fires when the zone is shutdown (either by zoneadm -z zone1 halt or using init 0 from within the zone):

0 6726 zone_shutdown:entry

This gives us the basic 'plumbing' for the monitoring script. By instrumenting the zone_boot() and zone_shutdown() functions with the FBT provider we can wait for zone boot and shutdown with almost zero overhead. Now what is left is finding out the name of the zone that was booted or shutdown. This requires some knowledge of the implementation and access to the source (anyone interested can take a look at the source after OpenSolaris is launched, so stay tuned).

A quick look at the source shows that we can get the zone name by instrumenting a third function, zone_find_all_by_id() that is called by both zone_boot() and zone_shutdown(). This function returns a pointer to a zone_t structure (defined in /usr/include/sys/zone.h). The DTrace script below uses a common DTrace idiom: in the :entry probe we set a thread-local variable trace that is used as a predicate in the :return probes (the :return probes have the information we're after). The FBT provider :return probe stores the function return value in args[1] so we can access the zone name as args[1]->zone_name in fbt:genunix:zonefind_all_by_id:return and save it for later use in fbt:genunix:zone_boot:return and fbt:genunix:zone_shutdown:return.

#!/usr/sbin/dtrace -qs

self string name;

fbt:genunix:zone_boot:entry
{
self->trace = 1;
}

fbt:genunix:zone_boot:return
/self->trace && args[1] == 0/
{
printf("Zone %s booted\n", self->name);
self->trace = 0;
self->name = 0;
}

fbt:genunix:zone_shutdown:entry
{
self->trace = 1;
}

fbt:genunix:zone_shutdown:return
/self->trace && args[1] == 0/
{
printf("Zone %s shutdown\n", self->name);
self->trace = 0;
self->name = 0;
}

fbt:genunix:zone_find_all_by_id:return
/self->trace/
{
self->name = stringof(args[1]->zone_name);
}


Starting the script and booting and shutting down some Zones gives the following result:

# ./zonemon.d
Zone aap booted
Zone noot booted
Zone noot shutdown
Zone noot booted
Zone aap shutdown