Sesparse vmdk что это

Исправляем ошибку: Virtual Machine disks consolidation is needed

15.09.2022
itpro
PowerShell, VMware
комментариев 14

Предупреждение ‘Virtual Machine disks consolidation is needed’ на вкладке Summary виртуальной машины в консоли VMWare vSphere Client означает, что при удалении снапшотов (операция Delete или Delete All) на диске остались файлы, которые не удалось слить (commit) с основным файлом виртуального диска (vmdk). В результате вы не можете выполнить резервное копирование такой виртуальной машины, а ее производительность сильно деградирует.

Самые распространённые причины появления ошибки consolidation is needed:

• Плохая производительность дискового хранилища, из-за которого удаление/консолидация снапшотов отваливаются по таймауту или большого размера снапшота;
• На VMFS хранилище недостаточно места для выполнения консолидации, должно быть свободно не менее 1 Гб (см. как расширить VMFS в VMware ESXi);
• Файлы снапшотов заблокированы vSphere или сторонним приложением (как правило это приложение резервного копирования, HP DataPtotector, Veeam или Netapp VSC). Убедитесь, что отсутствует запушенные процессы резервного копирования виртуальной машины;

Как выполнить консолидацию дисков в VMware?

Для исправления ошибки «Virtual machine Consolidation Needed status» необходимо щелкнуть ПКМ по виртуальной машине и выбрать в меню пункт Actions -> Snapshots -> Consolidate.

Появится окно с запросом:

Подтвердите удаление избыточных логов. После этого vCenter выполнит консолидацию дисков и очистку логов. Процесс консолидации может идти долго в зависимости от размера ВМ, количества снапшотов и текущей нагрузки. Во время выполнения консолидации производительность ВМ может ухудшиться. Дождитесь окончания выполнения задания Consolidate virtual machine disk files и очистки логов.

При выполнении консолидации данные из дельта дисков сливаются с основным диском и лишние файлы на хранилище удаляются. После этого предупреждение о необходимости консолидации ВМ исчезнет.

Ошибки блокировки файлов при консолидации дисков VMware

В некоторых случая при выполнении консолидации в консоли vSphere может появится ошибка:

VMware в этом случае рекомендует выполнить перезапуск агентов Management agents на сервере ESXi. Для этого нужно подключиться к хосту ESXi по SSH и выполнить команду:

Если это не помогло, проверьте кто заблокировал файлы виртуальной машины.

1. Перейдите в каталог ВМ на VMFS хранилище: # cd /vmfs/volumes/xxxxxx-xxxxxx-xxxx-xxxxxxx/VM_NAME
2. Выведите список заблокированных файлов ВМ и какие хосты ESXi держат данные файлы: # for i in `ls`; do vmfsfilelockinfo -p $i ;done|grep ‘is locked in\|Host owning the lock\|Total time taken’ | sed ‘s|Host owning the lock on file is||g’|sed ‘s|Total time|—|g’ | awk ‘‘ |uniq
3. Предыдущая команда вернёт примерно такой результат:
4. В данном примере видно, что файл VM_NAME-flat.vmdk заблокирован сразу двумя хостами. Чтобы снять блокировку файла вторым хостом, подключитесь к esxi2 по SSH и выполните команды:
   /etc/init.d/hostd restart
   /etc/init.d/vpxa restart
5. Еще раз запустите консолидацию из интерфейса vSphere Client.

Однако вы можете попробовать разблокировать файлы виртуальной машины так:

1. Выключите виртуальную машины (если возможно);
2. Создайте новый снапшот;
3. Удалите все снапшоты ВМ с помощью пункта «Delete All Snapshots»;

Если опция Consolidate не активна в меню (серая кнопка), а в хранилище все еще находится большое количество дельта файлов снапшотов, скорее всего нарушена целостность цепочки снапшотов (ошибка Unable to enumerate all disks).

