Servers with multiple disks or multiple arrays are typically managed by Veritas Volume Manager (VXVM). VXVM provides both GUI and command-line interfaces, and is designed to manage hundreds or even thousands of disks. It provides functionality for sharing disks between servers, and for control of disks within a cluster and during cluster failover. It is by far the most common disk-management system on large Sun servers.
VXVM requires that one or more disks be included in "the rootdg", a "disk group" that holds configuration information for all other disk groups. This diskgroup cannot be on a shared array (i.e., one attached to two servers in a cluster) because the diskgroup can never be "exported" from one machine and "imported" on another. Thus no disk in rootdg can be made available to any other machine, ever. Therefore, experienced administrators put the boot disk, or other local disks, in rootdg. They put all other disks in other disk groups.
Consider that if a database server fails, you might want to move the databases disks to another functional host until the problem is resolved. If those disks are in rootdg, they cannot be imported to the new system. However, if in another disk group, this operation is easily implemented.
So what's the problem? We can put the boot disk, plus another internal disk, in rootdg, and use VXVM to mirror between the two. Unfortunately, there's trouble in paradise. First, the root disk is built before VXVM is installed. For the root disk to be managed by VXVM, it must be "encapsulated". This process makes room for VXVM to add its management information to the disk, without having to rebuild the disk. Unfortunately, if you ever want to upgrade Solaris on this system, you must unencapsulate the disk first (because the upgrade procedures do not recognize the boot disk as a Solaris disk).
To understand another problem, consider the case of the root disk failing and its secondary mirror working properly. Naturally, the root disk is replaced and VXVM will re-mirror from the secondary. In this case the root disk is no longer encapsulated. Rather, it is a VXVM managed disk. Unfortunately, Solaris upgrades do not know how to deal with VXVM managed disks, so you can no longer easily upgrade that system. Even worse, you cannot even boot from CDROM and manually mount the root disk partitions (to recover from a lost root password or a dozen other problems)!
There even used to be a Sun Blueprint that recommended the following steps:
Encapsulate the root disk
Mirror to secondary disk
Tell VXVM that the root disk went bad
Tell VXVM to remirror to the root disk