Ctk vmdk что это

Detailed description of all the files that make up a Virtual Machine

Here’s a detailed list of all the files that make up a Virtual Machine :

<vmname>.nvram file
This file contains the CMOS/BIOS for the VM. The BIOS is based off the PhoenixBIOS 4.0 Release 6 and is one of the most successful and widely used BIOS and is compliant with all the major standards, including USB, PCI, ACPI, 1394, WfM and PC2001. If the NVRAM file is deleted or missing it will automatically be re-created when the VM is powered on. Any changes made to the BIOS via the Setup program (F2 at boot) will be saved in this file. This file is usually less then 10K in size and is not in a text format (binary).

vmdk files
These are the disk files that are created for each virtual hard drive in your VM. There are typically 3 different types of files that use the vmdk extension, they are:

<vmname>flat.vmdk file — This is the actual raw disk file that is created for each virtual hard drive. Almost all of a .vmdk file’s content is the virtual machine’s data, with a small portion allotted to virtual machine overhead. This file will be roughly the same size as your virtual hard drive.

<vmname>.vmdk file — This isn’t the file containing the raw data anymore. Instead it is the disk descriptor file which describes the size and geometry of the virtual disk file. This file is in text format and contains the name of the flat.vmdk file for which it is associated with and also the hard drive adapter type, drive sectors, heads and cylinders, etc. One of these files will exist for each virtual hard drive that is assigned to your virtual machine. You can tell which flat.vmdk file it is associated with by opening the file and looking at the Extent Description field.

<vmname>delta.vmdk file — This is the differential file created when you take a snapshot of a VM (also known as REDO log). When you snapshot a VM it stops writing to the base vmdk and starts writing changes to the snapshot delta file. The snapshot delta will initially be small and then start growing as changes are made to the base vmdk file, The delta file is a bitmap of the changes to the base vmdk thus is can never grow larger than the base vmdk. A delta file will be created for each snapshot that you create for a VM. These files are automatically deleted when the snapshot is deleted or reverted in snapshot manager.

<vmname>-ctk.vmdk file is a special file that is created in each VM’s home directory for each virtual disk that has Change Block Tracking (CBT) feature enabled. CBT is a new feature introduced in vSphere. Besides requiring vSphere, a prerequisite for using CBT is that a virtual machine must be using version 7 virtual hardware. The size of this file is fixed and does not grow beyond its initial size unless you increase the size of a virtual disk. The size of this file will vary based on the size of a virtual disk which is approximately .5MB for every 10 GB of virtual disk size. Inside this file the state of each block is stored for tracking purposes using sequence numbers that can tell applications if a block has changed or not. One of these files will exist for each virtual disk that CBT is enabled on.

<vmname>.vmx file
This file is the primary configuration file for a virtual machine. When you create a new virtual machine and configure the hardware settings for it that information is stored in this file. This file is in text format and contains entries for the hard disk, network adapters, memory, CPU, ports, power options, etc. You can either edit these files directly if you know what to add or use the VMware® GUI (Edit Settings on the VM) which will automatically update the file.

<vmname>.vswp file
This is the VM swap file (earlier ESX versions had a per host swap file) and is created to allow for memory overcommitment on a ESX server. The file is created when a VM is powered on and deleted when it is powered off. By default when you create a VM the memory reservation is set to zero, meaning no memory is reserved for the VM and it can potentially be 100% overcommitted. As a result of this a vswp file is created equal to the amount of memory that the VM is assigned minus the memory reservation that is configured for the VM. So a VM that is configured with 2GB of memory will create a 2GB vswp file when it is powered on, if you set a memory reservation for 1GB, then it will only create a 1GB vswp file. If you specify a 2GB reservation then it creates a 0 byte file that it does not use. When you do specify a memory reservation then physical RAM from the host will be reserved for the VM and not usable by any other VM’s on that host. A VM will not use it vswp file as long as physical RAM is available on the host. Once all physical RAM is used on the host by all its VM’s and it becomes overcommitted then VM’s start to use their vswp files instead of physical memory. Since the vswp file is a disk file it will effect the performance of the VM when this happens. If you specify a reservation and the host does not have enough physical RAM when the VM is powered on then the VM will not start.

