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

Оригинал данной статьи находится здесь, я же являюсь не более, чем пристрастным переводчиком данного текста. 🙂 Статья рекомендуется к прочтению всем адептам VMware VI3 и VMware vSphere.

Введение

Вчера я потратил полдня, решая проблему, возникшую из-за рассинхронизации снимка VMware VI3. Это был неприятный опыт, зато я узнал о важности CID-цепи!
После нескольких часов пинания мертвой ВМ, мой коллега, Дан, и я натолкнулись на CID-цепи.
Мы пришли к выводу, что .vmdk-файлы, которые создаются в VI3 каждый раз при снятии снимка, связаны с другими .vmdk через сгенерированные случайным образом значения CID. VI3 присваивает каждому новому файлу снимка CID, причем это значение меняется при каждой перезагрузке ВМ.
Если цепь CID разрывается, то ВМ не может подключить свой виртуальный диск.

Проблема

Ваши виртуальные диски не подключаются при включении ВМ, вы получите следующее сообщение об ошибке:
“Cannot open the disk ‘/vmfs/volumes/INSERT SPECIFIC VALUE HERE.vmdk’ or one of the snapshot disks it depends on.
Reason: The parent virtual disk has been modified since the child was created.”
“Не удается открыть диск ‘/vmfs/volumes/lalala.vmdk’ или один из файлов снимков, от которых он зависит.
Причина: первичный виртуальный диск был изменен, после создания вторичного.”

Черт!

Что вам делать?!
1) Только не паникуйте 🙂
2) Полностью выключите ВМ.
3) Ничего не изменяйте!
4) Прочтите эту статью!
Если вы не вносили изменения в .vmdk файлы, вероятнее всего, у вас получится исправить эту проблему.

Анализ

Эта проблема возникла, вероятно, потому что вы сделали один или несколько снимков одного или нескольких виртуальных дисков, связанных с ВМ, и снимки рассинхронизировались. Скорее всего, вы получили эту проблему в средах ESX/VI3.
Причина этой проблемы связана с тем, как VI3 управляет снимками и дельтами изменений относительно первоначального виртуального диска (.vmdk). Вероятно, нарушилась логика иерархии снимков, и вторичные .vmdk-файлы, уже не ссылаются на первичные.
Ключ к складыванию головоломки из снимков находится в восстановлении цепи CID.
Каждому .vmdk файлу назначается свой CID-идетификатор. Кроме того, в каждом .vmdk содержится ссылка на CID и .vmdk предыдущего (родительского) файла. CID “родителя” должен указывать на .vmdk файл, созданный непосредственно перед созданием снимка.
При загрузке ВМ CID в .vmdk-файлах меняется на случайным образом. Если после загрузки ВМ цепь CID не в том же состоянии, как и до загрузки, то связь вторичный CID -> первичный CID нарушается. Таким образом VI3 определяет подлинность снимков. Единственный способ вновь синхронизировать CID-цепь – вручную отредактировать все .vmdk файлы в этой цепи.
Пример CID-цепи:
Первичный .vmdk = vdisk.vmdk
.vmdk, созданный после 1 снимка = vdisk-000001.vmdk
.vmdk, созданный после 2 снимка = vdisk-000002.vmdk
Если эта цепочка нарушается, то:
вручную делаем ссылку vdisk-000002.vmdk -> vdisk-000001.vmdk;
vdisk-000001.vmdk -> vdisk.vmdk.

Обратим внимание на три поля в .vmdk-файле:
— поле CID;
— ссылка на parentCID;
— поле parentNameHint.
Примечание: первичный .vmdk не содержит поля «parentNameHint», а его «parentCID» всегда равняется «ffffffff».

Примеры

Пример содержимого первичного vdisk.vmdk:
[root@myvi3server]# cat vdisk.vmdk
# Disk DescriptorFile
version=1
CID=7f81b951
parentCID=ffffffff
createType=»vmfs»
# Extent description
RW 50331648 VMFS «vdisk-flat.vmdk»
# The Disk Data Base
#DDB
ddb.virtualHWVersion = «4»
ddb.geometry.cylinders = «3133»
ddb.geometry.heads = «255»
ddb.geometry.sectors = «63»
ddb.adapterType = «lsilogic»
ddb.toolsVersion = «7202»

Пример второго файла — vdisk-000001.vmdk:
[root@myvi3server]# cat vdisk-000001.vmdk
# Disk DescriptorFile
version=1
CID=8eb633b8
parentCID=7f81b951
createType=»vmfsSparse»
parentFileNameHint=»/vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername/vdisk.vmdk»
# Extent description
RW 50331648 VMFSSPARSE «vdisk-000001-delta.vmdk»
# The Disk Data Base
#DDB
ddb.toolsVersion = «7202»
Примечание: файл из “parentNameHint” находится на iSCSI SAN. Длинный шестнадцатиричный GUID – идентификатор этого VMFS-хранилища.

