Команда UNMAP стандартизирована в рамках набора команд T10 SCSI и используется для высвобождения пространства из тонких лунов назад хрнилищу данных в SAN окружении. Как я писал ранее, протоколы SAN и NAS понемногу заимствуют друг у друга всё лучшее. Одна из полезных вещей которая появилась достаточно давно, это возможность обратной связи СХД и хоста, для того чтобы «возвращать» удалённые блоки в тонкий лун, чего раньше так не хватало в SAN. Функцией UNMAP по-прежнему мало кто пользуется в SAN окружении, хотя она очень полезна в сочетании как с виртуализированными так и не виртуализированными средами.
Без поддержки команды UNMAP любой тонкий лун созданный на стороне СХД всегда мог только увеличиваться в размере. Его рост был вопросом времени, который безоговорочно всегда заканчивался тем, что такой тонкий лун в конце концов станет занимать свой полный объём, который ему положен, т.е. в конце концов он станет толстым.
Вот представьте у вас на датасторе живут 3 виртуальные машины, каждая занимает 100GB. Ваш датастор находится на тонком луне, который занимает 300GB. Занимаемое пространство со стороны СХД и ESXi одинаковое: 300GB. После удаления одной ВМ, размер вашего луна со стороны СХД по-прежнему 300GB, а со стороны гипервизора занимаемое пространство на датасторе живущем на этом луне 200GB.
Связанно это с тем, что ране не было механизма обратной связи хоста с СХД. А именно, когда хост записывал блок информации в луне, СХД в свою очередь помечала этот блок как используемый. Далее хост мог удалить этот блок, но система хранения уже об этом не знала. Команда UNMAP и есть эта обратная связь, которая отмапливает уже не нужный блок с луна. Наконец-то наш тонкий лун научился не только набирать, но и уменьшать свой вес начиная с версии прошивки (Clustered Data) ONTAP 8.2.
В версии 5.0 функция UNMAP впервые была представлена, включена она была по умолчанию и автоматически запускалась при достижении заданного значения удалённых блоков, в последующих версиях механизм отключён по умолчанию и запускается вручную. Начиная с VMFS-6 (vSphere 6.5) высвобождение пространства происходит автоматически в течении 12 часов, при необходимости ручной механизм запуска высвобождения пространства также доступен. Важно отметить, что высвобождение пространства, о котором сейчас пойдёт речь происходит на уровне гипервизора, т.е. высвобождение удалённых блоков происходит только после удаления виртуальной машины или виртуальных дисков целиком, а не внутри гостевой ОС.
Если у вас уже есть ESXi и СХД с ONTAP с поддержкой UNMAP, но функция не включена
Нужно её включить со стороны СХД и со стороны гипервизора. Начнём с того, что переведём лун в оффлайн и включим функцию space-allocation на СХД (если там остались ВМ в запущенном состоянии, они завершат работу некорректно и возможно будут повреждены, так что их стоит или временно выключить, или временно мигрировать):
После чего нужно включить unmap со стороны ESXi, для этого нужно отмапить и примапить датастор, чтобы ESXi обнаружил поддержку UNMAP (если там остались ВМ в запущенном состоянии, они завершат работу некорректно и возможно будут повреждены, так что их стоит или временно выключить или временно мигрировать):
После этого, чтобы высвобождать пространство, нужно будет периодически запускать команду:
Важно отметить, что UNMAP работает только для лунов отформатированных со смещением партиции кратное 1 MB. Что это значит? Это значит, что, если вы когда-то конвертировали VMFS3 в VMFS5, UNMAP работать не будет. Проверить это просто, конвертированные VMFS3 имеют таблицу разбивки MBR, а VMFS5 которые были созданы заново имеют разбивку GPT.
Обратите внимение на колонку Layout.
Проверить смещение тоже не сложно, смотрим на длинну сектора. Напомню сектор равен 512 байтам.
Обратите внимание на колонки «Start Sector» и «End Sector». Итак, последнее устройство naa.60a98000486e574f6c4a5052537a7375 имеет смещение 1MB (2048 сектора*512 =1048576 byte = 1024KB). А вот второе устройство naa.60a98000486e574f6c4a5778594e7456 имеет смещение которое не кратно 1MB, оно явно меньше, UNMAP на нем работать не будет.
Проверить поддерживается ли UNMAP (Delete Status) можно так:
Автоматическое высвобождение пространства назад в тонкий лун на СХД поддерживается начиная с vSphere 6.5. Для каждого VMFS-6 датастора можно назначать приоритет высвобождения пространства High/Mid/Slow, которое будет возвращено хранилищу в течении 12 часов. Запуск высвобождения пространства и настройку приоритизаци для VMFS-6 датастора можно также выполнить вручную из графического интерфейса или из командной строки.
Итак, ранее мы рассмотрели удаление виртуальных машин из датастора. Логично было бы сделать тоже самое при удалении блоков данных изнутри гостевой ОС, а не целиком виртуальной машины или её дисков. UNMAP поддерживается на стороне СХД с ONTAP и для того, чтобы работал механизм UNMAP при удалении данных с VMDK, т.е. изнутри гостевой ОС, со стороны хранилища дополнительно ничего реализовывать не требуется, достаточно чтобы UNMAP был включён. Необходимо, чтобы гипервизор мог транслировать эту информацию от виртуальной машины к хранилищу что выполняется полностью на SCSI уровне. Итак начиная с ESXi 6.0 теперь есть возможность передавать информацию об удалённых блоках внутри гостевой ОС.
Для работы UNMAP изнутри виртуальной машины необходимо соблюсти следующие условия и иметь:
Многие годы все вендоры СХД говорили не создавайте тонкие виртуальные диски на тонких лунах. Но теперь это изменилось и для того, чтобы высвобождать блоки изнутри виртуальной машины необходимо иметь тонкие виртуальные диски и тонкий лун на СХД. В версии vSphere 6.0 был реализован функционал возврата удалённых блоков изнутри гостевой ОС, но имел ряд ограничений при использовании UNMAP, к примеру не поддерживались Linux машины. В vSphere 6.0 и более старых версий с VMFS, функция UNMAP автоматически не запускается, нужно запускать команду вручную.
Для того, чтобы работало высвобождение пространства изнутри гостевой ОС Windows, файловая система NTFS обязана быть отформатирована с размером allocation unit равным 64КБ.
Виртуальные машины с Linux поддерживающие SPC-4 и работающие на vSphere 6.5 теперь также смогут возвращать высвобожденное пространство изнутри виртуальной машины назад в хранилище.
Как проверить поддерживает ли ваша линукс машина высвобождение пространства?
Важно помнить, что гипервизор VMware запускает UNMAP асинхронно, то есть с задержкой. Это означает, что на практике вы скорее всего, никогда не будете иметь занятое пространство 1:1, внутри гостевой ОС/на датасторе гипервизора и на луне СХД.
Технология VVOL начиная с версии vSphere 6.0, VM Hardware версии 11 и Windows 2012 GOS с файловой системой NTFS поддерживает автоматическое высвобождение пространства внутрь тонкого луна на внешнем хранилище, на котором расположена данная виртуальная машина.
Linux GOS поддерживающие SPC-4 установленные на VM Hardware версии 11 на vSphere 6.5 также смогут возвращать пространство изнутри виртуальной машины на тонкий лун СХД.
Это существенно улучшает утилизацию полезного пространства в SAN инфраструктуре, использующей Thing Provisioning и Hardware-assistant снепшоты.
Подробнее о тюнинге ESXi 6.x для ONTAP.
Поддержка команд UNMAP для этого семейства ОС началась с Windows Server 2012 с файловой системой NTFS. Для включения автоматического UNMAP используйте Windows Host Utility 6.0.2 и выше или ONTAP DSM 4.0 и выше. Для проверки включён ли UNMAP выполните
Подробнее о тюнинге Windows Server для ONTAP.
Linux дистрибутивы поддерживают UNMAP. NetApp официально поддерживает RHEL версии 6.2 и выше при помощи ключа –o discard команды mount и утилиты fstrim. Подробнее в RHEL6 Storage Admin Guide.
Подробнее о тюнинге Linux Server для ONTAP.
Высвобождение удалённых блоков позволяет с одной стороны существенно экономить дисковое пространство, но с другой стороны если хост запросит у СХД высвободить больше количество блоков, к примеру, терабайты данных, ваша СХД будет выполнять это и не успокоится пока не закончит, а это дополнительная активность на СХД. Высвобождение терабайта данных особенно будет заметно на дисковых или гибридных (не All Flash) системах. Поэтому стоит осторожно относиться к удалению большего количества данных одним махом на таких системах (терабайт).
Если же вы попали в такую ситуацию, проконсультируйтесь с техподдержкой, возможно стоит увеличить значение wafl_zombie_ack_limit и wafl_zombie_msg_cnt. Если вам необходимо удалить все данные на луне, то лучше удалите на СХД целиком весь лун. All Flash системы, с другой стороны, намного менее восприимчивы к подобным запросам, и как правило, достаточно быстро и без усилий справляются с такими задачами.
Реализованная поддержка UNMAP, как на стороне гостевой ОС, хоста, так и на стороне хранилищ NetApp, позволяет более рационально утилизировать пространство в SAN окружении использующего Thin Provisioning и как следствие позволит более рационально использовать пространство СХД с аппаратными снепшотами. Поддержка UNMAP на уровне гипервизора, и тем более внутри гостевой ОС, существенно облегчит использование этих двух востребованных технологий.
Сообщения по ошибкам в тексте прошу направлять в ЛС. Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Без поддержки команды UNMAP любой тонкий лун созданный на стороне СХД всегда мог только увеличиваться в размере. Его рост был вопросом времени, который безоговорочно всегда заканчивался тем, что такой тонкий лун в конце концов станет занимать свой полный объём, который ему положен, т.е. в конце концов он станет толстым.
Вот представьте у вас на датасторе живут 3 виртуальные машины, каждая занимает 100GB. Ваш датастор находится на тонком луне, который занимает 300GB. Занимаемое пространство со стороны СХД и ESXi одинаковое: 300GB. После удаления одной ВМ, размер вашего луна со стороны СХД по-прежнему 300GB, а со стороны гипервизора занимаемое пространство на датасторе живущем на этом луне 200GB.
Связанно это с тем, что ране не было механизма обратной связи хоста с СХД. А именно, когда хост записывал блок информации в луне, СХД в свою очередь помечала этот блок как используемый. Далее хост мог удалить этот блок, но система хранения уже об этом не знала. Команда UNMAP и есть эта обратная связь, которая отмапливает уже не нужный блок с луна. Наконец-то наш тонкий лун научился не только набирать, но и уменьшать свой вес начиная с версии прошивки (Clustered Data) ONTAP 8.2.
VMware ESXi & UNMAP
В версии 5.0 функция UNMAP впервые была представлена, включена она была по умолчанию и автоматически запускалась при достижении заданного значения удалённых блоков, в последующих версиях механизм отключён по умолчанию и запускается вручную. Начиная с VMFS-6 (vSphere 6.5) высвобождение пространства происходит автоматически в течении 12 часов, при необходимости ручной механизм запуска высвобождения пространства также доступен. Важно отметить, что высвобождение пространства, о котором сейчас пойдёт речь происходит на уровне гипервизора, т.е. высвобождение удалённых блоков происходит только после удаления виртуальной машины или виртуальных дисков целиком, а не внутри гостевой ОС.
Если у вас уже есть ESXi и СХД с ONTAP с поддержкой UNMAP, но функция не включена
Нужно её включить со стороны СХД и со стороны гипервизора. Начнём с того, что переведём лун в оффлайн и включим функцию space-allocation на СХД (если там остались ВМ в запущенном состоянии, они завершат работу некорректно и возможно будут повреждены, так что их стоит или временно выключить, или временно мигрировать):
lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -state offline
lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -space-allocation enabled
lun modify -vserver vsm01 -volume vol2 -lun lun1_myDatastore -state online
После чего нужно включить unmap со стороны ESXi, для этого нужно отмапить и примапить датастор, чтобы ESXi обнаружил поддержку UNMAP (если там остались ВМ в запущенном состоянии, они завершат работу некорректно и возможно будут повреждены, так что их стоит или временно выключить или временно мигрировать):
esxcli storage filesystem unmount -l myDatastore
esxcli storage filesystem mount -l myDatastore
esxcli storage vmfs unmap -l myDatastore
После этого, чтобы высвобождать пространство, нужно будет периодически запускать команду:
esxcli storage vmfs unmap -l myDatastore
Важно отметить, что UNMAP работает только для лунов отформатированных со смещением партиции кратное 1 MB. Что это значит? Это значит, что, если вы когда-то конвертировали VMFS3 в VMFS5, UNMAP работать не будет. Проверить это просто, конвертированные VMFS3 имеют таблицу разбивки MBR, а VMFS5 которые были созданы заново имеют разбивку GPT.
# esxcli storage core device partition showguid
Example output:
Device Partition Layout GUID
-------------------------------------------------------------
naa.60a98000486e574f6c4a5778594e7456 0 MBR N/A
naa.60a98000486e574f6c4a5778594e7456 1 MBR N/A
naa.60a98000486e574f6c4a5052537a7375 0 GPT 00000000000000000000000000000000
naa.60a98000486e574f6c4a5052537a7375 1 GPT aa31e02a400f11db9590000c2911d1b8
Обратите внимение на колонку Layout.
Проверить смещение тоже не сложно, смотрим на длинну сектора. Напомню сектор равен 512 байтам.
# esxcli storage core device partition list
Example output:
Device Partition Start Sector End Sector Type Size
-------------------------------------------------------------------------------------
naa.60a98000486e574f6c4a5778594e7456 0 0 3221237760 0 1649273733120
naa.60a98000486e574f6c4a5778594e7456 1 128 3221225280 fb 1649267277824
naa.60a98000486e574f6c4a5052537a7375 0 0 3221237760 0 1649273733120
naa.60a98000486e574f6c4a5052537a7375 1 2048 3221237727 fb 1649272667648
Обратите внимание на колонки «Start Sector» и «End Sector». Итак, последнее устройство naa.60a98000486e574f6c4a5052537a7375 имеет смещение 1MB (2048 сектора*512 =1048576 byte = 1024KB). А вот второе устройство naa.60a98000486e574f6c4a5778594e7456 имеет смещение которое не кратно 1MB, оно явно меньше, UNMAP на нем работать не будет.
Проверить поддерживается ли UNMAP (Delete Status) можно так:
# esxcli storage core device vaai status get -d naa
Example output:
naa.60a98000486e574f6c4a5052537a7375
VAAI Plugin Name: VMW_VAAIP_NETAPP
ATS Status: supported
Clone Status: supported
Zero Status: supported
Delete Status: supported
Автоматическое высвобождение пространства в vSphere 6.5
Автоматическое высвобождение пространства назад в тонкий лун на СХД поддерживается начиная с vSphere 6.5. Для каждого VMFS-6 датастора можно назначать приоритет высвобождения пространства High/Mid/Slow, которое будет возвращено хранилищу в течении 12 часов. Запуск высвобождения пространства и настройку приоритизаци для VMFS-6 датастора можно также выполнить вручную из графического интерфейса или из командной строки.
esxcli storage vmfs reclaim config get -l DataStoreOnNetAppLUN
Reclaim Granularity: 248670 Bytes
Reclaim Priority: low
esxcli storage vmfs reclaim config set -l DataStoreOnNetAppLUN -p high
UNMAP из гостевой ОС.
Итак, ранее мы рассмотрели удаление виртуальных машин из датастора. Логично было бы сделать тоже самое при удалении блоков данных изнутри гостевой ОС, а не целиком виртуальной машины или её дисков. UNMAP поддерживается на стороне СХД с ONTAP и для того, чтобы работал механизм UNMAP при удалении данных с VMDK, т.е. изнутри гостевой ОС, со стороны хранилища дополнительно ничего реализовывать не требуется, достаточно чтобы UNMAP был включён. Необходимо, чтобы гипервизор мог транслировать эту информацию от виртуальной машины к хранилищу что выполняется полностью на SCSI уровне. Итак начиная с ESXi 6.0 теперь есть возможность передавать информацию об удалённых блоках внутри гостевой ОС.
Для работы UNMAP изнутри виртуальной машины необходимо соблюсти следующие условия и иметь:
- Virtual Hardware Version 11
- VMFS6
- vSphere 6.0*/6.5
- лун СХД должен быть тонким
- виртуальные диски виртуалки должны быть тонкими
- файловая система гостевой ОС должна поддерживать UNMAP
- для vSphere 6.0 CBT должен быть выключен
- включить UNMAP на гипервизоре, если необходимо: esxcli storage vmfs unmap -l myDatastore
- включить UNMAP на СХД
Never Thin on Thin
Многие годы все вендоры СХД говорили не создавайте тонкие виртуальные диски на тонких лунах. Но теперь это изменилось и для того, чтобы высвобождать блоки изнутри виртуальной машины необходимо иметь тонкие виртуальные диски и тонкий лун на СХД. В версии vSphere 6.0 был реализован функционал возврата удалённых блоков изнутри гостевой ОС, но имел ряд ограничений при использовании UNMAP, к примеру не поддерживались Linux машины. В vSphere 6.0 и более старых версий с VMFS, функция UNMAP автоматически не запускается, нужно запускать команду вручную.
Windows Guest OS support
Для того, чтобы работало высвобождение пространства изнутри гостевой ОС Windows, файловая система NTFS обязана быть отформатирована с размером allocation unit равным 64КБ.
Linux Guest OS SPC-4 support
Виртуальные машины с Linux поддерживающие SPC-4 и работающие на vSphere 6.5 теперь также смогут возвращать высвобожденное пространство изнутри виртуальной машины назад в хранилище.
Как проверить поддерживает ли ваша линукс машина высвобождение пространства?
Проверка поддержки SPC-4 в виртуальной машине Linux
Для этого запустите команду
Параметр Unmap command supported (LBPU) установленный в значение 1 означает, что используется тонкий диск, что нам и требуется. А значение 0 означает что тип виртуального диска thick (eager или sparse), с толстыми дисками функция UNMAP работать не будет.
Версия version=0x02 [SCSI-2] говорит о том, что UNMAP работать не будет, нам необходима версия SPC-4:
sg_vpd -p lbpv
Logical block provisioning VPD page (SBC):
Unmap command supported (LBPU): 1
Write same (16) with unmap bit supported (LBWS): 0
Write same (10) with unmap bit supported (LBWS10): 0Параметр Unmap command supported (LBPU) установленный в значение 1 означает, что используется тонкий диск, что нам и требуется. А значение 0 означает что тип виртуального диска thick (eager или sparse), с толстыми дисками функция UNMAP работать не будет.
sg_inq /dev/sdc -d
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: VMware
Product identification: Virtual disk
Product revision level: 1.0Версия version=0x02 [SCSI-2] говорит о том, что UNMAP работать не будет, нам необходима версия SPC-4:
sg_inq -d /dev/sdb
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x06 [SPC-4]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=1 Sync=1 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: VMware
Product identification: Virtual disk
Product revision level: 2.0Давайте проверим что UNMAP включён и работает:
Для этого запустим команду
значение 1 говорит о том, что гостевая ОС уведомляет SCSI уровень об удалённых блоках с файловой системы.
Проверим высвобождается ли пространство при помощи UNMAP:
Если вы получаете ошибку «blkdiscard: /dev/sdb: BLKDISCARD ioctl failed: Operation not supported» значит UNMAP не работает. Если же ошибки нет, то остаётся примонтировать файловую систему с ключём discard:
grep . /sys/block/sdb/queue/discard_max_bytes
1значение 1 говорит о том, что гостевая ОС уведомляет SCSI уровень об удалённых блоках с файловой системы.
Проверим высвобождается ли пространство при помощи UNMAP:
sg_unmap --lba=0 --num=2048 /dev/sdb
#или
blkdiscard --offset 0 --length=2048 /dev/sdbЕсли вы получаете ошибку «blkdiscard: /dev/sdb: BLKDISCARD ioctl failed: Operation not supported» значит UNMAP не работает. Если же ошибки нет, то остаётся примонтировать файловую систему с ключём discard:
mount /dev/sdb /mnt/netapp_unmap -o discardВажно помнить, что гипервизор VMware запускает UNMAP асинхронно, то есть с задержкой. Это означает, что на практике вы скорее всего, никогда не будете иметь занятое пространство 1:1, внутри гостевой ОС/на датасторе гипервизора и на луне СХД.
VVOL
Технология VVOL начиная с версии vSphere 6.0, VM Hardware версии 11 и Windows 2012 GOS с файловой системой NTFS поддерживает автоматическое высвобождение пространства внутрь тонкого луна на внешнем хранилище, на котором расположена данная виртуальная машина.
Linux GOS поддерживающие SPC-4 установленные на VM Hardware версии 11 на vSphere 6.5 также смогут возвращать пространство изнутри виртуальной машины на тонкий лун СХД.
Это существенно улучшает утилизацию полезного пространства в SAN инфраструктуре, использующей Thing Provisioning и Hardware-assistant снепшоты.
Подробнее о тюнинге ESXi 6.x для ONTAP.
Windows (Bare Metal)
Поддержка команд UNMAP для этого семейства ОС началась с Windows Server 2012 с файловой системой NTFS. Для включения автоматического UNMAP используйте Windows Host Utility 6.0.2 и выше или ONTAP DSM 4.0 и выше. Для проверки включён ли UNMAP выполните
fsutil behavior query disabledeletenotify. Состояние DisableDeleteNotify = 0 означает что UNMAP возвращает блоки на ходу (in-band). Если у хоста подключены несколько лунов с несколких СХД, часть которых не поддерживает UNMAP, рекомендуется выключить его. Подробнее о тюнинге Windows Server для ONTAP.
Linux (Bare Metal)
Linux дистрибутивы поддерживают UNMAP. NetApp официально поддерживает RHEL версии 6.2 и выше при помощи ключа –o discard команды mount и утилиты fstrim. Подробнее в RHEL6 Storage Admin Guide.
Подробнее о тюнинге Linux Server для ONTAP.
Disclaimer
Высвобождение удалённых блоков позволяет с одной стороны существенно экономить дисковое пространство, но с другой стороны если хост запросит у СХД высвободить больше количество блоков, к примеру, терабайты данных, ваша СХД будет выполнять это и не успокоится пока не закончит, а это дополнительная активность на СХД. Высвобождение терабайта данных особенно будет заметно на дисковых или гибридных (не All Flash) системах. Поэтому стоит осторожно относиться к удалению большего количества данных одним махом на таких системах (терабайт).
Если же вы попали в такую ситуацию, проконсультируйтесь с техподдержкой, возможно стоит увеличить значение wafl_zombie_ack_limit и wafl_zombie_msg_cnt. Если вам необходимо удалить все данные на луне, то лучше удалите на СХД целиком весь лун. All Flash системы, с другой стороны, намного менее восприимчивы к подобным запросам, и как правило, достаточно быстро и без усилий справляются с такими задачами.
Выводы
Реализованная поддержка UNMAP, как на стороне гостевой ОС, хоста, так и на стороне хранилищ NetApp, позволяет более рационально утилизировать пространство в SAN окружении использующего Thin Provisioning и как следствие позволит более рационально использовать пространство СХД с аппаратными снепшотами. Поддержка UNMAP на уровне гипервизора, и тем более внутри гостевой ОС, существенно облегчит использование этих двух востребованных технологий.
Сообщения по ошибкам в тексте прошу направлять в ЛС. Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Поделиться с друзьями
Комментарии (5)
Smasher
13.12.2016 17:12+2Практика показала, что для работы опции space-allocation с VMware необязательно отправлять LUN в офлайн. Просто после включения space-allocation надо немного подождать.
bbk
16.12.2016 15:44Привет.
Я точно выжидал где-то 5 минут с 5.5.
Какая у тебя версия ESXi и сколько ты выжидал?
jnz
19.12.2016 15:35Версия version=0x02 [SCSI-2] говорит о том, что UNMAP работать не будет, нам необходима версия SPC-4
Вроде достаточно SPC-3
mikkisse
Спасибо! Интересно как всегда.