<vmname>.vmss file
This file is created when a VM is put into Suspend (pause) mode and is used to save the suspend state. It is basically a copy of the VM’s RAM and will be a few megabytes larger than the maximum RAM memory allocated to the VM. If you delete this file while the VM is in a suspend state It will start the VM from a normal boot up instead of starting the VM from the state it was when it was suspended. This file is not automatically deleted when the VM is brought out of Suspend mode. Like the vswp file this file will only be deleted when the VM is powered off (not rebooted). If a vmss file exists from a previous suspend and the VM is suspended again then the previous file is re-used for the subsequent suspensions. Also note that if a vswp file is present it is deleted when a VM is suspended and then re-created when the VM is powered on again. The reason for this is that the VM is essentially powered off in the suspend state, it’s RAM contents are just preserved in the vmss file so it can be quickly powered back on.

<vmname>.log file
This is the file that keeps a log of the virtual machine activity and is useful in troubleshooting virtual machine problems. Every time a VM is powered off and then back on a new log file is created. The current log file for the VM is always vmware.log. The older log files are incremented with a -# in the filename and up to 6 of them will be retained. (ie. vmware-4.log) The older .log files are always deleteable at will, the latest .log file can be deleted when the VM is powered off. As the log files do not take much disk space, most administrators let them be

<vmname>.vmxf file
This is a supplemental configuration file in text format for virtual machines that are in a team. Note that the .vmxf file remains if a virtual machine is removed from the team. Teaming virtual machines is a VMware Workstation feature and includes the ability to designate multiple virtual machines as a team, which administrators can then power on and off, suspend and resume as a single object making it particularly useful for testing client-server environments. This file still exists with ESX server virtual machines but only for compatibility purposes with Workstation.

<vmname>.vmsd file
This file is used to store metadata and information about snapshots. This file is in text format and will contain information such as the snapshot display name, uid, disk file name, etc. It is initially a 0 byte file until you create your first snapshot of a VM and from that point it will populate the file and continue to update it whenever new snapshots are taken. This file does not cleanup completely after snapshots are taken. Once you delete a snapshot it will still leave the fields in the file for each snapshot and just increment the uid and set the name to Consolidate Helper presumably to be used with Consolidated Backups

<vmname>.vmsn file
This is the snapshot state file, which stores the exact running state of a virtual machine at the time you take that snapshot. This file will either be small or large depending on if you select to preserve the VM’s memory as part of the snapshot. If you do choose to preserve the VM’s memory then this file will be a few megabytes larger then the maximum RAM memory allocated to the VM. This file is similar to the vmss (Suspend) file. A vmsn file will be created for each snapshot taken on the VM, these files are automatically deleted when the snapshot is removed.

Русские Блоги

VMware виртуальной машина программирование виртуального диска точка знания грамотность

содержание

Преступность

Этот блог является основой программирования VMware виртуального диска, а также является основа написания VMware защиты виртуальной машины и восстановления процедур. Он относится к соответствующей точке знания грамотности.

VMware виртуальной машины тип файла

VMware виртуальный тип машины файл на хосте Exsi：

суффикс	описывать
.vmx	Файл конфигурации виртуальной машины
.vmdk	Файл метаданных для файла на диске виртуальной машины
flat.vmdk	файл двоичного диска виртуальной машины, виртуальная машина файл данных реального диска
ctk.vmdk	Блок данных изменяет блок данных файла на диске виртуальной машины, сохраняет блок данных информации о сдвиге после последнего снимка
.vmem	Файл подкачки памяти виртуальной машины, хранит данные памяти на виртуальной машине, был создан, когда виртуальная машина работает или вышел из строя.
.vmss	Информация о файле состояния, когда виртуальная машина виснет
.vmsd	Файл метаданных виртуального снимка машины, сохраняет информацию, такие как имя, быстрым UID (уникальный идентификатор), имя файла на диске. Перед созданием снимков, его размер 0bytete
.vmsn	Файл информации о состоянии виртуальной машины снимки используется для сохранения состояния виртуальной машины, который создает снимок. Размер этого файла зависит от того, или нет, чтобы сохранить память при создании снимков. Если сохранен, то этот файл будет большое количество памяти, чем размер памяти, выделенной для этой виртуальной машины.
.vmtx	Файл шаблона виртуальной машины
.nvram	Виртуальная машина BIOS файл
.vswp	обмен файлами виртуальной машины
.log	Файл журнала виртуальной машины

Три типа файлов, необходимых для виртуальных машин VMware перечислены ниже:

