Solaris: SVM deployment and ZFS migration with minimun downtime

Hace muy pocos días, compré un viejo, pero en excelente estado, servidor Sun Fire 280R. El equipo cuenta con algunos features más que interesantes, equipado con dos procesadores UltraSPARC64 III, 2 Gb. de RAM, RSC card, fuentes de alimentación redundantes, lector de DVD-R y dos discos SCSI de 36 Gb cada uno.
Al momento de bootearlo por primera vez, me encontré con Solaris 10 5/08 instalado, y prácticamente sin uso. Por lo cual no hacía reinstalar el sistema operativo. Había un solo tema negativo en esta configuración por default, el layout de particionamiento de los discos y asignación filesystems no me gustaba. En uno de los discos estaba el sistema operativo, el /export/home, en otro utilizando ZFS cree un zpool donde instalé una zona que no quería volver a reinstalar.

Mi idea, fue migrar algunas particiones a SVM (Solaris Volume Manager), armando un mirror entre ambos discos, y para las zonas armar también un zpool mirroreado, con el objetivo de obtener redundancia y mejorar la performance de I/O La idea era migrar parte del disco a un RAID1, utilizando SVM y la otra a un Zpool utilizando mirroring, para de esta forma tener redundancia al duplicar los cabezales de lectoescritura de los discos, lo que podría acelerar en un 50% los tiempos de búsquedas y lecturas.

Solaris Volume Manager:
Originalmente conocido como Online: DiskSuite, y luego como Solstice DiskSuite, SVM es un paquete de software que integra un Volume Manager con una gran cantidad de opciones que le provee a un sistema operativo, crear mediante software metadevices (Logical Volumes), y utilizarlo bajo distintos esquemas que provean flexibilidad y redundancia, como por ejemplo la posibilidad de crear volúmenes en RAID 0, mirrorear estos utilizando RAID 1, RAID 5, RAID 0+1 o RAID 1+0 además de Soft Partitions, a fin de poder vencer la limitación de siete slices por disco. Añadido originalmente para SunOS a finales de 1991, a sido una herramienta testeada y segura para manejar grandes volúmenes de información, teniendo la particularidad de poder convivir perfectamente con implementaciones de ZFS que se están convirtiendo en estándar en varios sistemas operativos.

Volumes Table of Contents (VTOC):
Como en PC/BIOS MBR es el estándar de particionamiento, y los BSD Labels lo son para sistemas operativos BSD, Solaris utiliza la VTOC (muy similar a BSD), esto es una tabla en la cual divide al disco en ocho posibles particiones o slices que van desde la 0 a la 7. VTOC predefine algunos slices para ser utilizados comúnmente de una manera especificada, por ejemplo el slice 0, es la root partition, osea, donde el sistema operativo booteara, el número 1 corresponde a la swap, y existe un slice especial denominado backup, el número 2 de nuestra tabla, este slice contiene todos los bloques disponibles en la unidad de almacenamiento que serán luego redistribuidos en el esquema de particionamiento elegido y nunca debe ser utilizado. Como seguramente habrán notado, también es posible asignarle flags a las particiones, el flag "w" especifica que la partición es escribible, por su parte el flag "m" nos quiere decir que la partición se puede montar, y el flag "u", que esta partición no puede ser montada (como es el caso de la swap).

Veamos un ejemplo:

Part      Tag    Flag     Cylinders         Size      Blocks
  0       root    wm     363 -  6170        8.00GB    16779312
  1       swap    wu       0 -   362      512.06MB    1048707
  2     backup    wm       0 - 24619       33.92GB    71127180
  3       home    wm    6171 -  6896        1.00GB    2097414
  4 unassigned    wm    6897 - 14156       10.00GB    20974140
  5 unassigned    wm       0                0         0
  6 unassigned    wm       0                0         0
  7 unassigned    wu   14157 - 14227      100.16MB    205119

Ahora bien, ya con estos conocimiento en mente, vamos a describir como estaban definidos nuestros discos:

La configuración de particionamiento es la siguiente:

• c1t0d0 (36 Gb.) - Sistema operativo (UFS)
• c1t1d0 (36 Gb.) - Zonas (ZFS)

Si analizamos el layout del primer disco, podemos notar que en c0t1d0s0 se encontraba el rootfs (/), en c0t0d0s1 la swap, y en c0t1d0s3 /export/home. Por su parte en c1t1d0s7, existe un zpool, llamado "zones, que contiene una zona "testing", instalada sobre un filesystem con el mismo nombre.

Manos a la obra
Comprobamos la existencia de la zona mediante zoneadm, podemos ver que la misma se encuentra corriendo, ejecutando servicios web y esta dentro del zpool creado especialmente para este fin, conformado por un solo disco, destro del slice 7 (c1t1d0s7):

shangai /#> zoneadm list -vi
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   1 testing          running    /zones/testing                 native   shared

shangai /#> zpool status -v 
  pool: zones
 state: ONLINE
 scrub: none requested
config:
        NAME        STATE     READ WRITE CKSUM
        zones       ONLINE       0     0     0
          c1t1d0s7  ONLINE       0     0     0
errors: No known data errors

shangai /#> zfs list 
NAME                                USED  AVAIL  REFER  MOUNTPOINT
zones                               789M  32.5G  26.5K  /zones
zones/testing                       789M  32.5G   228M  /zones/testing

A continuación crearemos un slice de 10 Gb. en el primer disco (c1t0d0), para contener nuestra zona en un futuro, por lo cual desde format debemos definir el nuevo slice:

shangai /#> format
Searching for disks...done

AVAILABLE DISK SELECTIONS:
       0. c1t0d0 
          /pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000004cf72faa5,0
       1. c1t1d0 
          /pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000004cf7805c4,0
Specify disk (enter its number): 0
selecting c1t0d0
[disk formatted]

Format nos preguntará sobre que disco queremos trabajar, por lo cual, en nuestro caso debemos seleccionar el primer disco, osea, el número 0, (c1t0d0).

FORMAT MENU:
        disk       - select a disk
        type       - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format     - format and analyze the disk
        repair     - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect     - defect list management
        backup     - search for backup labels
        verify     - read and display labels
        save       - save new disk/partition definitions
        inquiry    - show vendor, product and revision
        volname    - set 8-character volume name
        !     - execute , then return
        quit
format> p

Ya en el menú de format, seleccionamos partition, a esto lo hacemos escribiendo literalmente partition, o simplemente con la letra "p".

PARTITION MENU:
        0      - change `0' partition
        1      - change `1' partition
        2      - change `2' partition
        3      - change `3' partition
        4      - change `4' partition
        5      - change `5' partition
        6      - change `6' partition
        7      - change `7' partition
        select - select a predefined table
        modify - modify a predefined partition table
        name   - name the current table
        print  - display the current table
        label  - write partition map and label to the disk
        ! - execute , then return
        quit
partition> p

Ya podemos trabajar con nuestras particiones, podemos seleccionar alguna de ellas, simplemente escogiendo el número sobre la que queremos trabajar y reasignar su geometría, o cargar un layout predefinido del archivo /etc/format.dat. En nuestr caso vamos a imprimir la tabla actual, escribiendo print, o su primer letra "p":

Current partition table (original):
Total disk cylinders available: 24620 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm     363 -  6170        8.00GB    (5808/0/0)  16779312
  1       swap    wu       0 -   362      512.06MB    (363/0/0)    1048707
  2     backup    wm       0 - 24619       33.92GB    (24620/0/0) 71127180
  3       home    wm    6171 -  6896        1.00GB    (726/0/0)    2097414
  4 unassigned    wm       0                0         (0/0/0)            0
  5 unassigned    wm       0                0         (0/0/0)            0
  6 unassigned    wm       0                0         (0/0/0)            0
  7 unassigned    wm       0                0         (0/0/0)            0

partition> 4

Nuestra partición 0, se encuentra siendo utilizada por el root filesystem, la 1 como sabemos es la swap, la 2 es backup (osea todo el disco), la 3 la home, por lo cual para seguir un orden geométrico, seleccionaremos la cuatro, y comenzaremos a definir la nueva partición.

Part      Tag    Flag     Cylinders         Size            Blocks
  4 unassigned    wm       0                0         (0/0/0)            0

Enter partition id tag[unassigned]: 
Enter partition permission flags[wm]: 
Enter new starting cyl[0]: 6897
Enter partition size[0b, 0c, 6897e, 0.00mb, 0.00gb]: 10gb

En la particón 4, definimos primero el tag, luego los flags con los que montará, en este caso wm, osea es una partición escribible y montable. Definimos el cilindro por el que la partición comienza, en nuestro caso en orden, el siguiente cilindro libre, osea el 6897, y por ultimo el tamaño, aquí 10gb.

partition> p
Current partition table (unnamed):
Total disk cylinders available: 24620 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm     363 -  6170        8.00GB    (5808/0/0)  16779312
  1       swap    wu       0 -   362      512.06MB    (363/0/0)    1048707
  2     backup    wm       0 - 24619       33.92GB    (24620/0/0) 71127180
  3       home    wm    6171 -  6896        1.00GB    (726/0/0)    2097414
  4 unassigned    wm    6897 - 14156       10.00GB    (7260/0/0)  20974140
  5 unassigned    wm       0                0         (0/0/0)            0
  6 unassigned    wm       0                0         (0/0/0)            0
  7 unassigned    wm       0                0         (0/0/0)            0

partition> label
Ready to label disk, continue? y

Volvemos a imprimir la tabla, mediante print, y escribirmos el label a disco.

El slice (c1t0d0s4) ya se encuentra creado,para estar seguros, fuera de la herramienta format imprimimos nuestra VTOC, utilizando prvtoc,(print vtoc):

shangai /#> prtvtoc -h /dev/dsk/c1t0d0s2
       0      2    00    1048707  16779312  17828018   /
       1      3    01          0   1048707   1048706
       2      5    00          0  71127180  71127179
       3      8    00   17828019   2097414  19925432   /export/home
       4      0    00   19925433  20974140  40899572

Vemos que la partición 4 se encuentra creada. El argumento -h del comando prtvtoc le dice a este que no imprima el header.

Ahora vamos a crear un nuevo zpool, con el slice que acabamos de crear, recuerden que este zpool va a contener la zona "testing", por lo cual, para que el zonepath de la zona funcione correctamente, debe tener el mismo nombre, aunque siempre existe la posibilidad de editar con zonecfg esta propiedad a fin de ajustarla al nuevo path. En mi caso, quería seguir utilizando "zones". Por lo cual cree un nuevo zpool llamado "zonas":

shangai /#> zpool create zonas /dev/dsk/c1t0d0s4
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
zonas                  9.94G     88K   9.94G     0%  ONLINE     -
zones                  33.8G    789M   33.0G     2%  ONLINE     -

Con el Zpool creado, y para evitar corrupciones de archivos, vamos a apagar nuestra zona, y comprobar que la misma haya bajado bien:

shangai /#> zoneadm -z testing halt
shangai /#> zoneadm list -vi
  ID NAME             STATUS     PATH                           BRAND    IP
   0 global           running    /                              native   shared
   - testing          installed  /zones/testing                 native   shared

Perfecto, la zona se encuentra baja, ahora lo que vamos a hacer, es migrar el filesystem "testing", donde esta nuestra zona, al nuevo zpool "zonass" que acabamos de crear, para ello tomamos un snapshot de zones/testing:

shangai /#> zfs snapshot zones/testing@snapshot-$(date +%Y-%m-%d)
shangai /#> zfs list
NAME                                USED  AVAIL  REFER  MOUNTPOINT
zonas                                85K  9.78G  24.5K  /zonas
zones                               789M  32.5G  26.5K  /zones
zones/testing                       789M  32.5G   228M  /zones/testing
zones/testing@snapshot-2012-06-23      0      -   228M  -

Ahora mediante la opción send de ZFS restauramos el filesystem en el nuevo zpool:

shangai /#> zfs send zones/testing@snapshot-2012-06-23 | zfs receive zonas/testing

NAME                                USED  AVAIL  REFER  MOUNTPOINT
zonas                               346M  9.44G  25.5K  /zonas
zonas/testing                       345M  9.44G   345M  /zonas/testing
zonas/testing@snapshot-2012-06-23      0      -   345M  -
zones                               789M  32.5G  26.5K  /zones
zones/testing                       789M  32.5G   228M  /zones/testing
zones/testing@snapshot-2012-06-23      0      -   228M  -

Y borramos el zpool "zones". Debemos pasarle el flag -f a fin de forzar la eliminación de dicho zpool, que se encuentra con filesystems montados:

shangai /#> zpool destroy -f zones

Ahora vamos a renombrar el zpool de "zonas" a zones nuevamente, para ello primero debemos exportarlo, y volver a importarlo con el nuevo nombre:

shangai /#> zpool export zonas
shangai /#> zpool import zonas zones
shangai /#> zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
zones                  9.94G    346M   9.60G     3%  ONLINE     -