Пример третьего — vdisk-000002.vmdk:
[root@myvi3server]# cat vdisk-000002.vmdk
# Disk DescriptorFile
version=1
CID=249e6aff
parentCID=8eb633b8
createType=»vmfsSparse»
parentFileNameHint=»sryulris0cogp01-000001.vmdk»
# Extent description
RW 50331648 VMFSSPARSE «vdisk-000002-delta.vmdk»
# The Disk Data Base
#DDB
ddb.toolsVersion = «7202»
Примечание: Путь к файлу в «parentNameHint» поле указывает на файл, который располагается в том же каталоге, что и vdisk-000002.vmdk. Если файл находится в другом каталоге, то в пути указывается каталог.

Решение

Следующие шаги синхронизируют файлы снимков VI3 так, что ESX/ESXi успешно проверит их связь друг с другом, а также их подлинность:
Примечание: Выполните следующие действия в текстовом редакторе. Сохраните резервную копию оригинального файла до внесения каких-либо изменений.

Измените vdisk-000002.vmdk:
1) Запомним CID у vdisk-000001.vmdk (= 8eb633b8);
2) Запомним путь к vdisk-000001.vmdk (= локальный каталог);
3) Исправьте parentCID для vdisk-000001.vmdk -> ParentCID=8eb633b8;
4) Исправьте parentNameHint на vdisk-000001.vmdk -> ParentFileNameHint=»vdisk-000001.vmdk».

Измените vdisk-000001.vmdk:
1) Запомним CID у vdisk-000001.vmdk (=7f81b951);
2) Запомним путь к vdisk-000001.vmdk (=»/ vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername /);
3) Исправьте parentCID для vdisk.vmdk -> ParentCID=7f81b951;
4) Исправьте parentNameHint на vdisk.vmdk файл -> ParentFileNameHint=»/ vmfs/volumes/478b9802-ce7ed955-96a4-0015c5fd9308/servername/vdisk.vmdk».

Если виртуальные диски не были изменены, вас можно поздравить. Если же виртуальные диски были изменены или вы удаляли их из виртуальной машины, а затем добавляли снова, необходимо будет вручную изменить настройки соответствующего виртуального SCSI-контроллера в файле настроек ВМ — .vmx-файле (указать .vmdk последнего снимка в вашей CID-цепи).

Примечание: Выполните следующие действия в текстовом редакторе. Естественно, сохраните резервную копию исходного файла до внесения каких-либо изменений. 🙂

Измените servername.vmx:
1) Найдите SCSI контроллер, на котором находится виртуальный диск, который мы восстанавливаем. Первый виртуальный диск, как правило, назначается на SCSI-контроллер scsi0:0, второй — scsi0:1, а третий — scsi0:2;
2) Предположим, что мы восстанавливаем второй виртуальный диск. Найдите раздел, ссылающийся на scsi0:1;
3) Укажите в поле ссылку на .vmdk последнего снимка в нашей цепи:
scsi0:1.fileName=»/ vmfs/volumes/46fd62d479749c9697e30015c5fd9308/servername/vdisk-000002.vmdk».
Примечание: Путь к файлу может быть изменен, хотя по умолчанию снимки сохраняются в том же каталоге, что и первичный .vmdk (vdisk.vmdk). Поэтому введите полный путь к .vmdk снимка (vdisk-000002.vmdk), включая iSCSI GUID и т.д…
4) Сохраните файл и перезагрузите ВМ;
5) Если ВМ не загружается, или выдает ошибку “The parent virtual disk has been modified since the child was created.”, проверьте иерархию CID и пути к файлам, а затем повторите попытку. Если ВМ прежнему не загружается, а CID-сеть и пути к файлам корректны, то первичный или последующие .vmdk-файлы, вероятно, были изменены некорректным образом и их не удается восстановить!