• vm_name.vmdk (Profile): Сохранить метаданные диска файл виртуальной машины (как правило, содержащий основную информацию о двух наиболее важных файлов диска), пример:

vm_name-flat.vmdk (Binary): Степень Описание файла, сохраните информацию виртуального диска виртуальной машины.

vm_name-ctk.vmdk (Binary): Изменить файл отслеживания изменений файла отслеживания, сохранения информации блока данных, изменения в виртуальной машине с момента последнего снимка.

VMware снимок виртуальной машины

VMware Virtual Machines Быстро иллюстрируют следующие три типа:

Краш равномерного снимок(Crash-последовательный снимок): Это тип снимка по умолчанию виртуальной машины VMware, что эквивалентно состоянию диска, когда компьютер вдруг выключен, а данные во флэш-памяти, будут потеряны.

Файловая система последовательной снимок(File-System-Последовательная съемка): До момента времени снимка файловой система виртуальной машины заморожена, грязная кисть данных в памяти, после того, как снимок будет завершен, файловая система оттаивает. Такие снимки обеспечивают согласованность файловой системы, то есть данные в памяти не будут потеряны.

консистенция Применение(Применение-Последовательная съемка): Прежде чем искать моменты времени, приложение работает на виртуальной машине заморожено, все диски кисти загрязнены данные применяются в памяти, после того, как снимок будет завершен, приложение оттаивает, такой снимок гарантирует, что данные указан полный, но не гарантируется , что файловая система также точно так же.

Quiseced Snapshot

Два последних типа моментальных также совместно именуемые Quiseced Snapshot.Есть два основных реализаций с использованием Quiseced Snapshot Есть два основных реализаций.:

Использование клиентских операционная системы встроенные служб или приложений VMware обеспечивает последовательный драйвер：

• Клиенты версии новой Windows , предоставляют услуги VSS (Volume Shadow Copy Service), VSS обеспечивает Запрос-Writer для приложения встречается и файловой системы с замораживанием потребностей, замораживания и памяти набора данных перед временем снимки и снимка Decoil после завершения;
• Для версии старого клиента Windows, VMware обеспечивает синхронизацию драйвера для поддержки приложений и файловой системы непротиворечивости снимков;
• На клиенте Linux, модуль VMSync ядра, предоставляемые Kernel Module VMSync поддерживает только согласованность файловой системы, и не может поддерживать согласованность приложений.

Scriptor: Если клиент не-Windows, вы должны сценариям записи для указанного приложения для замораживания или оттепелью применения.

NOTE: Указанный выше VSS, синхронизация драйвер, модуль ядра VMSync и скрипты должны полагаться на VMware Tools, так что даже если операционная система клиента поддерживает перечисленную выше функцию, вам все еще нужно установить VMware Tools, чтобы полностью поддерживать Quiseced снимок. Например, для VSS, VMware Tools предоставляет функцию поддержки VSS, которая является мостом между VMware Tools и Windows, VSS. Для создания QuiseCed снимков, VSS Поддержка должна быть установлена.

Процесс создания для quisECed снимки

1. Вопросы пользователя запрос создания Стабилизирован Snapshot для VCENTER, VCENTER дает запрос на создание снимки к ESXi виртуальной машины.
2. Hostd служба по ESXi передает запрос на создание моментальных снимков в VMware Tools в клиенте.
3. VMware Tools Уведомление VSS в VSS реквестере и VSS относится к зарегистрированной файловой системе и VSS Writer каждого приложения для выполнения операций замораживания.
4. После того, как замороженный и память набор данных завершен, инструменты VMware уведомляет Hostd службу в результате завершения.
5. Hostd служба выполняет операцию снимки.
6. После того, как снимок будет завершен, файловая система и различные приложения наконечников в предыдущем заказе.

Создать снимок

3-файлы, созданные после того, как в виртуальной машине VMware создает снимок:

• vm_name-000001.vmdk (Profile): Файл метаданных виртуального снимка машины записывает информацию о соответствующем файле снимка, где 000001 представляет первый снимок.

vm_name-000001-delta.vmdk (Binary) называется файл данных снимок или файл отката-журнал (в VDDK связанных терминов, суб-диск Ребенок диска, журнальные журнальные, разница цепи Delta Link означает то же значение), этот файл используется для сохранения новые данные, полученные с помощью виртуальной машины после того, как в момент времени снимки, то есть, данные снимка. В-файл дельта технологии технология, начальный размер 16Мбы, который будет увеличиваться по мере данных виртуальных машин оседающих работы увеличивается, и БРОНИРОВАНИЕ конфликт SCSI снижается, а размер файла не будет превышать базовый диск размера файла.

