Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 17 de septiembre de 2011
Hace un año instalé una máquina Solaris con múltiples zonas. El esquema ha funcionado muy bien durante este tiempo. No obstante, aunque la configuración que utilicé está soportada por Sun/Oracle, lo cierto es que no puedo utilizar las grandes ventajas de "Live Upgrade" y diferentes "Boot Environments".
Al principio era un problema con algunos bugs de Solaris, pero ha pasado año y medio, y estos bugs parece que ya se han solucionado en versiones recientes del sistema operativo.
En los últimos días, cansado de los inconvenientes, he dedicado algo de tiempo a hacer experimentos con máquinas virtuales, para identificar y, en lo posible, solucionar estos problemas. Quiero poder utilizar "Live Upgrade" y "Boot Environments" de forma normal y rutinaria. Tras un considerable número de experimentos, he llegado a la conclusión de que, con un pequeño cambio en mi configuración, puedo solucionar los problemas.
La situación es la siguiente: tengo una máquinas Solaris con múltiples Zonas. La configuración ZFS es:
datos /datos datos/ROOT legacy datos/ROOT/Solaris10u7 /.alt.Solaris10u7 datos/ROOT/Solaris10u7/var /var datos/dump - datos/home /home datos/swap - datos/usr_local /usr/local datos/zones /datos/zones datos/zones/babylon5 /datos/zones/babylon5 datos/zones/babylon5/dataset /datos datos/zones/babylon5/dataset/* [...] datos/zones/stargate /datos/zones/stargate datos/zones/stargate/dataset /datos datos/zones/stargate/dataset/* [...]
Como puede verse, tengo un "dataset" "zones" en el que residen los "datasets" de las zonas. Cada zona tiene, a su vez, un "dataset" delegado dentro de la zona, que puede gestionarse dentro de ella para crear "datasets" adicionales locales a la zona.
La clave del asunto es el "dataset" "zones", padre de las zonas. Es un "dataset" flotante, no asignado a ningún "BE" ("Boot Environment") concreto. Ese es el problema, porque cuando se clonan las zonas al crear un nuevo "dataset", se intentan montar debajo del "dataset" común "zones", creando conflictos, duplicaciones, etc.
La solución es que "zones" resida bajo los "BE", de forma que cuando clonamos un "BE" nuevo, el punto de montaje de sus zonas sea diferente.
Una complicación extra son los "datasets" delegados, que no queremos clonar (los datos de las zonas se compartirán entre los "BE"). Entonces debemos desvincular los "datasets" delegados del "dataset" de la zona.
Dado que esta máquina está en producción, cualquier cambio debe impactar la disponibilidad del servicio lo menos posible, y debe ser reversible de forma rápida si surgen problemas.
En una primera fase voy a actuar sobre la zona "babylon5", ya que es una zona que puedo parar durante unos minutos sin levantar demasiadas ampollas.
Ya he mostrado más arriba cuál es mi configuración ZFS. La configuración de esa zona Solaris concreta es:
# cat /etc/zones/babylon5.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE zone PUBLIC "-//Sun Microsystems Inc//DTD Zones//EN" "file:///usr/share/lib/xml/dtd/zonecfg.dtd.1">
<!--
DO NOT EDIT THIS FILE. Use zonecfg(1M) instead.
-->
<zone name="babylon5" zonepath="/datos/zones/babylon5" autoboot="true">
<<nherited-pkg-dir directory="/lib"/>
<inherited-pkg-dir directory="/platform"/>
<inherited-pkg-dir directory="/sbin"/>
<inherited-pkg-dir directory="/usr"/>
<inherited-pkg-dir directory="/opt"/>
<filesystem special="/usr/local" directory="/usr/local" type="lofs">
<fsoption name="ro"/>
<fsoption name="nodevices"/>
</filesystem>
<network address="xx.xx.xx.xx/24" physical="gani0" defrouter="xx.xx.xx.254"/>
<dataset name="datos/zones/babylon5/dataset"/>
<network address="192.168.69.1/24" physical="gani0"/>
</zone>
Primero paramos la zona
# zoneadm -z babylon5 halt # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 1 stargate running /datos/zones/stargate native shared - babylon5 installed /datos/zones/babylon5 native shared
Creamos el "dataset" contenedor dentro del "BE", y le ponemos los atributos necesarios para que todo funcione bien. Le meto compresión cañera, porque yo soy así de guay :-) :
# zfs create datos/ROOT/Solaris10u7/zones # zfs set canmount=noauto datos/ROOT/Solaris10u7/zones # zfs set compression=gzip-9 datos/ROOT/Solaris10u7/zones # zfs get all datos/ROOT/Solaris10u7/zones NAME PROPERTY VALUE SOURCE datos/ROOT/Solaris10u7/zones type filesystem - datos/ROOT/Solaris10u7/zones creation Tue Oct 5 4:05 2010 - datos/ROOT/Solaris10u7/zones used 21K - datos/ROOT/Solaris10u7/zones available 558G - datos/ROOT/Solaris10u7/zones referenced 21K - datos/ROOT/Solaris10u7/zones compressratio 1.00x - datos/ROOT/Solaris10u7/zones mounted yes - datos/ROOT/Solaris10u7/zones quota none default datos/ROOT/Solaris10u7/zones reservation none default datos/ROOT/Solaris10u7/zones recordsize 128K default datos/ROOT/Solaris10u7/zones mountpoint /.alt.Solaris10u7/zones inherited from datos/ROOT/Solaris10u7 datos/ROOT/Solaris10u7/zones sharenfs off default datos/ROOT/Solaris10u7/zones checksum on default datos/ROOT/Solaris10u7/zones compression gzip-9 local datos/ROOT/Solaris10u7/zones atime on default datos/ROOT/Solaris10u7/zones devices on default datos/ROOT/Solaris10u7/zones exec on default datos/ROOT/Solaris10u7/zones setuid on default datos/ROOT/Solaris10u7/zones readonly off default datos/ROOT/Solaris10u7/zones zoned off default datos/ROOT/Solaris10u7/zones snapdir hidden default datos/ROOT/Solaris10u7/zones aclmode groupmask default datos/ROOT/Solaris10u7/zones aclinherit restricted default datos/ROOT/Solaris10u7/zones canmount noauto local datos/ROOT/Solaris10u7/zones shareiscsi off default datos/ROOT/Solaris10u7/zones xattr on default datos/ROOT/Solaris10u7/zones copies 1 default datos/ROOT/Solaris10u7/zones version 4 - datos/ROOT/Solaris10u7/zones utf8only off - datos/ROOT/Solaris10u7/zones normalization none - datos/ROOT/Solaris10u7/zones casesensitivity sensitive - datos/ROOT/Solaris10u7/zones vscan off default datos/ROOT/Solaris10u7/zones nbmand off default datos/ROOT/Solaris10u7/zones sharesmb off default datos/ROOT/Solaris10u7/zones refquota none default datos/ROOT/Solaris10u7/zones refreservation none default datos/ROOT/Solaris10u7/zones primarycache all default datos/ROOT/Solaris10u7/zones secondarycache all default datos/ROOT/Solaris10u7/zones usedbysnapshots 0 - datos/ROOT/Solaris10u7/zones usedbydataset 21K - datos/ROOT/Solaris10u7/zones usedbychildren 0 - datos/ROOT/Solaris10u7/zones usedbyrefreservation 0 -
Ahora movemos la jerarquía de "datasets" de la zona fuera del "BE", y la zona "babylon5" dentro del "dataset" en el "BE". Antes de hacer todo esto, es muy buena idea hacer un "snapshot" recursivo del "pool" ZFS, por lo que pudiera pasar:
# zoneadm -z babylon5 detach # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 1 stargate running /datos/zones/stargate native shared - babylon5 configured /datos/zones/babylon5 native shared # zonecfg -z babylon5 delete Are you sure you want to delete zone babylon5 (y/[n])? y # zfs create -o mountpoint=/zones-datasets datos/zones-datasets # zfs set canmount=noauto datos/zones/babylon5 # zfs umount datos/zones/babylon5 # zfs inherit zoned datos/zones/babylon5/dataset # zfs set canmount=noauto datos/zones/babylon5/dataset # zfs rename datos/zones/babylon5/dataset datos/zones-datasets/babylon5 # zfs rename datos/zones/babylon5 datos/ROOT/Solaris10u7/zones/babylon5 # zfs set mountpoint=/zones datos/ROOT/Solaris10u7/zones # zfs mount datos/ROOT/Solaris10u7/zones # zfs inherit mountpoint datos/ROOT/Solaris10u7/zones/babylon5 # zfs mount datos/ROOT/Solaris10u7/zones/babylon5 # zfs get mountpoint datos/ROOT/Solaris10u7/zones/babylon5 NAME PROPERTY VALUE SOURCE datos/ROOT/Solaris10u7/zones/babylon5 mountpoint /zones/babylon5 inherited from datos/ROOT/Solaris10u7/zones # ls -la /zones/babylon5 total 117 drwx------ 5 root root 7 Oct 5 04:31 . drwx------ 6 root root 6 Sep 30 14:50 .. -rw-r--r-- 1 root root 2079490 Oct 5 04:31 SUNWdetached.xml drwxr-xr-x 12 root root 51 Oct 5 03:55 dev drwxr-xr-x 2 root root 2 Jul 28 2009 lu -rw-r--r-- 1 root root 12 May 6 04:35 lu_moved drwxr-xr-x 40 root root 53 Sep 30 15:00 root (Editamos "/zones/babylon5/SUNWdetached.xml" y cambiamos el "dataset" a <dataset name="datos/zones-datasets/babylon5"/>) # zonecfg -z babylon5 babylon5: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:babylon5> create -a /zones/babylon5 zonecfg:babylon5> commit zonecfg:babylon5> exit # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 1 stargate running /datos/zones/stargate native shared - babylon5 configured /zones/babylon5 native shared # zoneadm -z babylon5 attach -u Getting the list of files to remove Removing 0 files Remove 6 of 6 packages Installing 22 files Add 15 of 15 packages Updating editable files The file within the zone contains a log of the zone update. # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 1 stargate running /datos/zones/stargate native shared - babylon5 installed /zones/babylon5 native shared # zoneadm -z babylon5 boot # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 1 stargate running /datos/zones/stargate native shared 10 babylon5 running /datos/zones/babylon5 native shared
El "zfs inherit zoned datos/zones/babylon5/dataset" es para desactivar el atributo "zoned" del "dataset", de forma que nos permita moverlo. Se trata de un atributo "sticky" que se activa cuando se importa un "dataset" en una zona, y que se utiliza para varias comprobaciones de seguridad en el kernel. Por ejemplo que si montamos en la zona global ese "dataset", potencialmente manipulado de forma maliciosa, no tengamos un compromiso de seguridad. Una vez puesto, el atributo no se desactiva nunca automáticamente. Hay que hacerlo de forma manual.
La cosa tiene buena pinta. Nos conectamos a la zona y verificamos que todo parece funcionar correctamente. Tenemos un problema la raíz del "dataset", que la habíamos indicado como "canmount=noauto". Ahora debemos cambiarlo, haciendo en "babylon5":
# zfs set canmount=on datos/zones-datasets/babylon5 # init 6
Cuando la zona arranque dará un error de que "/datos" no se puede montar porque el directorio no está vacío. Para solucionarlo, volvemos a parar la zona y, en la zona global, nos vamos a "/datos/zones/babylon5/root" y comprobamos que podemos eliminar el directorio "datos" y lo que contenga (deberían ser directorios vacíos). Una vez hecho eso, podemos arrancar la zona de forma normal, con "zoneadm -z babylon5 boot".
Para mayor seguridad, deberíamos reiniciar el servidor por completo, para asegurarnos de que la zona se lanza como debe.
Ahora debemos migrar la zona "stargate", que es la principal y la que nos interesa que esté menos tiempo fuera de servicio. La tarea debería completarse en menos tiempo que para "babylon5", porque algunos pasos ya no habrá que hacerlos, y el proceso ya está "depurado":
# zoneadm -z stargate halt # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 2 babylon5 running /zones/babylon5 native shared - stargate installed /datos/zones/stargate native shared # zoneadm -z stargate detach # zonecfg -z stargate delete Are you sure you want to delete zone stargate (y/[n])? y # zfs set canmount=noauto datos/zones/stargate # zfs umount datos/zones/stargate # zfs inherit zoned datos/zones/stargate/dataset # zfs set canmount=noauto datos/zones/stargate/dataset # zfs rename datos/zones/stargate/dataset datos/zones-datasets/stargate # zfs rename datos/zones/stargate datos/ROOT/Solaris10u7/zones/stargate # zfs inherit mountpoint datos/ROOT/Solaris10u7/zones/stargate # zfs mount datos/ROOT/Solaris10u7/zones/stargate # zfs get mountpoint datos/ROOT/Solaris10u7/zones/stargate NAME PROPERTY VALUE SOURCE datos/ROOT/Solaris10u7/zones/stargate mountpoint /zones/stargate inherited from datos/ROOT/Solaris10u7/zones (Editamos "/zones/stargate/SUNWdetached.xml" y cambiamos el "dataset" a <dataset name="datos/zones-datasets/stargate"/>) # zonecfg -z stargate stargate: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:stargate> create -a /zones/stargate zonecfg:stargate> commit zonecfg:stargate> exit # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 2 babylon5 running /zones/babylon5 native shared - stargate configured /zones/stargate native shared # zoneadm -z stargate attach -u Getting the list of files to remove Removing 0 files Remove 6 of 6 packages Installing 22 files Add 15 of 15 packages Updating editable files The file within the zone contains a log of the zone update. # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 2 babylon5 running /zones/babylon5 native shared - stargate installed /zones/stargate native shared # zoneadm -z stargate boot # zoneadm list -icv ID NAME STATUS PATH BRAND IP 0 global running / native shared 2 babylon5 running /zones/babylon5 native shared 7 stargate running /zones/stargate native shared
Nos conectamos a la zona y verificamos que todo parece funcionar correctamente. Tenemos un problema la raíz del "dataset", que la habíamos indicado como "canmount=noauto". Ahora debemos cambiarlo, haciendo en "stargate":
# zfs set canmount=on datos/zones-datasets/stargate # init 6
En este caso no hay problema al arrancar la zona, porque no se montan "datasets" directamente colgando del contenedor.
Para mayor seguridad, deberíamos reiniciar el servidor por completo, para asegurarnos de que la zona se lanza como debe.
En total, migrar la zona "stargate", completar su configuración, reiniciar la máquina completa y verificar que todo funciona, nos ha supuesto 15 minutos exactos.
La configuración ZFS final es:
NAME USED AVAIL REFER MOUNTPOINT datos 120G 557G 257M /datos datos/ROOT 19.5G 557G 18K legacy datos/ROOT/Solaris10u7 19.5G 557G 4.15G /.alt.Solaris10u7 datos/ROOT/Solaris10u7/var 4.18G 557G 3.71G /var datos/ROOT/Solaris10u7/zones 10.4G 557G 24K /zones datos/ROOT/Solaris10u7/zones/babylon5 1.29G 557G 689M /zones/babylon5 datos/ROOT/Solaris10u7/zones/stargate 9.11G 557G 1.80G /zones/stargate datos/dump 4.00G 557G 4.00G - datos/home 1.67M 557G 884K /home datos/swap 32G 582G 7.67G - datos/usr_local 7.36G 557G 4.75G /usr/local datos/zones 384K 500G 22K /datos/zones datos/zones-datasets 56.5G 557G 21K /zones-datasets datos/zones-datasets/babylon5 40.9G 557G 47K /datos datos/zones-datasets/babylon5/* [...] datos/zones-datasets/stargate 15.6G 557G 39.5K /datos datos/zones-datasets/stargate/* [...]
La prueba de fuego ahora será crear un nuevo "BE" y arrancar con él. Todos los cambios realizados están dirigidos a este objetivo:
# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
Solaris10u7 yes yes yes no -
# lucreate -n Solaris10u7BACKUP
Checking GRUB menu...
System has findroot enabled GRUB
Analyzing system configuration.
Comparing source boot environment <Solaris10u7> file systems with the file
system(s) you specified for the new boot environment. Determining which
file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Updating system configuration files.
Creating configuration for boot environment <Solaris10u7BACKUP>.
Source boot environment is <Solaris10u7>.
Creating boot environment <Solaris10u7BACKUP>.
Cloning file systems from boot environment <Solaris10u7> to create boot environment <Solaris10u7BACKUP>.
Creating snapshot for <datos/ROOT/Solaris10u7> on <datos/ROOT/Solaris10u7@Solaris10u7BACKUP>.
Creating clone for <datos/ROOT/Solaris10u7@Solaris10u7BACKUP> on <datos/ROOT/Solaris10u7BACKUP>.
Setting canmount=noauto for </> in zone <global> on <datos/ROOT/Solaris10u7BACKUP>.
Creating snapshot for <datos/ROOT/Solaris10u7/var> on <datos/ROOT/Solaris10u7/var@Solaris10u7BACKUP>.
Creating clone for <datos/ROOT/Solaris10u7/var@Solaris10u7BACKUP> on <datos/ROOT/Solaris10u7BACKUP/var>.
Setting canmount=noauto for </var> in zone <global> on <datos/ROOT/Solaris10u7BACKUP/var>.
Creating snapshot for <datos/ROOT/Solaris10u7/zones> on <datos/ROOT/Solaris10u7/zones@Solaris10u7BACKUP>.
Creating clone for <datos/ROOT/Solaris10u7/zones@Solaris10u7BACKUP> on <datos/ROOT/Solaris10u7BACKUP/zones>.
Setting canmount=noauto for </zones> in zone <global> on <datos/ROOT/Solaris10u7BACKUP/zones>.
Creating snapshot for <datos/ROOT/Solaris10u7/zones/stargate> on <datos/ROOT/Solaris10u7/zones/stargate@Solaris10u7BACKUP>.
Creating clone for <datos/ROOT/Solaris10u7/zones/stargate@Solaris10u7BACKUP> on <datos/ROOT/Solaris10u7BACKUP/zones/stargate-Solaris10u7BACKUP>.
Creating snapshot for <datos/ROOT/Solaris10u7/zones/babylon5> on <datos/ROOT/Solaris10u7/zones/babylon5@Solaris10u7BACKUP>.
Creating clone for <datos/ROOT/Solaris10u7/zones/babylon5@Solaris10u7BACKUP> on <datos/ROOT/Solaris10u7BACKUP/zones/babylon5-Solaris10u7BACKUP>.
Saving existing file </boot/grub/menu.lst> in top level dataset for BE <Solaris10u7BACKUP> as <mount-point>//boot/grub/menu.lst.prev.
File </boot/grub/menu.lst> propagation successful
Copied GRUB menu from PBE to ABE
No entry for BE <Solaris10u7BACKUP> in GRUB menu
Population of boot environment <Solaris10u7BACKUP> successful.
Creation of boot environment <Solaris10u7BACKUP> successful.
# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
Solaris10u7 yes yes yes no -
Solaris10u7BACKUP yes no no yes -
# luactivate Solaris10u7BACKUP
System has findroot enabled GRUB
Generating boot-sign, partition and slice information for PBE <Solaris10u7>
A Live Upgrade Sync operation will be performed on startup of boot environment <Solaris10u7BACKUP>.
Generating boot-sign for ABE <Solaris10u7BACKUP>
Generating partition and slice information for ABE <Solaris10u7BACKUP>
Copied boot menu from top level dataset.
Generating multiboot menu entries for PBE.
Generating multiboot menu entries for ABE.
Disabling splashimage
Re-enabling splashimage
No more bootadm entries. Deletion of bootadm entries is complete.
GRUB menu default setting is unaffected
Done eliding bootadm entries.
**********************************************************************
The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
target BE.
**********************************************************************
In case of a failure while booting to the target BE, the following process
needs to be followed to fallback to the currently working boot environment:
1. Boot from Solaris failsafe or boot in single user mode from the Solaris
Install CD or Network.
2. Mount the Parent boot environment root slice to some directory (like
/mnt). You can use the following command to mount:
mount -Fzfs /dev/dsk/c2d0s0 /mnt
3. Run <luactivate> utility with out any arguments from the Parent boot
environment root slice, as shown below:
/mnt/sbin/luactivate
4. luactivate, activates the previous working boot environment and
indicates the result.
5. Exit Single User mode and reboot the machine.
**********************************************************************
Modifying boot archive service
Propagating findroot GRUB for menu conversion.
File </etc/lu/installgrub.findroot> propagation successful
File </etc/lu/stage1.findroot> propagation successful
File </etc/lu/stage2.findroot> propagation successful
File </etc/lu/GRUB_capability> propagation successful
Deleting stale GRUB loader from all BEs.
File </etc/lu/installgrub.latest> deletion successful
File </etc/lu/stage1.latest> deletion successful
File </etc/lu/stage2.latest> deletion successful
Activation of boot environment <Solaris10u7BACKUP> successful.
# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
Solaris10u7 yes yes no no -
Solaris10u7BACKUP yes no yes no -
Ahora cruzamos los dedos y reiniciamos.
Tras arrancar, comprobamos que todo funciona bien, que es el caso. ¡¡Estupendo!!. Nos aseguramos de que estamos ejecutando el "BE" que queríamos:
# lustatus Boot Environment Is Active Active Can Copy Name Complete Now On Reboot Delete Status -------------------------- -------- ------ --------- ------ ---------- Solaris10u7 yes no no yes - Solaris10u7BACKUP yes yes yes no -
Existen aún un par de detallitos a corregir, ocasionados por bugs en las viejas versiones de "Live Upgrade". No debería ser problema en actualizaciones futuras, porque ya están corregidos. Lo que queremos es que todos los "paths" de los "datasets" asociados a "BE" concretos sean relativos a tu "root":
# zfs get mountpoint datos/ROOT/Solaris10u7 NAME PROPERTY VALUE SOURCE datos/ROOT/Solaris10u7 mountpoint /.alt.Solaris10u7 local # zfs get mountpoint datos/ROOT/Solaris10u7BACKUP NAME PROPERTY VALUE SOURCE datos/ROOT/Solaris10u7BACKUP mountpoint / local # zfs set mountpoint=/ datos/ROOT/Solaris10u7 # zfs inherit mountpoint datos/ROOT/Solaris10u7/var # zfs inherit mountpoint datos/ROOT/Solaris10u7/zones # zfs get -r mountpoint datos/ROOT/Solaris10u7BACKUP|grep -v @ NAME PROPERTY VALUE SOURCE datos/ROOT/Solaris10u7BACKUP mountpoint / local datos/ROOT/Solaris10u7BACKUP/var mountpoint /var inherited from datos/ROOT/Solaris10u7BACKUP datos/ROOT/Solaris10u7BACKUP/zones mountpoint /zones inherited from datos/ROOT/Solaris10u7BACKUP datos/ROOT/Solaris10u7BACKUP/zones/babylon5 mountpoint /zones/babylon5 local datos/ROOT/Solaris10u7BACKUP/zones/stargate mountpoint /zones/stargate local # zfs get -r mountpoint datos/ROOT/Solaris10u7|grep -v @ NAME PROPERTY VALUE SOURCE datos/ROOT/Solaris10u7 mountpoint / local datos/ROOT/Solaris10u7/var mountpoint /var inherited from datos/ROOT/Solaris10u7 datos/ROOT/Solaris10u7/zones mountpoint /zones inherited from datos/ROOT/Solaris10u7 datos/ROOT/Solaris10u7/zones/babylon5-Solaris10u7 mountpoint /zones/babylon5-Solaris10u7 local datos/ROOT/Solaris10u7/zones/stargate-Solaris10u7 mountpoint /zones/stargate-Solaris10u7 local
Parece que todo está en su sitio. Probamos "lumount" para comprobar que podemos acceder a los datos de otros "BE" sin problemas.
También podemos eliminar el viejo "dataset" que hacía de contenedor de zonas. Naturalmente habrá que borrar todos sus "snapshots" también:
# zfs destroy datos/zones cannot destroy 'datos/zones': filesystem has children use '-r' to destroy the following datasets: datos/zones@20090801-00:50 datos/zones@20090826-01:58 datos/zones@20090922-21:16 datos/zones@20091001-15:02 datos/zones@20091016-14:10 datos/zones@20091025-07:18 datos/zones@20091030-22:06 datos/zones@20091119-00:37 datos/zones@20091123-19:57 datos/zones@20091203-23:59 datos/zones@20091218-23:01 datos/zones@20091228-20:51 datos/zones@20100102-15:43 datos/zones@20100118-22:12 datos/zones@20100201 datos/zones@20100205-21:27 datos/zones@20100219 datos/zones@20100301 datos/zones@20100313-21:46 datos/zones@20100319-03:02 datos/zones@20100401-02:53 datos/zones@20100502 datos/zones@20100518 datos/zones@20100601-22:15 datos/zones@20100623 datos/zones@20100701-04:35 datos/zones@20100711-05:44 datos/zones@20100720-05:13 datos/zones@20100723-18:56 datos/zones@20100726-14:17 datos/zones@20100801-15:17 datos/zones@20100802-20:06 datos/zones@20100809-01:13 datos/zones@20100818-04:25 datos/zones@20100901-01:36 datos/zones@20100928-13:46 datos/zones@20100930-14:40 datos/zones@20101001-19:57 datos/zones@20101004-13:03 datos/zones@20101005-04:40 # zfs destroy -r datos/zones
Activamos la zona original, reiniciamos la máquina y nos vamos a dormir tranquilos.
Una vez pasados unos días y habiendo comprobado que todo funciona a la perfección, actualizamos los procedimientos de copia de seguridad y snapshots ZFS periódicos para reflejar la nueva situación, y nos olvidamos de todo este asunto.
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