Попробуйте вручную удалить ВМ из списка (Remove from Inventory) и зарегистрировать VMX файла виртуальной машины из Datastore Browser. Если это не помогло, проверьте и исправьте ошибки в цепочке снапшотов как описано в статье “ The parent virtual disk has been modified since the child was created ” (https://kb.vmware.com/s/article/1007969).

Консолидация снапшотов ВМ VMware с помощью PowerCLI

Вы можете найти все виртуальные машины VMware, которые требуют консолидации с помощью PowerCLI (специальный модуь PowerShell для управления инфраструктурой VMware). Для этого подключитесь к своему серверу vCenter (или хосту ESXi):

Чтобы получить список всех ВМ со статусом «Virtual machine disks consolidation is needed»:

Теперь можно выполнить консолидацию дисков всех полученных ВМ:

Можно выполнить автоматическую консолидацию снапшотов ВМ старше 30 дней с помощью такого PowerShell скрипта:

$VMName = Get-VM | Get-Snapshot |
Where <$_.Created -lt (Get-Date).AddDays(-30)>| select VM |
ForEach-Object <
$VMName.ExtensionData.ConsolidateVMDisks()
>

Предыдущая статья Следующая статья

SEsparse Disk Format vs VMFSsparse – VMware performance study

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:

• SEsparse
• VMFSsparse

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:

• Big Data Analytics (Hadoop)
• VDI

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)

Особенности работы Sparse дисков в VMware ESXi

Сегодня я хотел бы рассказать об особенностях архитектуры «разреженных» (Sparse) дисков, использующихся для виртуальных машин на базе гипервизора ESXi и файловой системы VMFS.

Знание некоторых аспектов работы Sparse дисков позволит лучше понять преимущества и недостатки использования данной технологии для защиты данных (снапшоты и бекапы) или для более эффективного использования дискового пространства (Linked Clones).

Начнем с общей теории. ESXi поддерживает различные форматы виртуальных дисков для хранения данных: VMFS, vmfsSparse, vmfsSeSparse, RDM, VVOL, vSAN.

VMFS (также известный как FLAT) формат является самым простым, он используется для thick и thin виртуальных дисков. Виртуальный диск хранится в виде двух файлов — файла дескриптора (.vmdk) и бинарного файла с данными (-flat.vmdk).

Пример файла дескриптора.

# 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»

Бинарный файл с данными имеет плоскую структуру, такую же как файл .dd. Сектора хранятся последовательно, нулевой сектор имеет адрес 0x0000, первый — 0x0200, второй — 0x400 и так далее.

Поскольку thick и thin диски имеют одинаковый формат (FLAT), то отсюда следует первый нюанс — за хранение тонких дисков (Thin provisioning) отвечает файловая система VMFS (или NFS, если это поддерживается файловой системой NFS сервера). Это можно легко проверить, создав пустой тонкий диск на 1 ГБ, а затем скопирововав его на свой компьютер с файловой системой NTFS, используя File browser или SCP, скопированный файл займет 1 ГБ дискового пространства на вашем компьютере.

Thin диск отличается от Thick диска тем, что не требует выделение всего дискового простанства при создании, а увеличивается по мере заполнения данными. Гранулярность с которой растет thin диск зависит от размера файлового блока, который использует файловая система VMFS. Для актуальных версий VMFS5 и VMFS6 размер файлового блока (в большинстве случаев) составляет 1 МБ. Это значит, что thin диск также будет прирастать сегментами по 1 МБ. Также это приводит к фрагментированности хранения файлов thin дисков на файловой системе, адресуемые сегменты thin диска могут хранится в разных частях хранилища VMFS, что может усложнить восстановление данных в случае порчи метаданных VMFS.

