System Administration Guide: Virtualization Using the Solaris Operating System

Chapter 28 Troubleshooting Miscellaneous Solaris Zones Problems

This chapter contains zones troubleshooting information.

Information on Zones in the OpenSolaris 2009.06 Release

See About Zones in the OpenSolaris 2009.06 Release.

Exclusive-IP Zone Is Using Device, so dladm reset-linkprop Fails

If the following error message is displayed:

dladm: warning: cannot reset link property 'zone' on 'bge0': operation failed

Referring to How to Use dladm reset-linkprop, the attempt to use dladm reset-linkprop failed. The running zone excl is using the device, which was assigned by executing ifconfig bge0 plumb inside the zone.

To reset the value, use the procedure ifconfig bge0 unplumb inside the zone and rerun the dladm command.

Incorrect Privilege Set Specified in Zone Configuration

If the zone's privilege set contains a disallowed privilege, is missing a required privilege, or includes an unknown privilege name, an attempt to verify, ready, or boot the zone will fail with an error message such as the following:

zonecfg:zone5> set limitpriv="basic"
global# zoneadm -z zone5 boot
 	required privilege "sys_mount" is missing from the zone's privilege set
 	zoneadm: zone zone5 failed to verify

Zone Administrator Mounting Over File Systems Populated by the Global Zone

The presence of files within a file system hierarchy when a non-global zone is first booted indicates that the file system data is managed by the global zone. When the non-global zone was installed, a number of the packaging files in the global zone were duplicated inside the zone. These files must reside under the zonepath directly. If the files reside under a file system created by a zone administrator on disk devices or ZFS datasets added to the zone, packaging and patching problems could occur.

The issue with storing any of the file system data that is managed by the global zone in a zone-local file system can be described by using ZFS as an example. If a ZFS dataset has been delegated to a non-global zone, the zone administrator should not use that dataset to store any of the file system data that is managed by the global zone. The configuration could not be patched or upgraded correctly.

For example, a ZFS delegated dataset should not be used as a /var file system. The Solaris operating system delivers core packages that install components into /var. These packages have to access /var when they are upgraded or patched, which is not possible if /var is mounted on a delegated ZFS dataset.

File system mounts under parts of the hierarchy controlled by the global zone are supported. For example, if an empty /usr/local directory exists in the global zone, the zone administrator can mount other contents under that directory.

You can use a delegated ZFS dataset for file systems that do not need to be accessed during patching or upgrade, such as /export in the non-global zone.

netmasks Warning Displayed When Booting Zone

If you see the following message when you boot the zone as described in How to Boot a Zone:

# zoneadm -z my-zone boot
zoneadm: zone 'my-zone': WARNING: hme0:1: no matching subnet
	found in netmasks(4) for; using default of

The message is only a warning, and the command has succeeded. The message indicates that the system was unable to find the netmask to be used for the IP address specified in the zone's configuration.

To stop the warning from displaying on subsequent reboots, ensure that the correct netmasks databases are listed in the /etc/nsswitch.conf file in the global zone and that at least one of these databases contains the subnet and netmasks to be used for the zone my-zone.

For example, if the /etc/inet/netmasks file and the local NIS database are used for resolving netmasks in the global zone, the appropriate entry in /etc/nsswitch.conf is as follows:

netmasks: files nis

The subnet and corresponding netmask information for the zone my-zone can then be added to /etc/inet/netmasks for subsequent use.

For more information about the netmasks command, see the netmasks(4) man page.

Zone Does Not Halt

In the event that the system state associated with the zone cannot be destroyed, the halt operation will fail halfway. This leaves the zone in an intermediate state, somewhere between running and installed. In this state there are no active user processes or kernel threads, and none can be created. When the halt operation fails, you must manually intervene to complete the process.

The most common cause of a failure is the inability of the system to unmount all file systems. Unlike a traditional Solaris system shutdown, which destroys the system state, zones must ensure that no mounts performed while booting the zone or during zone operation remain once the zone has been halted. Even though zoneadm makes sure that there are no processes executing in the zone, the unmount operation can fail if processes in the global zone have open files in the zone. Use the tools described in the proc(1) (see pfiles) and fuser(1M) man pages to find these processes and take appropriate action. After these processes have been dealt with, reinvoking zoneadm halt will completely halt the zone.

Resolving Problems With a zoneadm attach Operation

ProcedurePatches and Packages Are Out of Sync

The target system must be running the same or later versions of the following required operating system packages and patches as those installed on the original host.

  1. If packages and patches are different between the original host and the new host, you might see a display similar to the following:

    host2# zoneadm -z my-zone attach
    	These packages installed on the source system are inconsistent with this system:
                SUNWgnome-libs (2.6.0,REV= version mismatch
                SUNWudaplr (11.11,REV=2005. version mismatch
                SUNWradpu320 (11.10.0,REV=2005. is not installed
                SUNWaudf (11.11,REV=2005. version mismatch
                NCRos86r (11.10.0,REV=2005. is not installed
    	These packages installed on this system were not installed on the source system:
                SUNWukspfw (11.11,REV=2006. was not installed
                SUNWsmcmd (1.0,REV=2005. was not installed
    	These patches installed on the source system are inconsistent with this system:
                120081 is not installed
                118844 is not installed
                118344 is not installed
    	These patches installed on this system were not installed on the source system:
                118669 was not installed
                118668 was not installed
                116299 was not installed
  2. To migrate the zone successfully, use one of the following methods:

ProcedureOperating System Releases Do Not Match

To migrate the zone successfully, install the same Solaris release that is running on the original host on a system with the same architecture.

  1. Verify the Solaris release running on the original system.

    host1# uname -a
  2. Install the same release on the new host.

    Refer to the Solaris installation documentation on

ProcedureMachine Architectures Do Not Match

To migrate the zone successfully, use the -u option to zoneadm attach.

  1. Verify the system architecture on both systems.

    host1# uname -a
  2. If the architectures are different, use the -u option to zoneadm attach to perform the attach.

    host2# zoneadm -z my-zone attach -u

    For more information, see How to Migrate A Non-Global Zone.