Skip Navigation Links | |
Exit Print View | |
Oracle Solaris ZFS Administration Guide Oracle Solaris 10 8/11 Information Library |
1. Oracle Solaris ZFS File System (Introduction)
2. Getting Started With Oracle Solaris ZFS
3. Oracle Solaris ZFS and Traditional File System Differences
4. Managing Oracle Solaris ZFS Storage Pools
5. Installing and Booting an Oracle Solaris ZFS Root File System
6. Managing Oracle Solaris ZFS File Systems
7. Working With Oracle Solaris ZFS Snapshots and Clones
8. Using ACLs and Attributes to Protect Oracle Solaris ZFS Files
9. Oracle Solaris ZFS Delegated Administration
10. Oracle Solaris ZFS Advanced Topics
Using a ZFS Volume as a Swap or Dump Device
Using a ZFS Volume as a Solaris iSCSI Target
Using ZFS on a Solaris System With Zones Installed
Adding ZFS File Systems to a Non-Global Zone
Delegating Datasets to a Non-Global Zone
Adding ZFS Volumes to a Non-Global Zone
Using ZFS Storage Pools Within a Zone
Using ZFS Alternate Root Pools
Creating ZFS Alternate Root Pools
Importing Alternate Root Pools
11. Oracle Solaris ZFS Troubleshooting and Pool Recovery
12. Recommended Oracle Solaris ZFS Practices
The following sections describe how to use ZFS on a system with Oracle Solaris zones:
For information about configuring zones on a system with a ZFS root file system that will be migrated or patched with Oracle Solaris Live Upgrade, see Using Live Upgrade to Migrate or Upgrade a System With Zones (Solaris 10 10/08) or Using Oracle Solaris Live Upgrade to Migrate or Upgrade a System With Zones (at Least Solaris 10 5/09).
Keep the following points in mind when associating ZFS datasets with zones:
You can add a ZFS file system or a clone to a non-global zone with or without delegating administrative control.
You can add a ZFS volume as a device to non-global zones.
You cannot associate ZFS snapshots with zones at this time.
In the following sections, a ZFS dataset refers to a file system or a clone.
Adding a dataset allows the non-global zone to share disk space with the global zone, though the zone administrator cannot control properties or create new file systems in the underlying file system hierarchy. This operation is identical to adding any other type of file system to a zone and should be used when the primary purpose is solely to share common disk space.
ZFS also allows datasets to be delegated to a non-global zone, giving complete control over the dataset and all its children to the zone administrator. The zone administrator can create and destroy file systems or clones within that dataset, as well as modify properties of the datasets. The zone administrator cannot affect datasets that have not been added to the zone, including exceeding any top-level quotas set on the delegated dataset.
Consider the following when working with ZFS on a system with Oracle Solaris zones installed:
A ZFS file system that is added to a non-global zone must have its mountpoint property set to legacy.
Due to CR 6449301, do not add a ZFS dataset to a non-global zone when the non-global zone is configured. Instead, add a ZFS dataset after the zone is installed.
When both a source zonepath and a target zonepath reside on a ZFS file system and are in the same pool, zoneadm clone will now automatically use the ZFS clone to clone a zone. The zoneadm clone command will create a ZFS snapshot of the source zonepath and set up the target zonepath. You cannot use the zfs clone command to clone a zone. For more information, see Part II, Zones, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
If you delegate a ZFS file system to a non-global zone, you must remove that file system from the non-global zone before using Oracle Solaris Live Upgrade. Otherwise, Oracle Live Upgrade will fail due to a read-only file system error.
You can add a ZFS file system as a generic file system when the goal is solely to share space with the global zone. A ZFS file system that is added to a non-global zone must have its mountpoint property set to legacy. For example, if the tank/zone/zion file system will be added to a non-global zone, set the mountpoint property in the global zone as follows:
# zfs set mountpoint=legacy tank/zone/zion
You can add a ZFS file system to a non-global zone by using the zonecfg command's add fs subcommand.
In the following example, a ZFS file system is added to a non-global zone by a global zone administrator from the global zone:
# zonecfg -z zion zonecfg:zion> add fs zonecfg:zion:fs> set type=zfs zonecfg:zion:fs> set special=tank/zone/zion zonecfg:zion:fs> set dir=/export/shared zonecfg:zion:fs> end
This syntax adds the ZFS file system, tank/zone/zion, to the already configured zion zone, which is mounted at /export/shared. The mountpoint property of the file system must be set to legacy, and the file system cannot already be mounted in another location. The zone administrator can create and destroy files within the file system. The file system cannot be remounted in a different location, nor can the zone administrator change properties on the file system such as atime, readonly, compression, and so on. The global zone administrator is responsible for setting and controlling properties of the file system.
For more information about the zonecfg command and about configuring resource types with zonecfg, see Part II, Zones, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
To meet the primary goal of delegating the administration of storage to a zone, ZFS supports adding datasets to a non-global zone through the use of the zonecfg command's add dataset subcommand.
In the following example, a ZFS file system is delegated to a non-global zone by a global zone administrator from the global zone.
# zonecfg -z zion zonecfg:zion> add dataset zonecfg:zion:dataset> set name=tank/zone/zion zonecfg:zion:dataset> end
Unlike adding a file system, this syntax causes the ZFS file system tank/zone/zion to be visible within the already configured zion zone. The zone administrator can set file system properties, as well as create descendent file systems. In addition, the zone administrator can create snapshots and clones, and otherwise control the entire file system hierarchy.
ZFS volumes cannot be added to a non-global zone by using the zonecfg command's add dataset subcommand. However, volumes can be added to a zone by using the zonecfg command's add device subcommand.
In the following example, a ZFS volume is added to a non-global zone by a global zone administrator from the global zone:
# zonecfg -z zion zion: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:zion> create zonecfg:zion> add device zonecfg:zion:device> set match=/dev/zvol/dsk/tank/vol zonecfg:zion:device> end
This syntax adds the tank/vol volume to the zion zone.
Note that adding a raw volume to a zone has implicit security risks, even if the volume doesn't correspond to a physical device. In particular, the zone administrator could create malformed file systems that would panic the system when a mount is attempted. For more information about adding devices to zones and the related security risks, see Understanding the zoned Property.
For more information about adding devices to zones, see Part II, Zones, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
ZFS storage pools cannot be created or modified within a zone. The delegated administration model centralizes control of physical storage devices within the global zone and control of virtual storage to non-global zones. Although a pool-level dataset can be added to a zone, any command that modifies the physical characteristics of the pool, such as creating, adding, or removing devices, is not allowed from within a zone. Even if physical devices are added to a zone by using the zonecfg command's add device subcommand, or if files are used, the zpool command does not allow the creation of any new pools within the zone.
After a dataset is delegated to a zone, the zone administrator can control specific dataset properties. After a dataset is delegated to a zone, all its ancestors are visible as read-only datasets, while the dataset itself is writable, as are all of its descendents. For example, consider the following configuration:
global# zfs list -Ho name tank tank/home tank/data tank/data/matrix tank/data/zion tank/data/zion/home
If tank/data/zion were added to a zone, each dataset would have the following properties.
|
Note that every parent of tank/zone/zion is visible as read-only, all descendents are writable, and datasets that are not part of the parent hierarchy are not visible at all. The zone administrator cannot change the sharenfs property because non-global zones cannot act as NFS servers. The zone administrator cannot change the zoned property because doing so would expose a security risk as described in the next section.
Privileged users in the zone can change any other settable property, except for quota and reservation properties. This behavior allows the global zone administrator to control the disk space consumption of all datasets used by the non-global zone.
In addition, the sharenfs and mountpoint properties cannot be changed by the global zone administrator after a dataset has been delegated to a non-global zone.
When a dataset is delegated to a non-global zone, the dataset must be specially marked so that certain properties are not interpreted within the context of the global zone. After a dataset has been delegated to a non-global zone and is under the control of a zone administrator, its contents can no longer be trusted. As with any file system, there might be setuid binaries, symbolic links, or otherwise questionable contents that might adversely affect the security of the global zone. In addition, the mountpoint property cannot be interpreted in the context of the global zone. Otherwise, the zone administrator could affect the global zone's namespace. To address the latter, ZFS uses the zoned property to indicate that a dataset has been delegated to a non-global zone at one point in time.
The zoned property is a boolean value that is automatically turned on when a zone containing a ZFS dataset is first booted. A zone administrator does not need to manually turn on this property. If the zoned property is set, the dataset cannot be mounted or shared in the global zone. In the following example, tank/zone/zion has been delegated to a zone, while tank/zone/global has not:
# zfs list -o name,zoned,mountpoint -r tank/zone NAME ZONED MOUNTPOINT tank/zone/global off /tank/zone/global tank/zone/zion on /tank/zone/zion # zfs mount tank/zone/global /tank/zone/global tank/zone/zion /export/zone/zion/root/tank/zone/zion
Note the difference between the mountpoint property and the directory where the tank/zone/zion dataset is currently mounted. The mountpoint property reflects the property as it is stored on disk, not where the dataset is currently mounted on the system.
When a dataset is removed from a zone or a zone is destroyed, the zoned property is not automatically cleared. This behavior is due to the inherent security risks associated with these tasks. Because an untrusted user has had complete access to the dataset and its descendents, the mountpoint property might be set to bad values, or setuid binaries might exist on the file systems.
To prevent accidental security risks, the zoned property must be manually cleared by the global zone administrator if you want to reuse the dataset in any way. Before setting the zoned property to off, ensure that the mountpoint property for the dataset and all its descendents are set to reasonable values and that no setuid binaries exist, or turn off the setuid property.
After you have verified that no security vulnerabilities are left, the zoned property can be turned off by using the zfs set or zfs inherit command. If the zoned property is turned off while a dataset is in use within a zone, the system might behave in unpredictable ways. Only change the property if you are sure the dataset is no longer in use by a non-global zone.