Второй нюанс заключается в том, что VMFS является кластерной файловой системой с разделяемым доступом. Это означает, что несколько хостов ESXi могут одновременно записывать данные. Для координации доступа используется раздел с метаданными файловой сиситемы, в котором указывается — в какие файлы/области диска какой из хостов может выполнять запись. Каждый раз при создании или выделении нового сегмента для увеличении размера тонкого диска один из хостов блокирует том для внесения изменений в метаданные, используя SCSI-3 резервации или часть секторов, используя механизм ATS VAAI.

Sparse диски

Sparse диски (они же delta-диски, Redo Log файлы или снапшоты, как их называют в быту) имеют более сложную структуру по сравнению с VMFS дисками.

Sparse диск создается «поверх» родительского диска (другого Sparse диска или базового VMFS диска). Sparse диск аккумулирует в себя все изменения (все операции записи), которые выполняются для данной цепочки, выступая т.н. Redo Log файлом, и растет по мере заполнения.

Но Sparse диски могут использоваться и без снапшотов (те же linked clones ВМ) и даже без базового диска, например, можно создать SE Sparse диск, выполнив команду:

vmkfstools -c 10g -d sesparse disk.vmdk

Sparse диски в отличие от FLAT дисков являются тонкими благодаря внутреннему формату хранения данных. При копировании такого диска с VMFS он сохраняет свой реальный размер, а не раздувается как FLAT диски.

Изначальной целью создания Sparse дисков было обеспечить максимальную экономию дискового пространства при хранении изменений. По этой причине, гранулярность хранения данных для Sparse дисков составляет 512 байт. Иными словами, если после создания снапшота на диск потребуется записать всего 10 байт данных, то внутри Sparse диска будет выделен блок размером в 512 байт. Чуть позже мы более детально рассмотрим внутренний формат хранения и механизмы работы операций чтения и записи.

Однако, поскольку Sparse диски хранятся на файловой системе VMFS, то минимальный размер файла связан с размером файлового блока (по умолчанию, 1 МБ для VMFS5). Я намеренно опускаю ряд технических нюансов по хранению файлов маленького размера внутри файловых дискрипторов или суб-блоков, чтобы не перегружать читателей. По факту, размер прироста файла снапшота составляет 16 МБ. Умудренный читатель спросит — почему выделяемый сегмент для Sparse диска гораздо больше, чем для Thin диска (16 МБ против 1 МБ)? Я не нашел достоверной информации по этому поводу, но могу предположить, что это сделано для того, чтобы уменьшить количество блокировок VMFS, которые возникают при увеличении размера файла и необходимости выделения новых файловых блоков — Sparse диски растут гораздо быстрее, т.к. аккумулируют в себя не только запись новых блоков данных, но и изменения в блоках родительских дисков.

Для связи родительского (parent) диска с дочерними используется механизм указателей. В каждом файле дескриптора присутствуют два поля:

CID=ec393eec
parentCID=ffffffff

Поле CID содержит уникальный 32-битный идентификатор. При создании диска это поле имеет значение fffffffe, однако каждый раз, когда файл диска открывается (например, при запуске ВМ, к которой подключен данный диск) и в этот файл записываются данные, идентификатор генерируется заново. Этот механизм позволяет отследить — вносились ли изменения в диск или нет, и позволяет гарантировать целостность данных в цепочке снапшотов.

Поле parentCID позволяет выстроить цепочку зависимостей между виртуальными дисками. При создании Sparse диска в поле parentCID задается CID-идентификатор родительского диска. У базового VMFS диска значение parentCID всегда равно ‘ffffffff’.

На картинке ниже приведен пример многоуровневого дерева снапшотов и значение идентификаторов.

Гипервизор проверяет на соответствие значение CID в родительском диске и parentCID в дочернем. Отличия в значении говорят о том, что родительский диск был изменен после создания дочернего диска, и консистентность данных не может быть гарантирована.