Запись опубликована в рубрике Статьи с метками , . Добавьте в закладки постоянную ссылку.

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

  1. nomad говорит:

    Хорошая статья, полезная для понимания принципа создания снапшотов в VM.

  2. Андрей Вахитов говорит:

    thnx 😉
    Обращайтесь еще

  3. Андрей Вахитов говорит:

    Как-то мимо меня прошло значительное изменение функционала по удалению снапшотов.
    Base disk — 10Gb
    Snap1 — 1 Gb
    Snap2 — 1 Gb
    Snap3 — 10Gb
    Поведение при нажатии кнопки Delete All до vSphere 4 Up2:
    Snap3->Snap2, Snap2->Snap1, Snap1->Base, после этого снапшоты удаляются.
    Так как snap2 может вырасти до 11Gb, snap1 — до 12Gb, то перед удалением снапшотов нам нужно иметь свободными
    10+12+11+10=43Gb (при объеме диска виртуальной машины в 10Gb).
    После Update2:
    Snap1->Base, Snap2->Base, Snap3->Base, после этого снапшоты удаляются.
    Требуемое место: 10+1+1+10 — 22Gb.
    Таким образом, применение апдейта почти ВДВОЕ снижает требования по диску к удалению снапшотов.
    Правда, есть и косяк — пользователям ESX3,5 необходима проплаченная подписка для перехода на ESX4.

  4. Илья говорит:

    Внесу еще одну ясность в статью. Лично я пол ночи убил чтобы до меня дошло.
    Получил ошибку при запуске ВМ «parent virtual disk has been modified since the child was created». Причина была в том что Windows на ВМ умер, и я решил достать с диска некоторые данные. Подключил vdisk.vmdk к другой рабочей машине, но нужных данных там не оказалось… а CID идентификатор изменился.
    А отдельно vdisk-000001.vmdk не открывается.
    В общем я сэкономил бы кучу времени если бы в статье было написано следующее:

    Если в vSphere Сlient открыть DataStore Browser и зайти в папку с ВМ то файлы виртуальных дисков отображаются так:
    vdisk.vmdk (100гб)
    На самом деле каждый файл (.vmdk) это два файла!!
    Маленький vdisk.vmdk (4кб) и большой vdisk-flat.vmdk (100гб). Если начать скачивать виртуальный диск к себе на комп, то первым скачивается маленький файл, в котором и нужно делать изменения указанные в статье, второй просто отменяем, блокнотом вносим изменения CID и закачиваем обратно.

    Я про это не знал, собирался уже HEX эдитором 100 гиговый файл ковырять =))
    Спасибо за статью)

  5. Mister Nobody говорит:

    2Илья
    Просто все админы vSphere в курсе того, что файл дисков состоит из нескольких файлов ;). Если будут снапшоты или влючен CBT, то файлов будет поболее.
    Как говорится, учите матчасть.

  6. Creator969 говорит:

    Спасибо за статью, очень выручил 🙂

  7. Евгений говорит:

    Друзья, помогите разобраться с такой проблемой в vmware. Где взять эти файлы текстовые для редактирования??? всё понял, но вот сами файлы.
    История такова: скопировал vmdk и снапшот, снес vmware, установил заново, установил ХР , скопировал всё обратно , не работает, выдает вышеописанную ошибку — рассинхронизация.

  8. Евгений говорит:

    Up

  9. Андрей Вахитов говорит:

    Это дескрипторы виртуальных дисков (файлы vm_name.vmdk). Не путать дескрипторы с «толстым» файлом vm_name-flat.vmdk.

  10. Евгений говорит:

    Спасибо за ответ!
    А если дескриптора нет,как быть?
    В новой XP удалил диск , прицепил другой, который создавал 2 года назад(на пожарный случай) — работает! Удалил и его, думал — наконец-то, и прицепил новый (тот, который нужен!) — не работает… опять про родителя ругается… Файлы дисков идентичны , но первый(2х летний) был сохранен, как только создан, а второй (важный) многократно изменялся. И нет, к сожалению, с ним больше ничего , кроме самого «толстого» vmdk. Надо вытащить оттуда файлы — времени много потратил. Дай совет, плиз, или я тупой?

  11. Евгений говорит:

    может можно родной дескриптор скопировать и подогнать?

  12. A.Vakhitov говорит:

    Если дескриптора нет, создаете дескриптор на любой диск схожего размера.
    После этого:
    — привязываете дескриптор на ваш flat-файл;
    — подключаете получившийся vmdk-диск к любой ВМ;
    — расширяете полученный диск на значение заведомо большее flat-файла (чтобы 100% попасть в количество головок, цилиндров, блоков)

  13. Пушкин говорит:

    А как «привязать» дескриптор на Flat файл?

    т.е. я скачиваю дескриптор, правлю CID and P.SID, сохраняю изменения и просто загрузить не получается, так как названия файлов одинаковые. В ДатасторБраузер .vmdk файлы называются name.vmdk без flat.

  14. Mister Nobody говорит:

    Для работы с файлами не достаточно использовать Datatore Browser — он отображает содержимое папок в упрощенном виде.
    Вариант первый — необходимо тащить всю папку себе на комп и локально смотреть содержимое.
    Вариант правильный — включить на хосте SSH, подключить с помощью WinSCP и им уже просматривать DataStore.

  15. Ihor говорит:

    Спасибо огромное!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *