Solaris Zone support

When using BMR to back up and restore Solaris Zones, you need to address some unique considerations.

Bare Metal Restore can restore a Solaris system running Zones. Although BMR cannot restore individual non-global zones, all non-global zones in a system are re-created as part of the global zone restoration.

In a dissimilar disk restoration scenario, do the following to ensure that you restore all non-global zones:

Remap the file system that hosts the zone (also known as zone path) to restore the zone files.
If a non-global zone imports slices from the global zone that are not remapped, BMR removes the slices from the zone configuration.
If a non-global zone imports slices from the global zone that are remapped to different disks, the following occurs: BMR readjusts the zone configuration and any zone vfstab (ZONEPATH/root/etc/vfstab) entries to use the new device names.
If a non-global zone imports systems from the global zone file that are not remapped, BMR removes any references to them in the zone configuration.

You may have to re-create and restore all file systems imported or used by a non-global zone after BMR restoration. These file systems usually don't appear in the global zone vfstab (/etc/vfstab).

In addition, to properly restore the zones, do the following:

BMR relies on entries in /etc/vfstab to document the file systems that are subject to restoration. Dynamically-created and mounted file the systems that do not appear in /etc/vfstab (even if backed up by NBU) do not automatically restore. The easiest way to force BMR to restore such file systems is the following: add an entry to /etc/vfstab that documents the devices and mount points used, with the Mount at boot field that is set to no. Then, the dynamic file systems can continue to be used as before. BMR is aware of them, recreates them unless unmapped in DDR, and restores their contents if backed up by NBU.

Zone features cause dynamically mounted file systems to appear, as follows:

fs entries that involve devices in the global zone
Device entries imported from the global zone but mounted either by the /etc/vfstab of the non-global zone, or dynamically by the zone itself

You can automate BMR zone restoration.

To automate, you add entries to the global zone /etc/vfstab that cause BMR to restore them (unless unmapped by DDR), as follows:

For fs entries, the global zone devices are used as special and raw values with a mount point that appears under the root of the non-global zone. The entry to add to the global zone's /etc/vfstab should use the global zone's device paths with the full path to the non-global zone mount point, including the zone path. For example, if the zone looks like:
```
	zonepath=/export/zone1  
	fs:
		dir=/export
		special=/dev/dsk/c0t9d0s6  
		raw=/dev/rdsk/c0t9d0s6  
		type=ufs
```
Then the global zone entry in /etc/vfstab should be as follows:
```
/dev/dsk/c0t9d0s6 /dev/rdsk/c0t9d0s6 /export/zone1/root/export ufs  
- no -
```
For device entries mounted by the non-global zone, the following issues must be dealt with when you configure for BMR restoration:
- The dynamic mount that is used involves the imported device path under the zone path. For a device that is mounted by an /etc/vfstab inside a non-global zone, there are one or more device entries in the zone, such as the following:
```
zonepath=/export/zone2  
  device:  
  match=/dev/*dsk/c0t0d0s4
```
  The devices that are listed are in the non-global zone's /etc/vfstab as follows:
```
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /local ufs - yes -
```
  This causes the global zone to dynamically mount
  
  /export/zone2/dev/dsk/c0t0d0s4 on mount point
  
  /export/zone2/root/local. However, to make BMR automatically recreate the fleshiest, you should add the documenting entry to the global zone /etc/vfstab instead as follows:
```
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /export/zone2/root/local ufs - no -
```
  (If you use the device paths relative to the zone path, BMR only recreates the mount point instead of restoring the whole fleshiest.)
- The device match should not use wildcards to allow BMR to edit if DDR is used. When the device specification involves a wildcard, BMR is not able to edit the entry if DDR mapping is done that affects the zone, such as unmapping or moving a fleshiest from one disk to another. The affected zone's /etc/vfstab is edited, but the device match entries are edited only if the match does not include a wildcard.
  
  For example, change the following entry:
```
match=/dev/*dsk/c0t0d0s4
```
  The entry must use two device entries, as follows:
```
match=/dev/dsk/c0t0d0s4  
match=/dev/rdsk/c0t0d0s4
```
  If the entries are changes as the example shows, BMR DDR correctly updates the zone definitions and vfstab file.