Esto dependiendo el tamaño de la zona puede tardar un rato, en este caso la zona era pequeña, por lo cual fue una tarea más que rápida. Si todo salio bien, ya estamos en condiciones de bootear nuestra zona nuevamente y loguearnos en ella:

shangai /#> zoneadm -z testing boot
shangai /#> zlogin testing
[Connected to zone 'testing' pts/3]
Last login: Fri Jun 22 15:56:10 from testing

[root@testing /#] exit
[Connection to zone 'testing' pts/4 closed]

Ya estamos a un 50% de concluir nuestra tarea, lo que debemos hacer a continuación es espejar nuestra VTOC de un disco a otro, si bien es posible realizar esto a mano, copiando la geometría de un disco a otro, es más práctico hacerlo a mano, para ello con prtvtoc imprimimos nuestra tabla de particiones y la levantamos en el segundo disco con fmthard (format harddrive):

shangai /#> prtvtoc /dev/rdsk/c1t0d0s2 | fmthard -s - /dev/rdsk/c1t1d0s2
fmthard:  New volume table of contents now in place.

Y attacheamos el segundo disco a nuestro zpool

shangai /#> zpool attach zones c1t0d0s4 c1t1d0s4  
shangai /#> zpool status -v
  pool: zones
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress, 46.90% done, 0h0m to go
config: 
        NAME          STATE     READ WRITE CKSUM
        zones         ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            c1t0d0s4  ONLINE       0     0     0
            c1t1d0s4  ONLINE       0     0     0
errors: No known data errors

La metadb, es una base de datos de estados utilizada para mantener la configuración de todos nuesotros metadevices en el sistema. Para ser más concisos aún, la metadb se define como una colección de múltiples replicas de bases de estados de dispositivos, donde cada replica se somete a intensivos chequeos a fin de garantizar su consistencia.
Adicionalemente, también mantiene información sobre las transacciones realizadas en nuestros metadevices. SVM actualiza la metadb cuando un cambio en la configuración ocurre, por ejemplo cuando un submirror falla. La metadb puede ser almacenada en un slice dedicado (como configuraremos nosotros), o en cualquier metadevice, siempre y cuando no contenga información preexistente.
Seguramente se preguntarán, que pasa si distintas metadb's, mantienen información distinta, la respuesta es fácil, SVM, utiliza un algoritmo en el cual obedece solo en caso de que la mitad + 1 tengan la misma información, por lo cual de esta manera se evitan problemas similares al RAID 5 write hole.
Solo como un consejo, NUNCA creen la metadb en un storage interno (SAN/NAS).
Es recomendable que las réplicas de la metadb se encuentren en diferentes discos (como haremos en este caso), o aún mejor, en diferentes controladoras.

Como creamos nuestro slice para el zpool, debemos crear un nuevo slice en ambos discos con exactamente la misma geometría, un slice dedicado para nuestra metadb, por lo cual volvemos a recurrir a format.

shangai /#> format
Searching for disks...done

AVAILABLE DISK SELECTIONS:
       0. c1t0d0 
          /pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000004cf72faa5,0
       1. c1t1d0 
          /pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w21000004cf7805c4,0
Specify disk (enter its number): 0
selecting c1t0d0

partition> p
Current partition table (original):
Total disk cylinders available: 24620 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm     363 -  6170        8.00GB    (5808/0/0)  16779312
  1       swap    wu       0 -   362      512.06MB    (363/0/0)    1048707
  2     backup    wm       0 - 24619       33.92GB    (24620/0/0) 71127180
  3       home    wm    6171 -  6896        1.00GB    (726/0/0)    2097414
  4 unassigned    wm    6897 - 14156       10.00GB    (7260/0/0)  20974140
  5 unassigned    wm       0                0         (0/0/0)            0
  6 unassigned    wm       0                0         (0/0/0)            0
  7 unassigned    wm       0                0         (0/0/0)            0

partition> 7
Part      Tag    Flag     Cylinders         Size            Blocks
  7 unassigned    wm       0                0         (0/0/0)            0

Enter partition id tag[unassigned]:    
Enter partition permission flags[wm]: 
Enter new starting cyl[0]: 14157
Enter partition size[0b, 0c, 14157e, 0.00mb, 0.00gb]: 100mb
partition> label
Ready to label disk, continue? y

Crearemos la metadb con 3 copias de ellas en ambos slices, dando un total de 6. Para ello vamos a utilizar el comando metadb. El flag -a, le indica a metadb que debe crear una nueva db, el flag -c 3, es la cantidad de copias que deben existir de ella, y que se utilizarán en caso de alguna corrupción de datos, y el flag -f se utiliza para crear la metadb inicial.

shangai /#> metadb -a -c 3 -f c1t0d0s7 c1t1d0s7 

Una vez creadas, podemos monitorear el estado de nuestras metadb, de la siguiente manera:

shangai /#> metadb -i  
        flags           first blk       block count
     a m  p  luo        16              8192            /dev/dsk/c1t0d0s7
     a    p  luo        8208            8192            /dev/dsk/c1t0d0s7
     a    p  luo        16400           8192            /dev/dsk/c1t0d0s7
     a    p  luo        16              8192            /dev/dsk/c1t1d0s7
     a    p  luo        8208            8192            /dev/dsk/c1t1d0s7
     a    p  luo        16400           8192            /dev/dsk/c1t1d0s7
 r - replica does not have device relocation information
 o - replica active prior to last mddb configuration change
 u - replica is up to date
 l - locator for this replica was read successfully
 c - replica's location was in /etc/lvm/mddb.cf
 p - replica's location was patched in kernel
 m - replica is master, this is replica selected as input
 W - replica has device write errors
 a - replica is active, commits are occurring to this replica
 M - replica had problem with master blocks
 D - replica had problem with data blocks
 F - replica had format problems
 S - replica is too small to hold current data base
 R - replica had device read errors

Ahora llego el momento de crear nuestros metadevices, y cada metadevice no es otra cosa que un mappeo desde un dispositivo de bloques lógico identificado por un nombre a un conjunto de bloques en disco albergados dentro de un slice o en un disco los cuales son manejados por una tecnología conocida como device mapper, en este caso SVM. Cada metadevice es nombrado por la letra "d" seguido de un número (dXX), y debemos tener un metadevice por cada slice que queramos inicializar utilizando SVM.
Por ejemplo, como en este caso, para crear mirrors, tenemos un slice destinado en cada uno de nuestros discos, c1t0d0s0 (disco 1) y c1t1d0s0 (disco 2), llamaremos al metadevice del primer disco d21, y al metadevice del segundo disco d22, los cuales en conjunto crearan el metadevice d20. Si bien un metadevice puede tener cualquier nombre, por una cuestión de prolijidad y fácilidad de entendimiento utilizaremos estos nombres que son los que se utilizan en la mayoría de las implementanciones.

Mediante el comando metainit, procederemos a crear cada uno de ellos, vamos a crear los metadevices para el root filesystem (d11 en c1t0d0s0, y d12 en c1t1d0s0) creando un mirror al que denominaremos d10, y en principio le attacharemos solo el primero de los metadevices que crearemos, d11 El flag -f, le indica a metainit, que fuerze la operación, aunque el device sobre el que crearemos el metadevice contenga particiones montadas. Nosotros queremos 1 device físico en cada metadevice, los parámetros 1 1 le dicen a metainit que creen una concatenación 1 a 1 entre ambos discos.

shangai /#> metainit -f d11 1 1 c1t0d0s0
d11: Concat/Stripe is setup

shangai /#> metainit -f d12 1 1 c1t1d0s0 
d12: Concat/Stripe is setup

Ahora, también con metainit, inicializaremos el mirror d10, diciéndole que d11 es un submirror de d10. La sintaxis es la siguiente: metainit mirror -m submirror. Mas adelante, attacharemos d12, la otra mitad del mirror.

shangai /#> metainit d10 -m d11
d10: Mirror is setup

Ahora utilizando metaroot (solo para trabajar menos), le diremos al sistema operativo (mediante /etc/system) y al archivo /etc/vfstab, que nuestro boot device (o rootdev) se encuentra en el metadevice d10 y de esta forma evitaremos tener que realizar los cambios a mano:

shangai /#> metaroot d10

Si miramos dentro de los archivos /etc/system y /etc/vfstab, encontraremos algo similar a esto:

shangai /#> cat /etc/system
* Begin MDD root info (do not edit)
rootdev:/pseudo/md@0:0,10,blk
* End MDD root info (do not edit)

shangai /#> cat /etc/vfstab
#device         device          mount           FS      fsck    mount   mount
#to mount       to fsck         point           type    pass    at boot options
#
/dev/md/dsk/d10 /dev/md/rdsk/d10        /       ufs     1       no      -

Ahora vamos a continuar inicalizando el resto de nuestros metadevices, primero crearemos d21 y d22, que formarán parte de d20, el cual corresponde a nuestra swap.

shangai /#> metainit -f d21 1 1 c1t0d0s1 
d21: Concat/Stripe is setup

shangai /#> metainit -f d22 1 1 c1t1d0s1  
d22: Concat/Stripe is setup

shangai /#> metainit d20 -m d21 
d20: Mirror is setup

En este punto debemos recordar hacer el cambio en el archivo /etc/vfstab, ya que metaroo no realiza esto para la swap (solo lo hace para el rootfs). Utilizando SVM el path hacia el device se encuentra ahora en /dev/md/dsk, por lo cual debemos modificar esto como se detalla a continuación, comentando la entrada antigua, y escribiendo el nuevo path hacia /dev/md/dsk/d20:

#device         device          mount           FS      fsck    mount   mount
#to mount       to fsck         point           type    pass    at boot options
#
#/dev/dsk/c1t0d0s1      -       -       swap    -       no      -
/dev/md/dsk/d20         -       -       swap    -       no      -       

Ahora vamos a crear los metadevices d31 y d32, que formaran el mirror d30 y corresponde a /export/home. También debemos recordar modificar el /etc/vfstab para ajustar estos cambios:

shangai /#> metainit -f d31 1 1 c1t0d0s3
d31: Concat/Stripe is setup

shangai /#> metainit -f d32 1 1 c1t1d0s3
d32: Concat/Stripe is setup

shangai /#> metainit d30 -m d31
d30: Mirror is setup

Y volvemos a cambiar el /etc/vfstab, para decirle al sistema que nuestro /export/home/ se encuentra en /dev/md/dsk/d30:

#/dev/dsk/c1t0d0s3      /dev/rdsk/c1t0d0s3      /export/home    ufs     2       yes   - 
/dev/md/dsk/d30         /dev/md/rdsk/d30        /export/home    ufs     2       yes   -

Ya estamos en condiciones de rebootear, pero antes vamos a ejecutar lockfs con el objetivo de vaciar todos los buffers, si bien no es necesario, es recomendado.

shangai /#> lockfs -fa
shangai /#> shutdown -y -g 0 -i 6

Una vez el equipo booteado, nos volvemos a loguear como root, y procedemos a attachear los metadevices del segundo disco, esto es: a d10 le attacheamos d12, a d20 d22 y a d30 attacheamos d32.

shangai /#> metattach d10 d12
d10: submirror d12 is attached

shangai /#> metattach d20 d22
d20: submirror d22 is attached

shangai /#> metattach d30 d32 
d30: submirror d32 is attached

Una vez listo, esto, el sistema comenzará a sincronizar los metadevices entre ambos discos, podemos inspeccionar esto mediante el metastat:

shangai /#> metastat -c
d30              m  1.0GB d31 d32 (resync-12%)
    d31          s  1.0GB c1t0d0s3
    d32          s  1.0GB c1t1d0s3
d20              m  512MB d21 d22 (resync-73%)
    d21          s  512MB c1t0d0s1
    d22          s  512MB c1t1d0s1
d10              m  8.0GB d11 d12 (resync-4%)
    d11          s  8.0GB c1t0d0s0
    d12          s  8.0GB c1t1d0s0

Una vez terminada la sincronización en los tres mirrors, estamos en condiciones de comenzar a disfrutar de SVM en todo su esplendor, pero solo resta una cosa más, únicamente si estamos utilizando arquitectura SPARC, instalar el bootloader, ufsboot en el segundo disco (c1t1d0s0), así de en caso de una falla en el primer disco, podamos bootear desde el segundo. ufsboot, se encuentra en /usr/platform/`uname -i`/lib/fs/ufs/bootblk.

shangai /#> installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c1t1d0s0

Alternativamente podriamos configurar en el OBP, mediante un alias, por ejemplo boot-backup, para especificarle este segundo disco en caso de que el primero falle como boot-device.
Ahora, si cualquiera de nuestros dispositivos de almacenamiento físico, falla, nuestra información está a salvo, gracias a estas dos tecnologías maravillosas, SVM y ZFS.