После скоропостижной гибели жесткого диска с лежащими на нем зонами, наступило время восстановить их из бекапа и запустить. Казалось, тривиальная процедура, отрепетированная на тестовых системах (но не тех, где лежали зоны – это важно) отняла много времени и поставила несколько вопросов, ответы на которые еще придется поискать.

Восстанавливаем зону из бекапа:

   # zfs send -R backup/zone/develop@rep201108250419 | zfs receive -F vol01/ zone/develop@rep201108250419

Стартуем зону и наблюдаем странное:

   # zoneadm -z develop boot

   zone 'develop': ERROR: no active dataset.
   zone 'develop':
   zoneadm: zone 'develop': call to zoneadmd failed

Ошибка явно говорит о том, что у нас что-то не в порядке со свойствами датасета.

++ Начинаем осмотр датасета

Чтобы было с чем сравнивать, я создал и запустил тестовую зону, свойства ее файловых систем и брал за эталон.

Тестовая зона создается примерно так:

    # zonecfg -z testzone

    testzone: No such zone configured
    Use’create’ to begin configuring a new zone.
    zonecfg:testzone>create
    zonecfg:testzone>set zonepath=/vol01/zone/testzone
    zonecfg:testzone>set autoboot=false
    zonecfg:testzone>add net
    zonecfg:testzone:net>set physical=e1000g4
    zonecfg:testzone:net>set address=192.168.0.24/24
    zonecfg:testzone:net>end
    zonecfg:testzone>verify
    zonecfg:testzone>commit
    zonecfg:testzone>exit

    # zoneadm -z testzone install
    ...

    # zoneadm -z testzone boot

При инсталляции в OpenSolaris/Solaris 11 создаются три датасета (по адресу zonepath):

    # zfs list | grep vol01/zone/testzone

    NAME
    vol01/zone/testzone
    vol01/zone/testzone/ROOT
    vol01/zone/testzone/ROOT/zbe

++ Лечение

    Смотрим полный список свойств датасетов исправной и сломанной зон и сравниваем их:
    
   # zfs get all vol01/zone/testzone

    (сдесь должен быть очень большой вывод, который я пропустил и самое интересное из которого можно увидеть ниже)

    # zfs get all vol01/zone/testzone/ROOT
    ...
    # zfs get all vol01/zone/testzone/ROOT/zbe
    ...
    # zfs get all vol01/zone/develop
    ...
    # zfs get all vol01/zone/develop/ROOT
    ...
    # zfs get all vol01/zone/develop/ROOT/zbe

    ...

Наблюдаем основную разницу в данных свойствах датасета:

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/testzone/ROOT/zbe

    NAME    PROPERTY    VALUE    SOURCE

    vol01/zone/testzone/ROOT/zbe  zoned on inherited from vol01/zone/testzone/ROOT
    vol01/zone/testzone/ROOT/zbe  canmount noauto  local
    vol01/zone/testzone/ROOT/zbe  mountpoint legacy inherited from vol01/zone/testzone/ROOT
    vol01/zone/testzone/ROOT/zbe  org.opensolaris.libbe:parentbe  2aadf62d-9560-e14b-c36a-f9136fbce6e9  local
    vol01/zone/testzone/ROOT/zbe  org.opensolaris.libbe:active on  local

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/develop/ROOT/zbe

    NAME    PROPERTY    VALUE    SOURCE

    vol01/zone/develop/ROOT/zbe  zoned off default
    vol01/zone/develop/ROOT/zbe  canmount on default
    vol01/zone/develop/ROOT/zbe  mountpoint /vol01/zone/develop/ROOT/zbe  default
    vol01/zone/develop/ROOT/zbe  org.opensolaris.libbe:parentbe - -
    vol01/zone/develop/ROOT/zbe  org.opensolaris.libbe:active - -

Исправляем, чтобы было нормально:

    # zfs set zoned=on vol01/zone/develop/ROOT/zbe
    # zfs set canmount=noauto vol01/zone/develop/ROOT/zbe
    # zfs set mountpoint=legacy vol01/zone/develop/ROOT/zbe
    # zfs set org.opensolaris.libbe:parentbe=2aadf62d-9860-e14b-c36a-f9106fbce6e9 vol01/zone/develop/ROOT/zbe
    # zfs set org.opensolaris.libbe:active=on vol01/zone/develop/ROOT/zbe