• magicNumber [4 байта] — хранит в себе слово COWD в ASCII формате.
• version [4 байта] — всегда равна 1.
• flags [4 байта] — значение равно 3.
• numSectors [4 байта] — количество секторов базового диска.
• grainSize [4 байта] — размер блока данных (в секторах), который используется для хранения данных (для Sparse дисков ESXi равен 1 сектору).
• gdOffset [4 байта] — смещение с которого начинается Granular Directory, равен 4 секторам.
• numGDEntries — кол-во GDE (равен numSectors / gtCoverage).
• freeSector — адрес смещения следующего свободного сектора, где может размещаться GT или полезные данные.

• L0 — Granural Directory (GD)
• L1 — Granular Table (GT)

Granual Table, на которую ссылается GDE) в свою очередь состоит из 4096 ячеек Granular Table Entry, каждая из которых хранит смещение, по которому располагается блок данных размером 512 байт (Grain Data). GT создаются по мере необходимости при первой операции записи в 2 МБ диапазон данных. Размер ячейки GTE также равен 4 байтам.

Из-за размера ячейки GDE и GTE в 4 байта (32 бита) с учетом использования 512 байт секторов можно легко посчитать максимальный размер Sparse диска = 2^32 * 512 = 2 ТБ.

Максимальное кол-во GDE, которое может быть создано внутри файла, рассчитывается по формуле:

GDE = numSectors * 512 Байт / 2 МБ

Рассмотрим пример. Создадим Sparse файл и в первый сектор диска запишем ‘0xffffffff’. Для того, чтобы найти нужным нам блок с данными определим адрес первой GDE по смещению gdOffset (0x800). Далее из GDE определим адрес GT (0x1000). Первая ячейка GTE будет адресует первый блок Sparse диска по смещению 0x5000.

Учтите, что сектора, которые в базовом FLAT диске идут последовательно, не обязательно будут последовательно размещаться в Sparse файле. Адрес блока данных зависит от того, когда этот блок был выделен для записи в него новых данных. Таким образом, при случайной записи вполне реальна ситуация, которая изображена на картинке.

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

Из-за того, что в Sparse диске хранится дополнительная служебная информация, при максимальном заполнении размер Sparse диска может превышать размер FLAT диска.

Для примера создадим Thick диск размером 2 ГБ и затем сделаем снапшот ВМ и перезапишем все блоки псевдослучайными данными в Sparse диске:

2114560 -rw——- 1 root root 2164269056 Oct 30 18:07 disk-000001-delta.vmdk
2097152 -rw——- 1 root root 2147483648 Oct 30 17:43 disk-flat.vmdk

Размер Sparse диска больше на

16 МБ за счет места, которое занимает заголовок, GDE и GTE ячейки.
Операция чтения данных для Sparse дисков выполняются следующим образом. Начиная с последнего файла в цепочке, определяется ячейка GTE, которая должна адресовать блок данных. Если значение ячейки GTE равно 0, то это означает, что блок данных еще не перезаписывался и данные следует прочитать из родительского диска (другого Sparse диска или базового FLAT диска). В случае, если значение GTE равно 1, то вместо чтения блока данных по смещению возвращаются нули. Если же в GTE указано значение отличное от 0 или 1, значит, что по указанному смещению располагается блок, содержащий данные, которые будут прочитаны.

Что касается записи, то здесь все гораздо проще. Данные всегда записываются в последний в цепочке файл. Гранулярность записи, как было сказано ранее, составляет 512 Байт.

В документации можно встретить упоминание, что снапшоты используют механизм Copy-on-Write (COW) для хранения данных. Это запутывает многих администраторов, которые считают, что использование отдельного файла, хранящего изменения, ближе к механизму Redirect-on-Write (ROW), чем к Copy-on-Write. Sparse диски используют механизм Cow, когда выполняют запись данных меньших, чем размер сектора. Например, вам требуется записать в сектор всего 10 изменных байт. Для обеспечения целостности данных, перед тем, как выполнить запись, должен быть инициирован целый сектор, в него будут скопированы данные из родительского диска, и только после этого могут быть записаны измененные блоки данных. Отсюда и возникает термин Copy-on-Write.