vm_name-000001-ctk.vmdk (Binary): Изменить файл отслеживания для сохранения блока данных, информацию о сдвиге, что изменения из файла виртуального диска с момента последнего снимка.

Создать процесс выполнения снимка и принцип

Это может быть видно из приведенного выше рисунка, характеристики виртуальной машины снимка VMware являются:

• Виртуальной машины VMware используется цепной снимок.
• Базовый диск файл виртуальной машины VMware После того, как снимок создан, его доступ или режим только чтение.
• После того, как момент время снимки, данные о новом диске будут записаны в файл данные снимки.
• Повреждение любого файла снимка на цепи снимок вызовет виртуальную машину для правильной работы.

Удаление снимка

Из характеристик создания моментальных снимков, вы можете понять , если вы хотите , чтобы убедиться , что виртуальная машина может работать в нормальном режиме при удалении снимка, то вам необходимо объединить данные в файле данные снимки для обеспечения виртуальной машины. Целостность данных диска ,

Удаление виртуального снимка машины, как правило, следующие два случая:

• Виртуальная машина быть углублен в цепи снимкиДанные в Delta VMDK слияниях вышестоящему-бит Delta VMDK или базовый файл на диске базы VMDK виртуальной, а затем Delta VMDK удаляется.
• Виртуальная машина снимок должны быть удален не в цепи моментальных снимков (VMware поддерживает независимый снимок): Нет слияние, удаление файлов данных снимков непосредственно.

Удалить характеристики виртуальной машины VMware снимки:

• Удаление снимков включают две асинхронные операции: 1. Удалить снимок из снимков менеджера; 2. VMDK объединение данных. Если 1 успешно и 2 неудачи, файл Delta VMDK останется, так что если вам необходимо вручную выполнить слияние файлов моментальных снимков.
• Удаление снимков могут принести много записи данных, иногда может потребоваться удалить длительное время, и производительность виртуальной машины будет иметь негативные последствия.
• не С начала Vsphere 4 Update 2, процесс выбора выбора, чтобы удалить все снимки виртуальной машины больше не является слияние следующего слоя, но каждый слой непосредственно объединен в базу VMDK.

ТОС является реализация введена в Vsphere версии 4.0инкрементное резервное копированиеФункция, добавочное резервное копирование представляет только разность между данными измененных два точечных точками, и эти разностями данными часто являются моментальными снимками данных виртуальной машины. ESXi создает -ctk.vmdk файл для каждого виртуального диска, который открывает виртуальную машину, которая позволила ТОС. ТОС принесет некоторые потери производительности на диск, так что элемент конфигурации ТОС виртуальной машины по умолчанию для завершения работы.

Принцип ТОС должен позволить VMkernel мониторинга с последнего снимка, и блоки данных изменяются, запишите смещение этих измененных блоков данных, так что эти изменения, которые были изменены могут быть получены.

Процесс выполнения ТОС

• Step 1Выполните полное резервное копирование, то есть, резервное копирование данных снимков для первой виртуальной машины снимки.
• Step 2:пройти через vShpere API(VirtualDisk.getBacking.getChangeId) Получить ChangeID соответствующий снимок, созданный на шаге 1.
• Step 3Выполните второй снимок.
• Step 4: Проведение до резервного копирования, вызов vShpere API(queryChangedDiskAreas) Для того, чтобы передать снимок снимок , созданный на шаге 2 в качестве параметра , чтобы получить изменение в первой временной точке снимка (передняя конечная точка) ко второй временной точке снимка (задняя конечная точка) изменения блоков данных и резервные копии этих блоков данных.

queryChangedDiskAreas

ТОС изменения быстро приобретает прототип QueryChangeDiskares:

Его выход аналогичен:

Каждый формат (offset，length) Представляет смещение блока данных переменных.

NOTE: Когда элемент конфигурации СВТА включен без виртуальной машины снимки и вызывает функцию QueryChangeDiskares, ChangeId является активным пунктом * 。

blog.vmpress.org

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

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

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

