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

Сегодня я хотел бы рассказать об особенностях архитектуры «разреженных» (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 диска приведена на рисунке.

Заголовок Sparse файла (COW Header) включает в себя следующие поля (это далеко не все поля, присутствующие в заголовке):

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

Рассмотрим пример заголовка Sparse диска, созданного с базового диска размером 32 МБ.

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

Sparse файлы используют двухуровневую иерархию метаданных для адресации блоков с данными:

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

GD идет следом за заголовком COW Header. GD состоит из ячеек Granular Directory Entry (каждая размером 4 байта). Ячейки GDE используются для хранения смещения (в 512 байтный секторах) по которому располагается таблица Granular Table. Ячейки GDE всегда располагаются последовательно. Адрес первой GDE ячейки указан в поле заголовка (gdOffset) и равен 4 секторам = 0x800 = 2048 байтам. Размер/количество ячеек GDE в Granular Directory зависит от максимально возможного размера Sparse диска, а также от размера блока данных, который может адресовать одна запись в таблице (gtcoverage).

Granual Table, на которую ссылается GDE, в свою очередь, состоит из 4096 ячеек Granular Table Entry, каждая из которых хранит смещение, по которому располагается блок данных (Grain Data). Размер блока данных, адресуемого GTE, указывается в заголовке в поле grainsize. Для Sparse дисков, создающихся гипервизором ESXi размер блока данных составляет 1 сектор (512 байт). GT создаются по мере необходимости, при первой операции записи в 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

Размер 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.

При подготовке использовались следующие материалы:

  1. https://kb.vmware.com/s/article/1015180
  2. https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf
  3. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/sesparse-vsphere55-perf-white-paper.pdf
  4. http://sanbarrow.com/vmdk-handbook.html

vSphere Change Block Tracking | «V» for Virtualization

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 не работает в любом из следующих случаев:

  • Если virtual hardware version виртуальной машины ниже чем 7
  • С RDM дисками в physical compatibility моде.
  • Когда виртуальный диск использует/подключен к общей виртуальной  SCSI шине (shared virtual SCSI bus).

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.

3. После этого для каждого виртуального диска параметр “scsi#:#.ctkEnabled”, где #:# надо заменить номером controller/disk-а (0:0, 0:1,…), со значением “true”. Для примера у меня виртуальная машина с двумя виртуальными дисками.

4. Жмем OK и сохраняем изменения.

После запуска данной виртуальной машины CBT начнет работать и хранить все информацию о изменённых блоках виртуального диска виртуальной машины, для которого включен Change Block Tracking, в файле *-ctk.vmdk. Этот файл создается для каждого виртуального диска по отдельности (т.е. у каждого виртуального диска виртуальной машины свой *-ctk.vmdk файл) в фолдэре где находится сама виртуальная машина. Размер *-ctk.vmdk файла постоянный и не увеличивается в течении времени, до тех пор пока мы не увеличим размер самого диска. Значит так он тока зависит от размера виртуального диска для которого он был создан. Примерно это зависимость следующая, ~500KB на 10GB виртуального диска.  

 

Вот список полезных статей на тему Changed Block Tracking-а в vSphere:

  • Статья Eric Siebert-а на Тechtarget-е: What is Changed Block Tracking in vSphere?
  • Punching Clouds: VMkernel’s Change Block Tracking Means Faster Backups and Recovery Performance
  • Yellow/Bricks: Changed block tracking?
  • VMware Uptime Blog: VMware Data Recovery Taking Advantage of vSphere 4
  • Technical Note: Designing Backup Solutions for VMware vSphere – VMware vStorage APIs for Data Protection

Like this:

Like Loading…

Что такое формат файла VMware CTK?

Владан СЕГЕТ | Последнее обновление:

Общие ресурсы

Файл с расширением CTK можно найти с помощью браузера хранилища данных VMware в той же папке, что и другие файлы VMDK, где ВМ хранит все свои файлы (VMDK, VMX , VMSD, NVRAM…. ). Для чего нужен файл VMware CTK? Файл CTK используется функцией отслеживания измененных блоков (CBT). В нем перечислены изменения блоков, сделанные с момента последнего резервного копирования. Первая резервная копия ВМ должна быть полной резервной копией, только затем CBT считывает содержимое файла CTK и создает резервную копию только измененных блоков вместо полной резервной копии ВМ. Каждый блок имеет отметку времени, в которой указано, где находится измененный блок.

Если вы не видите файл CTK, значит CBT просто не активирован. Функционал CBT доступен для ВМ с версией виртуального оборудования не 7 и выше. На самом деле CBT впервые появился в vSphere 4. CBT обычно автоматически активируется продуктами резервного копирования, такими как Veeam или VDP, во время первого резервного копирования. CBT также можно активировать вручную через веб-клиент vSphere ИЛИ непосредственно отредактировав файл конфигурации конкретной ВМ (файл VMX).

Включенный CBT позволяет выполнять до резервных копий в 10 раз быстрее .

Что такое VMware CTK и что внутри файла?

Общий размер файла может составлять несколько мегабайт. Размер этого файла фиксирован и не превышает его исходного размера. Только при увеличении размера виртуального диска изменяется размер файла CTK. Реальный размер этого файла CTK зависит от размера виртуального диска, но он составляет около 0,5 МБ на каждые 10 ГБ размера виртуального диска. Содержимое файла CTK хранит состояние каждого блока в целях отслеживания и использует порядковые номера. Эти порядковые номера используются приложением резервного копирования, чтобы увидеть, изменился ли блок в своем состоянии или нет.

Файл CTK может значительно увеличиться, но если CBT включен, должен быть только один файл CTK на виртуальный диск (VMDK) . Поэтому, если у вас есть виртуальная машина с одним единственным диском VMDK, вы должны увидеть только один файл CTK. Если существует более одного файла CTK, возможно, ваше программное обеспечение для резервного копирования оставило некоторые из них, не очищая должным образом временные снимки, сделанные во время резервного копирования.

Чтобы отключить отслеживание измененных блоков (CBT), убедитесь, что перед этим были удалены все снимки.

Какие форматы дисков работают в CBT?

  • Тонкие и толстые виртуальные диски
  • VMDK и RDM (только виртуальные)

Обычными преимуществами CBT являются очевидное увеличение скорости резервного копирования и более низкая загрузка ЦП на хосте.

Источники:

  • Поддержка IBM
  • Veeam KB1113
  • VMware vSphere 5 — создание виртуального центра обработки данных (VMware Press)
  • KB1031873 VMware, в котором описывается, как активировать CBT на виртуальных машинах (если появляется ошибка «Неверная конфигурация CBT»).
  • Отслеживание измененных блоков (CBT) на виртуальных машинах KB: 1020128 – общая информация о CBT
  • Объединение снимков (1007849)
  • Консолидация моментальных снимков в vSphere 5 (2003638).

Общие ресурсы

Подробное описание всех файлов, составляющих виртуальную машину

Вопросы и ответы

Вы когда-нибудь задумывались, для чего предназначен каждый из файлов, составляющих виртуальную машину?

Вот подробный список всех файлов, составляющих виртуальную машину:

Файл . nvram
Этот файл содержит CMOS/BIOS для виртуальной машины. BIOS основан на PhoenixBIOS 4.0 Release 6 и является одним из наиболее успешных и широко используемых BIOS и совместим со всеми основными стандартами, включая USB, PCI, ACPI, 1394, WfM и PC2001. Если файл NVRAM удален или отсутствует, он будет автоматически воссоздан при включении виртуальной машины. Любые изменения, сделанные в BIOS через программу Setup (F2 при загрузке), будут сохранены в этом файле. Этот файл обычно имеет размер менее 10 КБ и не имеет текстового (двоичного) формата.

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

flat.vmdk файл — это фактический необработанный файл диска, который создается для каждого виртуального жесткого диска. Почти все содержимое файла .vmdk представляет собой данные виртуальной машины, а небольшая часть предназначена для служебных данных виртуальной машины. Этот файл будет примерно такого же размера, как ваш виртуальный жесткий диск.

Файл .vmdk — это уже не файл, содержащий необработанные данные. Вместо этого это файл дескриптора диска, который описывает размер и геометрию файла виртуального диска. Этот файл имеет текстовый формат и содержит имя файла flat.vmdk, с которым он связан, а также тип адаптера жесткого диска, сектора диска, головки и цилиндры и т. д. Один из этих файлов будет существовать для каждого виртуального жесткого диска. который назначен вашей виртуальной машине. Вы можете определить, с каким файлом flat.vmdk он связан, открыв файл и посмотрев поле Extent Description.

Файл delta.vmdk — это разностный файл, созданный при создании моментального снимка виртуальной машины (также известный как журнал REDO). Когда вы делаете снимок виртуальной машины, она прекращает запись в базовый vmdk и начинает записывать изменения в дельта-файл моментального снимка. Дельта моментального снимка изначально будет небольшой, а затем начнет расти по мере внесения изменений в базовый файл vmdk. Дельта-файл представляет собой растровое изображение изменений в базовом vmdk, поэтому он никогда не может вырасти больше, чем базовый vmdk. Дельта-файл будет создан для каждого моментального снимка, который вы создаете для виртуальной машины. Эти файлы автоматически удаляются при удалении или восстановлении моментального снимка в диспетчере моментальных снимков.

Файл -ctk.vmdk — это специальный файл, который создается в домашнем каталоге каждой виртуальной машины для каждого виртуального диска, на котором включена функция отслеживания блоков изменений (CBT). CBT — это новая функция, представленная в vSphere. Помимо использования vSphere, предварительным условием для использования CBT является то, что виртуальная машина должна использовать виртуальное оборудование версии 7. Размер этого файла фиксирован и не превышает его начального размера, пока вы не увеличите размер виртуального диска. Размер этого файла зависит от размера виртуального диска, который составляет примерно 0,5 МБ на каждые 10 ГБ размера виртуального диска. Внутри этого файла сохраняется состояние каждого блока для целей отслеживания с использованием порядковых номеров, которые могут сообщать приложениям, изменился блок или нет. Один из этих файлов будет существовать для каждого виртуального диска, на котором включена CBT.

Файл .vmx
Этот файл является основным файлом конфигурации для виртуальной машины. Когда вы создаете новую виртуальную машину и настраиваете для нее параметры оборудования, эта информация сохраняется в этом файле. Этот файл имеет текстовый формат и содержит записи для жесткого диска, сетевых адаптеров, памяти, ЦП, портов, параметров питания и т. д. Вы можете либо редактировать эти файлы напрямую, если знаете, что добавить, либо использовать графический интерфейс VMware® (Edit Settings на виртуальной машине), который автоматически обновит файл.

.vswp file
Это файл подкачки виртуальной машины (в более ранних версиях ESX был файл подкачки для каждого хоста), который создается для обеспечения чрезмерного выделения памяти на сервере ESX. Файл создается при включении виртуальной машины и удаляется при ее выключении. По умолчанию, когда вы создаете виртуальную машину, резервирование памяти устанавливается равным нулю, что означает, что память для виртуальной машины не резервируется, и потенциально она может быть перераспределена на 100%. В результате создается файл vswp, равный объему памяти, назначенному виртуальной машине, за вычетом резервирования памяти, настроенного для виртуальной машины. Таким образом, виртуальная машина, настроенная с 2 ГБ памяти, создаст файл vswp размером 2 ГБ при включении, если вы установите резервирование памяти на 1 ГБ, тогда будет создан только файл vswp размером 1 ГБ. Если вы укажете резервирование 2 ГБ, будет создан файл размером 0 байт, который он не использует. Когда вы укажете резервирование памяти, физическая оперативная память хоста будет зарезервирована для виртуальной машины и не будет использоваться другими виртуальными машинами на этом хосте. Виртуальная машина не будет использовать этот файл vswp, пока на хосте доступна физическая оперативная память. Как только вся физическая оперативная память используется на хосте всеми его виртуальными машинами, и она становится перегруженной, тогда виртуальные машины начинают использовать свои файлы vswp вместо физической памяти. Поскольку файл vswp является файлом на диске, это повлияет на производительность виртуальной машины, когда это произойдет. Если вы укажете резервирование, а на хосте недостаточно физической оперативной памяти при включении виртуальной машины, то виртуальная машина не запустится.

Файл .vmss
Этот файл создается, когда виртуальная машина переводится в режим приостановки (паузы) и используется для сохранения состояния приостановки. По сути, это копия оперативной памяти виртуальной машины, и она будет на несколько мегабайт больше, чем максимальная оперативная память, выделенная виртуальной машине. Если вы удалите этот файл, когда виртуальная машина находится в состоянии приостановки, она запустит виртуальную машину из обычной загрузки, а не из состояния, в котором она была в момент приостановки. Этот файл не удаляется автоматически, когда виртуальная машина выходит из режима ожидания. Как и файл vswp, этот файл будет удален только тогда, когда виртуальная машина будет выключена (не перезагружена). Если файл vmss существует из предыдущей приостановки и виртуальная машина снова приостанавливается, то предыдущий файл повторно используется для последующих приостановок. Также обратите внимание, что если файл vswp присутствует, он удаляется, когда виртуальная машина приостанавливается, а затем создается заново, когда виртуальная машина снова включается. Причина этого в том, что виртуальная машина по существу выключена в состоянии приостановки, ее содержимое ОЗУ просто сохраняется в файле vmss, поэтому ее можно быстро снова включить.

.log file
Это файл, в котором хранится журнал активности виртуальной машины. Он полезен при устранении неполадок, связанных с виртуальной машиной. Каждый раз, когда виртуальная машина выключается, а затем снова включается, создается новый файл журнала. Текущий файл журнала для виртуальной машины всегда vmware.log. Старые файлы журнала увеличиваются с помощью -# в имени файла, и до 6 из них будут сохранены. (например, vmware-4.log) Старые файлы .log всегда можно удалить по желанию, последний файл .log можно удалить при выключении виртуальной машины. Поскольку файлы журналов не занимают много места на диске, большинство администраторов разрешают им не более

Файл .vmxf
Это дополнительный файл конфигурации в текстовом формате для виртуальных машин, входящих в группу. Обратите внимание, что файл .vmxf остается, если виртуальная машина удаляется из команды. Объединение виртуальных машин — это функция VMware Workstation, которая включает в себя возможность назначать несколько виртуальных машин в группу, которую администраторы могут затем включать и выключать, приостанавливать и возобновлять как единый объект, что делает ее особенно полезной для тестирования клиент-серверных сред. Этот файл все еще существует с виртуальными машинами сервера ESX, но только в целях совместимости с рабочей станцией.

Файл .vmsd
Этот файл используется для хранения метаданных и информации о моментальных снимках. Этот файл имеет текстовый формат и будет содержать такую ​​информацию, как отображаемое имя моментального снимка, идентификатор пользователя, имя файла на диске и т. д. Первоначально это файл размером 0 байт, пока вы не создадите свой первый снимок виртуальной машины, и с этого момента он будет заполнять файл. и продолжайте обновлять его всякий раз, когда делаются новые снимки. Этот файл не очищается полностью после создания моментальных снимков. После того, как вы удалите снимок, он все равно оставит поля в файле для каждого снимка и просто увеличит uid и установит имя Consolidate Helper, предположительно для использования с Consolidated Backups

Файл .vmsn
Это файл состояния моментального снимка, в котором хранится точное рабочее состояние виртуальной машины на момент создания этого моментального снимка. Этот файл будет либо маленьким, либо большим, в зависимости от того, решите ли вы сохранить память виртуальной машины как часть моментального снимка.

Posted inПопулярное