Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
zones zfs integration
Posted:
Mar 3, 2006 12:46 PM
|
|
I submitted this proposal to our internal architectural
review process today. Please feel free to send me
any comments or questions.
Thanks,
Jerry
---
SUMMARY:
This fast-track enhances the Solaris Zones [1] subsystem to improve
its integration with ZFS [2].
ZFS's advanced capabilities can provide a new degree of flexible
provisioning for Solaris Zones. This case address an existing RFE [3]
to provide integrated support for using ZFS snapshots and clones when
cloning zones [4]. Additionally, this case enhances zones to
automatically create ZFS filesystems during zone installation and
destroy ZFS filesystems during zone uninstall.
Patch binding is requested for these sub-commands and the stability
of the new options is "evolving". However, support for placing
zone roots on a ZFS filesystem will not be provided in a patch
release until bug 6356600 is resolved [5]. This bug is being
actively addressed so this is only a short-term issue. In the
meantime, these enhancements will only be a candidate for a minor
release.
DETAILS:
PSARC/2005/711 [4] introduced support for cloning zones by copying
the data from a source zonepath to a target zonepath. This case
extends that support to use ZFS clones, whenever possible, in place
of actually copying the data. The zonepath cloning technique will
be automatic. We will determine if a ZFS clone is an option for
cloning the zone, and if so, use a ZFS clone.
I don't want to get into implementation details here, but, in brief,
the implementation will look at what kind of filesystem the source
zonepath is and where the target zonepath will reside. If both are
non-ZFS or one is ZFS and the other non-ZFS, the code will use the
existing copy technique. If both are ZFS and in the same pool, we
will take a snapshot of the source zonepath and then use a ZFS clone
to set up the target zonepath. The actual implementation is a bit
more complicated than what I just described, but this gives the
general idea.
As an aside, a ZFS snapshot is a prerequisite for a ZFS clone. A
ZFS clone is an actual writable, mounted, filesystem that is based
off of the point-in-time, read-only, snapshot of some other ZFS
filesystem.
The destination zone zonepath will be used to name the ZFS clone.
The name of the snapshot(s) will be SUNWzoneX (where X is a unique
id to distinguish between multiple snapshots).
In all cases, we will automatically fall back to copying the data
if using a ZFS clone is not possible.
This case introduces a slight change in the behavior described in
PSARC/2005/711. PSARC/2005/711 stated that the default behavior
for zone cloning was to "copy". This case modifies that to make
the default behavior "do the right thing". Since the code for
PSARC/2005/711 is not released yet, outside of Nevada and OpenSolaris,
the minor change in default behavior should not be a factor.
You might want to clone a source zone many times and not want to
have a new snapshot for each clone. We will add a new '-s' parameter
to the clone subcommand which will allow you to specify that an
existing snapshot should be used.
For example:
# zoneadm -z new-zone clone -s foo/myzone@SUNWzone1 myzone
Since a snapshot's contents represent a zone from some unknown point
in the past, it is possible that the system has been updated
in some way, such as by patching or upgrading, since the snapshot
was taken. This could render the snapshot invalid for use as a zone
on the present-day system.
We will leverage the software inventory capabilities that were
introduced in the zone migration PSARC case [6] so that we
automatically take a software inventory while we are taking a
snapshot for cloning. In this way, we can identify the state
of the system associated with the snapshot and use the software
inventory to validate a snapshot if it is being reused for another
clone, similar to what we do today for zone detach/attach [6].
For example:
# zoneadm -z new-zone1 clone myzone
<take sw inven., take zfs snapshot(SUNWzone1), clone snapshot>
# zoneadm -z new-zone2 clone -s foo/myzone@SUNWzone1 myzone
<validate sw from snapshot(SUNWzone1), clone snapshot>
This means that only snapshots that have been taken from an earlier
zone clone can be used with the -s option since only those snapshots
will have the required software inventory needed to validate that the
snapshot is still usable on the host. Snapshots taken with an
explicit "zfs snapshot" command will not be usable.
PSARC/2005/711 also introduced a "-m copy" option. With this new
proposal, if you specify "-m copy" the zonepath will be copied, not
ZFS cloned, even if the source could be cloned. If you don't specify
the "-m copy" option, the code will "do the right thing".
Cloning a zone through ZFS clones depends upon the source zonepath
being its own ZFS filesystem. This is actually behavior that we
want to encourage since ZFS filesystems are cheap and offer other
benefits.
The "zoneadm install" subcommand will be extended to automatically
create a ZFS filesystem for the zonepath, if possible, when you
initially install a zone. If the zonepath is not on a ZFS filesystem
then the install will work as it currently does (the directory is
simply created and populated).
It is possible that the sys-admin might not want to automatically
create a ZFS filesystem when installing a zone. We will add an
optional "-x nodataset" parameter to "zoneadm install" which means
that a ZFS filesystem should not be created. If the zonepath is not
on a ZFS filesystem in the first place, then this parameter will have
no effect. This also introduces '-x' as a new option which can
be used for new, extended parameters in the future.
For example:
# zoneadm -z new-zone install -x nodataset
When a zone is uninstalled, if the zonepath is a ZFS filesystem,
instead of using "rm -rf" to remove the zone root, we will destroy
the ZFS filesystem. We will modify the behavior for uninstalling
non-ZFS based zonepaths in a similar manner to address an open bug [7].
As a result, the user will see consistent behavior in both the ZFS
and non-ZFS cases.
This will be implemented so that we will first validate that there
are no additional directories in the top-level of the zonepath. If
there are, the ZFS filesystem will not be destroyed and we will
instead fall-back to removing the root & dev (& lu [7]) directories
as we currently do. This will ensure that any user data that the
sys-admin might have placed in the top-level zonepath is not
accidentally lost. Likewise, if there are existing clones of the
zonepath, then the filesystem must be preserved. If the zonepath
was a ZFS clone, the associated snapshot will also be removed, if
possible.
EXPORTED INTERFACES
zoneadm subcommands
clone [-s snapshot] Evolving
install [-x nodataset] Evolving
The ZFS zone snapshot namespace
XXX/XXX@SUNWzoneX Stable
IMPORTED INTERFACES
libzfs Consolidation Private
(this is already imported by zones)
REFERENCES
1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. PSARC 2002/240 ZFS
3. 6383119 RFE: add support for using zfs clones when cloning a zone
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6383119
4. PSARC 2005/711 Zone move and clone
5. 6356600 - zfs datasets can't be used to provide space for zone roots
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6356600
6. PSARC 2006/030 Zone migration
7. 6365776 zoneadm uninstall doesn't remove <zonepath>/lu
|
|
