Что за файл ctk vmdk

Обновлено: 01.07.2024

Ошибка VMware Workstation and Device/Credential Guard are not compatible

При включении VMware Workstation на Windows 10 может возникнуть ошибка со следующим текстом:

Чаще всего эта ошибка возникает из-за того, что включено ПО Device Guard — оно помогает защитить систему от вредоносных файлов. Device Guard позволяет настроить список файлов, которые Windows будет считать безопасными. Если на компьютер попадут файлы, которые не входят в список, система автоматически удалит их. Работе VMware в таких случаях мешает компонент Hyper-V.

Чтобы отключить Hyper-V, необходимо внести изменения в реестр Windows. Перед отключением Hyper-V обязательно создайте резервную копию ОС. В поисковую строку введите «gpedit.msc» и нажмите Ок. Перейдите в раздел «Политика Локальный компьютер» — «Конфигурация компьютера» — «Административные шаблоны» — «Система» — «Device Guard». Дважды кликните на строку «Включить средство обеспечения безопасности на основе виртуализации». В новом окне выберите пункт «Отключено» и нажмите Ok. Перейдите в раздел «Панель управления» — «Программы и компоненты» — «Включение или отключение компонентов Windows». Отключите Hyper-V и нажмите Ок. Если система предложит перезагрузить компьютер, откажитесь от перезагрузки.

Откройте командную строку от имени администратора. Поочередно выполните команды:

Затем перезагрузите компьютер.

Ошибка Cannot open the disk

Ещё одна распространенная ошибка при запуске виртуальной машины в VMware — Cannot open the disk. Её текст следующий:

На следующей строке будет указана одна из причин этой ошибки. Разберём, что означает каждая:

1) Failed to lock the file. Это значит, что процесс, который вы используете, не может открыть файл. При этом файл используется другим процессом. Что может привести к ошибке:

при работе с ВМ вы пытаетесь запустить вторую ВМ, используя тот же VMX-файл,
вы запустили ВМ с подключенным диском при помощи утилиты vmware-mount,
вы добавили виртуальный диск к ВМ, которая уже используется.

2) The parent virtual disk has been modified since the child was created. Эта ошибка возникает, если повреждён снимок ВМ.

3) The destination file system does not support large files означает, что на целевом хранилище невозможно открыть файл ВМ того же размера.

4) Could not open/create change tracking file. Эта проблема может возникнуть, если файл filename-ctk.vmdk создавался ранее и не очищался перед созданием новой ВМ. Здесь filename — это название вашего файла.

5) Cannot allocate memory. Тот случай, когда в модуле VMFS не хватает места.

6) The file specified is not a virtual disk возникает в случаях, если повреждён .VMDK-файл дескриптора.

7) Insufficient permission to access file. Такая проблема может возникнуть при использовании хранилищ типа NFS. Она сообщает о том, что экспорт NFS работает неправильно, так как права на чтение и запись файла не даны либо даны некорректно.

Единого решения для этого типа ошибки нет. Чаще всего причина связана с локальными настройками компьютера. Рекомендации по исправлению ошибки описаны в официальной документации.

Появилась штука CBT достаточно давно, и у Михаила Михеева информация в блоге аж от 28 декабря 2009 года. Описано там как включать и отключать эту штуку.

Естественно, это штукой на благо использует "собственное" средство резервного копирования VMware VDP. VDP я активно пользуюсь, однако в последнее время стал замечать, что бэкапы делаются долго, а их размеры для некоторых VM равны полным копиям VM. Стал грешить на CBT, проверил для VM ключик ctkEnabled на true - все в порядке. Стал искать другие закономерности в "неправильных" VM с "неправильными" бэкапами и оказалось, что всему виной Storage vMotion в моем случае под личиной SDRS.

Самое печальное, что после Storage vMotion CBT перестает работать вообще: и на первом бэкапе (что логично) и на всех последующих. Т.е. если Вы сделали первый бэкап с помощью VDP и включенным для VM CBT, потом случился Storage vMotion, то все последующие бэкапы даже в отсутствии Storage vMotion совершенно не интересуются измененными блоками. Восстановление с использованием CBT тоже становится невозможным.

Для начала надо понять, что нам важнее бэкап с использованием CBT или Storage vMotion.

- Если выбором будет Storage vMotion - ключик ctkEnabled=false и забыли про все плюшки CBT.

- Если беда уже случилось, и мы хотим спасти овец (использовать CBT) делаем так:

4. удаляем *-ctk.vmdk (все *-ctk.vmdk они создаются для каждого диска VM, для которого включен CBT)

p.s> CBT использем в том числе и Veeam, к сожалению его нет под рукой, так что проверить как такая ситуация обрабатывается Veeam (происходит ли обнуление *-ctk.vmdk после Storage vMotion) нет возможности.

Heartbleed VMware

Hearbleed'ом зацепило, естественно, и продукты VMware. Так что придется пропатчиться.

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

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

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

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

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

Бинарный файл с данными имеет плоскую структуру, такую же как файл .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).

Учтите, что сектора, которые в базовом 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

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.

Change Block Tracking (CBT) появился в vSphere 4.0 и позволяет VMkernel-у отслеживать блоки виртуальных дисков (*.vmdk) виртуальных машин, которые изменились с определенного момента времени.

Вот те преимущества которые стали доступны с появлением на свет Change Block Tracking-а в vSphere 4:

Повышает скорость резервного копирования и восстановления, репликации виртуальных машин.
Улучшает работу/производительность Storage VMotion (так как она тесно связана с ней).

CBT может быть доступна/использована приложениями сторонних разработчиков, как часть vStorage APIs for Data Protection-а. Приложение может, используя данный API, посылать запросы VMkernel-у чтобы получить информацию о изменившихся блоках данных виртуальных дисков после последнего бекапа. Так что Change Block Tracking повышает скорость резервного копирования и восстановления виртуальных машин.

Требования у CBT простые:

vSphere 4.x
Virtual hardware version 7
Любые типы датасторов (NFS, iSCSI)

CBT не работает в любом из следующих случаев:

Change Block Tracking-ом занимается VMkernel а не файловая система VMFS. Также стоит запомнить, что CBT не работает с блоками VMFS-а, а использует свои CBT блоки для работы. Размер этих блоков зависит от размера VMDK файла.

CBT не является глобальной функцией и может быть использована/включена для каждой виртуальной машиной по отдельности.

По умолчанию CBT выключен и причиной этого скорее всего то что при работе он создает маленький overhead. Такие приложения как Veeam Backup & Replication и VMware Data Recovery (т.е. те которые используют CBT в своих целях) сами включают поддержку CBT если это возможно и нужно.

CBT можно включить разными методами, к примеру используя vSphere Client, vSphere SDK или же PowerCLI. Для того чтобы нам это сделать из vSphere Client-а нам надо будет добавить конфигурационные параметры для каждой виртуальной машины для которых мы хотим это сделать. Для этого:

1. Выключаем VM. Заходим Edit Settings, переходим на вкладку Options, выбираем Advanced>General Settings и жмем Configuration Parameters.

2. Добавляем новый Row (Add Row), в поле Name вписываем параметр ctkEnabled а в поле Value значение true (ctkEnabled = "TRUE"). Это включит на нашей виртуальной машине поддержку CBT.

Читайте также: