sesparse vmdk что это
VMware — возможна потеря данных в SEsparse
Благодаря подписке на рассылку от Veeam Community Forums, углядел наличие одной прелестной проблемы с vSphere.
При использовании SEsparse-снапшотов могут наблюдаться следующие симптомы:
Круто, сказал я себе. А что же это за снапшоты такие?
Оказывается, SEsparse-снашоты используются на хранилищах VMFS-5/NFS при использовании виртуальных дисков (VMDK) размером больше 2ТБ, начиная с vSphere 5.5! Или кто-то вручную настроил такой тип снапшота для виртуальной машины.
В VMFS6 они используются для любых виртуальных дисков.
Соответственно, если вы используете любое (любое, Карл) средство резервного копирования, использующее vSphere API for Data Protection, на время создания резервной копии создается снапшот виртуальной машины.
О проблеме стало известно 4 октября, на текущий момент патчи вышли для vSphere 6.0, 6.5 и 6.7. Обратите внимание, что эти патчи имеют статус «Критичный»!
vSphere 5.5 в пролете, однако есть решение по отключению функционала «IO coalescing».
После отключения этой «фичи» может наблюдаться замедление в работе ВМ.
Для отключения вы можете воспользоваться утилитой esxcli:
P.S. Меня часто спрашивают «а зачем вообще нужна поддержка вендором версии vSphere? Закончилась она для vSphere 5.5 — ну и что»? 🙂
UPD: Решение под PowerSHell из комментариев, проставляющее параметр для всех хостов версии 5.5, подключенных к вашему vCenter:
Исправляем ошибку: Virtual Machine disks consolidation is needed
Предупреждение ‘Virtual Machine disks consolidation is needed’ на вкладке Summary виртуальной машины в консоли VMWare vSphere означает, что при удалении снапшота (операция Delete или Delete All) не удалились корректно (остались на диске) файлы виртуальных vmdk файлов снапшотов или логи. В результате не удается выполнить резервное копирование виртуальной машины.
Самые распространённые причины появления ошибки «Virtual Machine disks consolidation is needed»:
Consolidate консолидация снапшотов виртуальной машины» srcset=»https://winitpro.ru/wp-content/uploads/2018/11/snapshots-greater-consolidate-konsolidaciya-snapshotov-vi.png 459w, https://winitpro.ru/wp-content/uploads/2018/11/snapshots-greater-consolidate-konsolidaciya-snapshotov-vi-300×132.png 300w» sizes=»(max-width: 459px) 100vw, 459px» />
Появится окно с запросом:
This operation consolidates all redundant redo logs on your virtual machine. Are you sure you want to continue?
Подтверждаем удаление избыточных логов. После этого vCenter выполнит консолидацию дисков и очистку логов. Процесс консолидации может занять несколько минут, в течении которых производительность ВМ может ухудшиться.
После этого предупреждение о необходимости консолидации ВМ исчезнет.
В некоторых случая при выполнении консолидации в консоли vSphere может появится ошибка:
VMware в этом случае рекомендует выполнить перезапуск агентов Management agents на сервере ESXi. Для этого нужно подключиться к хосту по SSH и выполнить команду:
Однако вы можете попробовать разблокировать файлы виртуальной машины так:
Вы можете найти все виртуальные машины, которые требуют консолидации с помощью PowerCLI. Для этого подключитесь к своему серверу vCenter:
Теперь получим список всех ВМ со статусом «Virtual machine disks consolidation is needed»:
Теперь можно выполнить консолидацию дисков всех полученных машин:
SEsparse Disk Format vs VMFSsparse – VMware performance study
By Vladan SEGET | Last Updated: October 13, 2013
While the new SEsparse disk format introduced in vSphere 5.1 for Horizon View based workloads only, the VMFSsparse is used for snapshoting or linked clones too. SEsparse Disk Format vs VMFSsparse are compared and tested in this study. The SESparce VMDK virtual disk format – Space Efficient Sparse Disk Format. This disk format has a new granular block allocation size of 4kb. FYI, I have reported more about SEsparse disks in my post What’s New in VMware View 5.2 – HTML 5 Access, Sparse Disks, vSGA, W8 Support …
VMware used View Planner 3.0 for generating VDI workloads for 40 VMs running on ESXi server and Hadoop cluster which has been tested with 3 applications (TeraGen, TeraSort and TeraValidate). The tests and results are in this new technical PDF called SEsparse in VMware vSphere 5.5 (Performance Study).
The performance were tested on vSphere 5.5 running VMware Horizon View 5.2 for the VDI tests as well as Hadoop workloads. The following phrase from the paper is quite interesting and lifts the cover on features and enhancements that hasn’t been reviewed or announced elsewhere yet:
In vSphere 5.5, for VMDKs greater than 2TB in size, SEsparse becomes the default scheme for virtual disk snapshots. Various enhancements were made to SEsparse technology in the vSphere 5.5 release, which makes SEsparse perform mostly on par or better than VMFSsparse formats. SEsparse also has a significant advantage over VMFSsparse virtual disk formats by being space efficient.
The tests are done at local attached storage and on SAN storage.
So In vSphere 5.5 VMware has two linked-clones techniques, but the performance varies depending on different data transfer sizes and I/O access patterns:
Both those techniques can use base VMDK file which is shared among VMs, but the VMs runs out of a delta-disks.
VMFSsparse:
VMFSsparse is a virtual disk format used when a VM snapshot is taken or when linked clones are created off the VM. VMFSsparse is implemented on top of VMFS and I/Os issued to a snapshot VM are processed by the VMFSsparse layer. VMFSsparse is essentially a redo-log that grows from empty (immediately after a VM snapshot is taken) to the size of its base VMDK (when the entire VMDK is re-written with new data after the VM snapshotting). This redo-log is just another file in the VMFS namespace and upon snapshot creation the base VMDK attached to the VM is changed to the newly created sparse VMDK.
SEsparse (space efficient):
SEsparse is a new virtual disk format that is similar to VMFSsparse (redo-logs) with some enhancements and new functionality. One of the differences of SEsparse with respect to VMFSsparse is that the block size is 4KB for SEsparse compared to 512 bytes for MFSsparse. Most of the performance aspects of VMFSsparse discussed above—impact of I/O type, snapshot depth, physical location of data, base VMDK type, etc.—applies to the SEsparse format also.
VMware uses IOmeter for the testing and methodology for full or empty VMDKs as the performance varies. The results also varies for sequential writes or random writes. Two platforms are analysed:
The results shows mostly better performance on SEsparse disks (not for every single workload) and also for VDI is good to have the SEsparse disks as they can reclaim dead space from thin provisioned disks automatically.
Get the paper from this link – SEsparse in VMware vSphere 5.5 (Performance Study)
blog.vmpress.org
Страницы
вторник, 6 ноября 2018 г.
Особенности работы Sparse дисков в VMware ESXi
Сегодня я хотел бы рассказать об особенностях архитектуры «разреженных» (Sparse) дисков, использующихся для виртуальных машин на базе гипервизора ESXi.
Знание аспектов работы Sparse дисков позволит лучше понять преимущества и недостатки при использовании для защиты данных виртуальных машин (снапшоты и бекапы) или для клонирования виртуальных машин (Linked Clones).
Начнем с общей теории. ESXi поддерживает множество различных форматов виртуальных дисков: VMFS, vmfsSparse, vmfsSeSparse, RDM, VVOL, vSAN.
Пример файла дескриптора.
# Disk DescriptorFile
version=1
encoding=»UTF-8″
CID=ec393eec
parentCID=ffffffff
createType=»vmfs»
# Extent description
RW 4194304 VMFS «vm01-flat.vmdk»
# The Disk Data Base
#DDB
ddb.adapterType = «lsilogic»
ddb.geometry.cylinders = «261»
ddb.geometry.heads = «255»
ddb.geometry.sectors = «63»
ddb.longContentID = «b67f98419cca278410ca1bd9fffffffe»
ddb.thinProvisioned = «1»
ddb.uuid = «60 00 C2 94 5a a7 a8 8e-d6 41 59 5b b0 06 b3 2b»
ddb.virtualHWVersion = «14»
Thin диск в отличие от Thick диска не требует выделения всего дискового простанства при создании, а увеличивается по мере заполнения данными. Гранулярность с которой растет thin диск зависит от размера файлового блока, который использует файловая система VMFS. Для VMFS 5 и VMFS 6 размер файлового блока по умолчанию составляет 1 МБ. Thin диск, по мере записи в него новых данных, будет увеличиваться частями (сегментами) по 1 МБ. Это может приводить к большей фрагментации файлов thin дисков по сравнению с thick дисками, особенно в тех случаях, когда на хранилище VMFS располагается много thin дисков, которые постепенно увеличиваются в размере.
Sparse диски
Sparse диски (они же delta-диски, Redo Log файлы или снапшоты, как их называют в быту) имеют более сложную структуру по сравнению с thick и thin дисками.
Sparse диск создается «поверх» родительского диска (другого Sparse диска или базового VMFS диска), формируя своеобразную цепочку, или дерево, если из одного родительского диска создано несколько Sparse дисков. Sparse диск аккумулирует в себя все изменения (все операции записи), которые выполняются для данной цепочки, выступая т.н. Redo Log файлом, и растет по мере заполнения.
Но Sparse диски могут использоваться и без снапшотов (те же linked clones ВМ) и даже без родительского диска, например, можно создать пустой SE Sparse диск, выполнив команду:
Sparse диски в отличие от FLAT дисков являются тонкими благодаря внутреннему формату хранения данных. При копировании такого диска с VMFS он сохраняет свой реальный размер, а не раздувается как FLAT диски.
Изначальной целью создания Sparse дисков было обеспечение максимальной экономии дискового пространства при хранении изменений. Гранулярность хранения данных для Sparse дисков составляет 512 байт. Иными словами, если после создания снапшота на диск потребуется записать всего 10 байт данных, то внутри Sparse диска будет выделен блок размером в 512 байт. Чуть позже мы более детально рассмотрим внутренний формат хранения и механизмы работы операций чтения и записи.
Поле parentCID позволяет выстроить цепочку зависимостей между виртуальными дисками. При создании Sparse диска в поле parentCID прописывается значение CID-идентификатора родительского диска. У базового VMFS диска значение parentCID всегда равно ‘ffffffff’.
На картинке ниже приведен пример многоуровневого дерева снапшотов и значение идентификаторов.
Гипервизор проверяет на соответствие значение CID в родительском диске и parentCID в дочернем. Отличия в значении говорят о том, что родительский диск был изменен после создания дочернего диска, и консистентность данных не может быть гарантирована.
Структура Sparse диска приведена на рисунке.
Более детальная информация по структуре заголовка приведена в документе Virtual Disk Format 5.0.
Из-за размера ячейки GDE и GTE в 4 байта (32 бита) с учетом использования 512 байт секторов можно легко посчитать максимальный размер Sparse диска = 2^32 * 512 = 2 ТБ.
Максимальное кол-во GDE, которое может быть создано внутри файла, рассчитывается по формуле:
GDE = numSectors * 512 Байт / 2 МБ
По этой причине, данные, хранящиеся в Sparse дисках, гораздо больше подвержены фрагментации, чем внутри обычных FLAT дисков, что негативно сказывается на производительности операций ввода-вывода.
Из-за того, что в Sparse диске хранится дополнительная служебная информация, при максимальном заполнении размер Sparse диска может превышать размер FLAT диска.
Для примера создадим Thick диск размером 2 ГБ, сделаем снапшот ВМ и перезапишем все блоки в Sparse диске:
16 МБ за счет места, которое занимает заголовок, GDE и GTE ячейки.
На сегодня это вся информация, которой я хотел поделиться, в следующей части я расскажу о Space Efficient Sparse дисках, которые появились в vSphere 5.1.
consolidate virtual machine disk files
Предупреждение ‘Virtual Machine disks consolidation is needed’ на вкладке Summary виртуальной машины в консоли VMWare vSphere означает, что при удалении снапшота (операция Delete или Delete All) не удалились корректно (остались на диске) файлы виртуальных vmdk файлов снапшотов или логи. В результате не удается выполнить резервное копирование виртуальной машины.
Самые распространённые причины появления ошибки «Virtual Machine disks consolidation is needed»:
Появится окно с запросом:
This operation consolidates all redundant redo logs on your virtual machine. Are you sure you want to continue?
Подтверждаем удаление избыточных логов. После этого vCenter выполнит консолидацию дисков и очистку логов. Процесс консолидации может занять несколько минут, в течении которых производительность ВМ может ухудшиться.
После этого предупреждение о необходимости консолидации ВМ исчезнет.
В некоторых случая при выполнении консолидации в консоли vSphere может появится ошибка:
VMware в этом случае рекомендует выполнить перезапуск агентов Management agents на сервере ESXi. Для этого нужно подключиться к хосту по SSH и выполнить команду:
Однако вы можете попробовать разблокировать файлы виртуальной машины так:
Вы можете найти все виртуальные машины, которые требуют консолидации с помощью PowerCLI. Для этого подключитесь к своему серверу vCenter:
Теперь получим список всех ВМ со статусом «Virtual machine disks consolidation is needed»:
Теперь можно выполнить консолидацию дисков всех полученных машин:
Ошибка virtual machine disks consol > 11.11.2014 Vmware, VirtualBox 15 комментариев
Ошибка virtual machine disks consol >
Добрый день уважаемые читатели, сегодня расскажу как решается ошибка висящая на виртуальной машине в ESXi 5.5 и звучит она virtual machine disks consol >
Устраняем virtual machine disks consolidation is needed
Вот так вот выглядит эта ошибка, некое такое предупреждающее сообщение на вкладке Summary.
Возникла ошибка virtual machine disks consolidation is needed в ESXI 5.x.x, причина это удаление snapshot. После его удаления остались файлы которые не смогли слиться с основным файлом виртуального диска, и требуется провести консолидацию. Выбираете нужную машину правым кликом меню Power-Consolidate.
После чего произойдет слияние дисков, и предупреждение пропадет. Сам процесс слияние или merge может идти долго, все будет зависеть от некоторых факторов
У меня были случаи в практике, что виртуалка так консолидировалась 3 дня. Надеюсь вам помогла эта заметка и вы смогли устранить ошибку virtual machine disks consolidation is needed
Популярные Похожие записи:
15 Responses to Ошибка virtual machine disks consol >
Спасибо за информацию, только мне кажется не в пункте «Power», а в пункте «Snapshot».
Спасибо мне помогло исправить данную ошибку, после veeam осталось так
your blo was much interesting for me! I will say thanks u a lot to posting the interesting stuff.
Your blog is very useful to us! I’ll thank you you very much to posting the interesting information!
Это действие выполняется при выключенной виртуальной машине или можно при включенной. Просто при включенной виртуалке выбивает ошибку
Unable to access file since it is locked
An error occurred while consolidating disks: Failed to lock the file.
Consolidation failed for disk node ‘scsi0:0’: Failed to lock the file.
В большинстве случаев можно на работающей машине, но бывает и таке, что только при выключенной. В вашем случае файлы заблокированы.
Можете подсказать, что делать в моём случае с заблокированными файлами, т.к eSXI я пока слабоват
Точный скриншот ошибки можете прислать
Спасибо. Оказалось, что проблема решается в 2 клика.
Вы смотрите по времени изменения файла, если оно не меняется то процесс завис, если меняется, то ждите, у меня на сайте есть про это статья, про снапшоты, прочитайте ее, будет полезно.
Ну, в общем я нашёл кое что, про что у Вас не читал — после застопорившегося consolidate любые попытки просмотреть внутренности каталога данного datastore приводят к подвисам или ошибкам, что device busy. Попытка перезагрузки хоста сопровождается евентом в консоли, что есть проблема с power off проблемной машины, хотя она не была запущена. После чего клиент отваливается, хост пинговаться перестаёт, но на экране самого хоста висит штатная заставка, а он сам на клики на клаве не реагирует. Делаем аппаратный poweroff, хост нормально поднимается и проблемная машина нормально стартует. Сообщение о необходимости консолидации не появляется, НО в каталогес VM помимо имяVM-00000x.vmdk есть ещё и имяVM-00000x-sesparse.vmdk. Создаётся впечатление, что подвис происходит на этапе удаления указанных файлов (в основе предположения — когда при первой попытке удалял папку проблемной машины из CLI — тоже всё подвисло). Останавливаем машину, заходим в CLI и переносим все имяVM-00000x.vmdk и имяVM-00000x-sesparse.vmdk в другой каталог на этом же томе (это чтоб прошло банальное переименование без фактического удаления источника). Машина нормально стартует и очень быстро работает. Врзвращаемся к CLI, переходим в каталог, куда мувнули файлы и пробуем удалять — имяVM-00000x-sesparse.vmdk удаляются без проблем, а вот попытка удалить эти sesparse приводит к зависанию, но не консоли, как я думал, а тома.
Там ошибочка — без проблем удалялся файл без sesparse
Last week I had a customer with a VM that required virtual disk consolidation, however when he attempted to perform this from the vSphere client it would run for hours and unfortunately fail: 
The virtual disk is either corrupted or not a supported format.
I waited till we could get a service window on the VM, performed a shutdown and re-ran the disk consolidation. Still the same error message!
I then used command vim-cmd vmsvc/getallvms to quickly locate the volume containing the VM: 
Then checked if there was any locks on the vmdk file: 
I have highlighted the line showing us there is a RO (Read-Only) lock on the VMDK file. This is most likely what is causing the disk consolidation to fail. The last part of the line 0026b9564d86 is the mac address of the host locking the file.
Lets lookup if the host running the VM currently is also the host locking the file: 
The mac address matched up and a quick Google search revealed the following VMware Knowledge Base article.
As suggested in the article I then performed a vMotion of the VM to a different host and re-tried the disk consolidation.
Finally it finished without errors!
As always, if this helped you please leave a comment! ��