This blog entry attempts to explain that answer.First a recap: Solaris 10 introduced the Solaris Zones feature set, way back in 2005. Zones are a form of server virtualization called "OS (Operating System) Virtualization." They improve consolidation ratios by isolating processes from each other so that they cannot interact. Each zone has its own set of users, naming services, and other software components. One of the many advantages is that there is no need for a hypervisor, so there is no performance overhead. Many data centers run tens to hundreds of zones per server!
In Solaris 10, there are two models of package deployment for Solaris Zones. One model is called "sparse-root" and the other "whole-root." Each form has specific characteristics, abilities, and limitations.
A whole-root zone has its own copy of the Solaris packages. This allows the inclusion of other software in system directories - even though that practice has been discouraged for many years. Although it is also possible to modify the Solaris content in such a zone, e.g. patching a zone separately from the rest, this was highly frowned on. 
(More importantly, modifying the Solaris content in a whole-root zone may lead to an unsupported configuration.)
The other model is called "sparse-root." In that form, instead of copying all of the Solaris packages into the zone, the directories containing Solaris binaries are re-mounted into the zone. This allows the zone's users to access them at their normal places in the directory tree. Those are read-only mounts, so a zone's root user cannot modify them. This improves security, and also reduces the amount of disk space used by the zone - 200MB instead of the usual 3-5 GB per zone. These loopback mounts also reduce the amount of RAM used by zones because Solaris only stores in RAM one copy of a program that is in use by several zones. This model also has disadvantages. One disadvantage is the inability to add software into system directories such as /usr. Also, although a sparse-root can be migrated to another Solaris 10 system, it cannot be moved to a Solaris 11 system as a "Solaris 10 Zone."
In addition to those contrasting characteristics, here are some characteristics of zones in Solaris 10 that are shared by both packaging models:
- A zone can modify its own configuration files in /etc.
- A zone can be configured so that it manages its own networking, or so that it cannot modify its network configuration.
- It is difficult to give a non-root user in the global zone the ability to boot and stop a zone, without giving that user other abilities.
- In a zone that can manage its own networking, the root user can do harmful things like spoof other IP addresses and MAC addresses.
- It is difficult to assign network patcket processing to the same CPUs that a zone used. This could lead to unpredictable performance and performance troubleshooting challenges.
- You cannot run a large number of zones in one system (e.g. 50) that each managed its own networking, because that would require assignment of more physical NICs than available (e.g. 50).
- Except when managed by Ops Center, zones could not be safely stored on NAS.
- Solaris 10 Zones cannot be NFS servers.
- The fsstat command does not report statistics per zone.
Solaris 11 Zones use the new packaging system of Solaris 11. Their configuration does not offer a choice of packaging models, as Solaris 10 does. Instead, two (well, four) different models of "immutability" (changeability) are offered. The default model allows a privileged zone user to modify the zone's content. The other (three) limit the content which can be changed: none, or two overlapping sets of configuration files. (See "Configuring and Administering Immutable Zones".)
Solaris 11 addresses many of those limitations. With the characteristics listed above in mind, the following table shows the similarities and differences between zones in Solaris 10 and in Solaris 11. (Cells in a row that are similar have the same background color.)
| Characteristic | Solaris 10 Whole-Root | Solaris 10 Sparse-Root | Solaris 11 | Solaris 11 Immutable Zones |
|---|---|---|---|---|
| Each zone has a copy of most Solaris packages | Yes | No | Yes | Yes |
| Disk space used by a zone (typical) | 3.5 GB | 100 MB | 500MB | 500MB |
| A privileged zone user can add software to /usr | Yes | No | Yes | No |
| A zone can modify its Solaris programs | True | False | True | False |
| Each zone can modify its configuration files | Yes | Yes | Yes | No |
| Delegated administration | No | No | Yes | Yes |
| A zone can be configured to manage its own networking | Yes | Yes | Yes | Yes |
| A zone can be configured so that it cannot manage its own networking | Yes | Yes | Yes | Yes |
| A zone can be configured with resource controls | Yes | Yes | Yes | Yes |
| Network processing automatically happens on that zone's CPUs | No | No | Yes | Yes |
| Zones can be NFS servers | No | No | Yes | Yes |
| Per-zone fsstat data | No | No | Yes | Yes |
As you can see, the statement "Solaris 11 Zones are whole-root zones" is only true using the narrowest definition of whole-root zones: those zones which have their own copy of Solaris packaging content. But there are other valuable characteristics of sparse-root zones that are still available in Solaris 11 Zones. Also, some Solaris 11 Zones do not have some characteristics of whole-root zones.
For example, the table above shows that you can configure a Solaris 11 zone that has read-only Solaris content. And Solaris 11 takes that concept further, offering the ability to tailor that immutability. It also shows that Solaris 10 sparse-root and whole-root zones are more similar to each other than to Solaris 11 Zones.