Формат VMFS (также известный как FLAT) имеет простую структуру и используется для thick и thin дисков. Каждый виртуальный диск хранится в виде нескольких файлов — файла дескриптора (.vmdk), бинарного файла с данными (-flat.vmdk) и опционального файла, хранящего информацию об измененных блока ( -ctk.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 и так далее.

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

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

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

Sparse диски

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

Sparse диск создается «поверх» родительского диска (другого Sparse диска или базового VMFS диска), формируя своеобразную цепочку, или дерево, если из одного родительского диска создано несколько Sparse дисков. 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). Это не всегда верно, так как я намеренно опускаю ряд технических деталей по хранению файлов маленького размера внутри файловых дискрипторов или суб-блоков, чтобы не перегружать читателей. В реальности размер дискового пространства, с которым растет Sparse диск, составляет 16 МБ. Умудренный читатель спросит — почему для Sparse диска единоразово выделяется больше места, чем для Thin диска (16 МБ против 1 МБ)? Я не нашел достоверной информации по этому поводу, но могу предположить, что это сделано для того, чтобы уменьшить количество блокировок VMFS, которые возникают при увеличении размера файла и необходимости выделения новых файловых блоков — Sparse диски растут гораздо быстрее, т.к. в них записываются не только новые блоки данных, но и изменения в блоках родительских дисков.

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

CID=ec393eec
parentCID=ffffffff

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

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

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

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

Структура Sparse диска приведена на рисунке.

• 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 или полезные данные.

Более детальная информация по структуре заголовка приведена в документе Virtual Disk Format 5.0.

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

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

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

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

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

Рассмотрим пример с адресацией GDE, GTE и блоков данных внутри Sparse диска. Создадим Sparse диск и с помощью какой-нибудь низкоуровневой утилиты из гостевой ОС запишем в первый сектор диска тестовые данные — 512 байт со значением 0xff. Поскольку мы знаем, что это первый блок на диске, то его адрес будет хранится в первой GTE, в таблице GT, которая адресуется первой GDE. Для того, чтобы найти нужный блок с данными, определим адрес первой GDE по смещению gdOffset (0x800). Далее из GDE определим адрес GT (0x1000). Первая ячейка GTE указывает на расположение первого блок Sparse диска (находится по смещению 0x5000).

По этой причине, данные, хранящиеся в 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

16 МБ за счет места, которое занимает заголовок, GDE и GTE ячейки.

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

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

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

What is VMware CTK file format?

A file with extension CTK can be found by using the VMware datastore browser, in the same folder as other VMDK file, where the VM stores all its files (VMDK, VMX, VMSD, NVRAM….). What is VMware CTK file for? The CTK file is used by Changed Block Tracking (CBT). It lists the block changes made since last backup. The first backup of a VM has to be a full backup, only then onwards the CBT reads the content of the CTK file, and back up changed blocks only instead of full VM backup. Every block has got a time stamp which says where the location of modified block is.

If you don’t see the CTK file, then certainly the CBT just isn’t activated. The CBT functionality is available for VMs with the virtual hardware version isn’t 7 and higher. The CBT in fact appeared first in vSphere 4. The CBT is usually activated by backup products, like Veeam or VDP automatically during the first backup. The CBT can also be activated manually, through the vSphere web client OR editing directly the configuration file of a particular VM (VMX file).

The CBT enabled allows up to 10 times faster backups.

What is VMware CTK, and what’s inside the file?

The file can be several Mb in size in total. The size of this file is fixed and does not grow over its initial size. Only if you grow the size of a virtual disk, than the size of CTK file changes. The real size of this CTK file depends on the size of a virtual disk, but it’s about .5MB for every 10 GB of virtual disk size. The CTK’s file content stores the state of each block, for tracking purposes, and is using sequence numbers. Those sequence numbers are used by backup application, to see if a block has changed its state or not.

The CTK file can grow quite a bit, but if CBT enabled, there should be only one CTK file per Virtual Disk (VMDK). So if you have VM with one single VMDK disk, you should see only one single CTK file. If there is more than one CTK file, than probably your backup software has left some behind while not cleaning properly the temporary snapshots taken during the backup.

To disable Changed Block Tracking (CBT), make sure to delete all snapshots before.

Which kind of disk formats works in CBT?

• Thin and Thick virtual disks
• VMDK and RDM (virtual only)

Usual advantages of CBT are the obvious gain of speed of backups and lower CPU utilization on the host.