На сегодня это вся информация, которой я хотел поделиться, в следующей части я расскажу о Space Efficient Sparse дисках, которые появились в vSphere 5.1.

Sesparse vmdk что это

A snapshot is a copy of the virtual machine’s disk file (VMDK) at a given point in time and preserves the state and data of a virtual machine at the time you take the snapshot. In this article will share basic information of what is a snapshot and different snapshot formats available on VMFS and the difference.

The first point everyone should aware that snapshots is not a backup solution. When you are taking a snapshot any data that was writable on a VM becomes read-only. You can take multiple snapshots of a virtual machine to create multiple point-in-time restore points. When you revert the virtual machine to a snapshot, current disk and memory states are deleted and the snapshot becomes the new parent snapshot for that VM. The snapshot file cannot exceed the size of the original disk file, and it requires some overhead disk space so you must have enough free space on your datastore.

A Take Snapshot operation creates .vmdk, -delta.vmdk, .vmsd, and .vmsn files. By default, the first and all delta disks are stored with the base .vmdk file. The. vmsd and .vmsn files are stored in the virtual machine directory. And you can create snapshots in VMware vSphere’s Snapshot Manager or with the vmware-cmd command-line utility from vSphere or vCenter. Deleting, or committing, snapshots merges all the delta files into the VMDK.

vSphere Snapshot Formats on VMFS

Currently, there are two snapshot formats are available VMFSsparse and SEsparse. Delta disk inside the VMFS datastore is called sparse disk. Delta disk represents the difference between the current state of the VM disk and the state that existed when you took the previous snapshot.

Sparse disks use the copy-on-write mechanism, in which the virtual disk contains no data, until the data is copied there by a write operation. This optimization saves storage space. Depending on the type of datastore in your virtual infrastructure, delta disks use different sparse formats.

Snapshot Formats	VMFS5	VMFS6
VMFSsparse	Virtual disks smaller than 2 TB	N/A
SEsparse	Virtual disks larger than 2 TB	For all disks

VMFSsparse

VMFS5 uses the VMFSsparse format for virtual disks smaller than 2 TB and it is implemented on top of VMFS. The VMFSsparse layer processes I/Os issued to a snapshot VM. Technically, VMFSsparse is a redo-log that starts empty, immediately after a VM snapshot is taken. The redo-log expands to the size of its base vmdk, when the entire vmdk is rewritten with new data after the VM snapshotting. This redo-log is a file in the VMFS datastore. Upon snapshot creation, the base vmdk attached to the VM is changed to the newly created sparse vmdk.

SEsparse

SEsparse is a format similar to VMFSsparse with some enhancements, SEsparse is a default format for all delta disks on the VMFS6 datastores. And on VMFS5 SEsparse is used for virtual disks of the size 2 TB and larger.SEsparse format is space-efficient and supports the space reclamation technique, were blocks that the guest OS deletes are marked. The system sends commands to the SEsparse layer in the hypervisor to unmap those blocks. The unmapping helps to reclaim space allocated by SEsparse once the guest operating system has deleted that data

Snapshot Migration

In every VMware infrastructure planned or unplanned maintenance may occur and that time VMs will be migrated. You can migrate VMs with snapshots across different datastores with VMFS versions find the below points while performing a migration

• When performing the migration of a VM with the VMFSsparse snapshot to VMFS6, the snapshot format changes to SEsparse.
• When performing the migration of VM with a vmdk of the size smaller than 2 TB is migrated to VMFS5, the snapshot format changes to VMFSsparse.
• You cannot mix VMFSsparse redo-logs with SEsparse redo-logs in the same hierarchy.

Conclusion

In this article, we have discussed vSphere Snapshot Formats on VMFS and basic information of Snapshots. Snapshot is useful as a short-term solution for testing any application upgrade or any change on the guest operating system.