Аналогично, правим vol01/zone/develop/ROOT после сравнения с работающей зоной:

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/testzone/ROOT

    NAME    PROPERTY    VALUE    SOURCE
    vol01/zone/testzone/ROOT  zoned on local
    vol01/zone/testzone/ROOT  canmount on default
    vol01/zone/testzone/ROOT  mountpoint legacy local
    vol01/zone/testzone/ROOT  org.opensolaris.libbe:parentbe - -
    vol01/zone/testzone/ROOT  org.opensolaris.libbe:active  - -

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/develop/ROOT

    NAME    PROPERTY    VALUE    SOURCE
    vol01/zone/develop/ROOT  zoned off default
    vol01/zone/develop/ROOT  canmount on default
    vol01/zone/develop/ROOT  mountpoint  /vol01/zone/develop/ROOT     default
    vol01/zone/develop/ROOT  org.opensolaris.libbe:parentbe - -
    vol01/zone/develop/ROOT  org.opensolaris.libbe:active - -

   # zfs set zoned=on vol01/zone/develop/ROOT
   # zfs set canmount=on vol01/zone/develop/ROOT

После этого у нас все хорошо: свойства датасетов практически идентичны.

    # zlogin -C develop

    [Connected to zone 'develop' console]
    [NOTICE: Zone booting up]
    SunOS Release 5.11 Version snv_134 64-bit
    Copyright 1983-2010 Sun Microsystems, Inc.  All rights reserved.
    Use is subject to license terms.
    Hostname: develop
    Reading ZFS config: done.
    Mounting ZFS filesystems: (5/5)

    develop console login: mike
    Password:
    Last login: Mon Aug 2 06:41:54 from nostalgia
    Sun Microsystems Inc.   SunOS 5.11      snv_134 February 2010
    (mike@develop)$ su
    Password:
    Aug 27 15:04:13 develop su: ‘su root’ succeeded for mike on /dev/console
    (root@develop)# svcs -xv
    (root@develop)#

++ Вместо послесловия

Если у зоны были смонтированы  из глобальной зоны файловые системы через lofs, будет такой казус - зона загрузиться, но локальные файловые системы не будут смонтированы, сервис filesystem/local:default перейдет в состояние maintenance с ошибкой 262 в логах:  
   /usr/bin/zfs mount -a failed: cannot mount local filesystem.

Проблему можно решить экспортировав и затем импортировав зону

   # zoneadm -z webapp detach
   # zoneadm -z webapp attach

После этого все будет работать нормально.

URL: http://blog.wadmin.ru/2011/08/solaris-zones-troubleshut/
Обсуждается: http://www.opennet.me/tips/info/2620.shtml

• ZFS головного мозга,XPEH, 14:15 , 03-Сен-11
  • ZFS головного мозга,GribNik, 19:42 , 03-Сен-11
  • ZFS головного мозга,Ващенаглухо, 09:21 , 05-Сен-11
    • ZFS головного мозга,GribNik, 17:49 , 05-Сен-11
• Опыт восстановления работы zones в Solaris 11 Express/OpenSolaris,Аноним, 15:20 , 05-Сен-11

> Казалось, тривиальная процедура, отрепетированная на тестовых системах (но не тех, где лежали зоны - это важно) отняла много времени

и поделом

> поставила несколько вопросов, ответы на которые

еще придется поискать

И главный из них: нахрена в этой задаче вообще ZFS, a не проверенные и безотказные gtar или rsync ?

> И главный из них: нахрена в этой задаче вообще ZFS, a не
> проверенные и безотказные gtar или rsync ?

В какой, простите, задаче?

что за gtar или rsync ? нет таких команд в солярисе.
Чел юзает снапшоты и правильно делает, а то что не знал некоторых особенностей ну и что теперь знает.

> что за gtar или rsync ? нет таких команд в солярисе.

Есть rsync точно (возможно не идет в базовой поставке с дистром, но в оф. репозиториях точно должна быть), я его юзаю когда есть задача синхронизации на файловом уровне, причем файлы могут быть на разных ФС. Но бывают задачи исключительно под ZFS, если фантазировать, то навскидку: через iscsi на zfs раздается volume размером 300 Гб, на котором лежит диск для виртуалки, на диске файлы БД размером 250 Гб. Как обеспечить резервное копирование БД с каждые 10 минут, и сократить окно бекапа до 5 минут? В ZFS это решается на раз снапшотами, так как инкрементный снапшот забекапит ИЗМЕНЕННЫЕ блоки виртуального диска only. И не будет переписывать каждый раз 300 Гб виртуального диска при обном изменившемся блоке. Кстати, буду очень признателен если кто-нибудь скажет, чем реализовать такое по-блочное копирование под CentOS?
    

ХРЕН,

дело в следующем. Зоны в Солярисе в принципе заточены под ZFS. Там даже аналог телепортации есть - но только если зона на датасете ZFS. Смекаешь?