Skip to main content

И снова простота от ZFS с Solaris Kernel Zones / LDOMs

Продолжаем ранее начатый монолог про простоту ZFS и функционал, который может доставить некоторые проблемы в реальной эксплуатации, короче, очередной занудный пост о пользе снэпшотов и вреде от упрощения администрирования. Правильно делать вот так, мы же сделаем все неправильно! 🙂

Далее, чтобы не бегать по тексту, и читать напрасные слова, эта заметка – просто маленькое предостережение админам, я лично сам такие вот странности воспринимаю как нюансы и не особо заморачиваюсь насчет возможных последствий, используя все предоставленные в распоряжение механизмы (мгновенные снимки на ZFS обычно полезно делать, даже перед изменением банальных параметров, есть лишь ряд очень ограниченных ситуаций, когда использование снимков на ZFS приведет к возможной остановке приложения). Важно четко понимать, каким образом себя можно подстраховать, ну а мне же всегда интересно разгребать такие ситуации на живых системах (к сожалению, в некоторых случаях констатируя потерю данных).

Нужно: увеличить размер rpool в Solaris Kernel Zone (или гостевой домен – не суть важно – главное zvol “внизу” и поверх него rpool в “гостевой” ОС).

Дабы не возится с real life example, делаем стенд, который прост и понятен:

zonecfg -z testkz create -t SYSsolaris-kz
zoneadm -z testkz install
echo select capped-memory \\nset physical=2g \\nend \\ncommit | zonecfg -z testkz
zoneadm -z testkz boot
zlogin -C testkz

Далее жмем на кнопки до завершения инсталляции по инструкции, по вкусу добрасывая настроек (не нужно на стенде).

По умолчанию создается следующая структура:

root@snooky:~# zfs list -r rpool/VARSHARE/zones/testkz
NAME USED AVAIL REFER MOUNTPOINT
rpool/VARSHARE/zones/testkz 16.5G 194G 31K /system/zones/testkz
rpool/VARSHARE/zones/testkz/disk0 16.5G 208G 2.62G -

Искомые ~16Gb (особо придирчивые до цифирей могут заметить некоторые детали, но разговор сейчас не о них)…

На этом этапе мы не поленимся и сделаем следующее:

zoneadm -z testkz halt
zfs snapshot rpool/VARSHARE/zones/testkz/disk0@coldanddark
zoneadm -z testkz boot

NB на полях – на все команды потрачено не более 5 минут + 40 минут к инсталляции из удаленного репозитория. К вопросу – “а надо ли проверять?”. Надо, это просто – и быстро.

Хотим увеличить диск в контейнере до 32 гигабайт:
zfs set volsize=32<strong>m</strong> rpool/VARSHARE/zones/testkz/disk0

Упс… Одну букву как подменили. Не всем очевидно, чаще всего ошибаются с недостающим нулем.

root@testkz:~# prstWARNING: zvblk_win_complete: IO operation failed(op=1)
WARNING: zvblk_win_complete: IO operation failed(op=1)
WARNING: zvblk_win_complete: IO operation failed(op=1)
WARNING: zvblk_win_complete: IO operation failed(op=1)
WARNING: zvblk_win_complete: IO operation failed(op=1)
WARNING: zvblk_win_complete: IO operation failed(op=1)

Все… То есть – совсем все:

root@snooky:~# zoneadm -z testkz halt
zone 'testkz': error: failed to write hostdata to all boot devices
zone 'testkz': error: /dev/zvol/rdsk/rpool/VARSHARE/zones/testkz/disk0: Could not write to device or file
zoneadm: zone testkz: call to zoneadmd(1M) failed: zoneadmd(1M) returned an error 9 (zone state change failed)

Что любопытно (практически – понятно, но – любопытно):

root@snooky:~# zfs rollback -f rpool/VARSHARE/zones/testkz/disk0@coldanddark
cannot rollback 'rpool/VARSHARE/zones/testkz/disk0': volume is busy

На “живой” зоне финт с rollback не прокатывает (а volsize – пожалуйста)…

Мораль сей басни такова:

  1. RTFM!! Все ходы записаны в т.н. руководствах пользователя, Managing ZFS File Systems. ИМХО, формулировка Use extreme care when adjusting the volume size не совсем полностью раскрывает (я бы сказал – не раскрывает вовсе) глубину попадания в густое и темное в случае неверных действий, но тем не менее сие должно хотя бы насторожить внимательного читателя и заставить провести вдумчивые натурные эксперименты, благо цена им – почти нулевая даже на продуктовой системе (да-да, именно так).
  2. Внимательно следить за собственными шаловливыми руками. Хорошая народная практика “семь раз отмерь, один раз отрежь” хорошо показывает всю суть проблемы, и даже если очень хочется нажать Enter после ввода гарантированно правильной (единственно правильной!) – можно потешить себя дополнительным символом #   в начале 😉

На закуску – кусок паники, просто для разнообразия (суть panic string может быть и другой):

Dec 21 10:27:27 testkz zvblk: WARNING: zvblk_win_complete: IO operation failed(op=2)
Dec 21 10:27:27 testkz last message repeated 23 times
Dec 21 10:27:27 testkz zvblk: WARNING: zvblk_win_complete: IO operation failed(op=1)
Dec 21 10:27:27 testkz last message repeated 1 time
Dec 21 10:27:27 testkz zvblk: WARNING: zvblk_win_complete: IO operation failed(op=2)

panic[cpu3]/thread=fffffffc802c1b40: assertion failed: zap\_add(os, DMU\_POOL\_DIRECTORY\_OBJECT, DMU\_POOL\_BPMAP\_DEFER, sizeof (uint64\_t), 1, &bm->bm\_defer\_obj, tx) == 0 (0x32 == 0x0), file: ../../common/fs/zfs/bpmap.c, line: 691

fffffffc802c18a0 genunix:zone\_default\_initname+12a594 ()  
fffffffc802c18f0 zfs:bpmap\_start\_populating+131 ()  
fffffffc802c1950 zfs:dsl\_scan\_setup_sync+1b1 ()  
fffffffc802c19b0 zfs:dsl\_scan\_sync+8c ()  
fffffffc802c1a80 zfs:spa_sync+458 ()  
fffffffc802c1b20 zfs:txg\_sync\_thread+244 ()  
fffffffc802c1b30 unix:thread_start+8 ()

syncing file systems&#8230; done  
dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel sections: zfs  
0:00 93% done (kernel)  
0:00 100% done (zfs)  
100% done: 164093 (kernel) + 10915 (zfs) pages dumped, dump succeeded  
rebooting&#8230;  
System would not fast reboot because:  
fastreboot_capable not set  
newkernel not valid  
newkernel checksum not valid  
fastreboot_onpanic is not set  
Driver zvcntrl should quiesce  
Driver zvblk should quiesce  
Driver zvnet should quiesce  
Driver zvsdir should quiesce

[NOTICE: Zone rebooting]

PANIC: zvboot: Cannot determine boot device from &#8216;disk0&#8217;.

[NOTICE: Zone halted]