RecoverPoint для віртуальних машин: Copy VM не завантажується під час доступу до образу через невідповідність у дескрипторі диска

Під час доступу до образів віртуальна машина Copy може не завантажуватися належним чином, і може спостерігатися така помилка:

При перевірці файлів Production VMDK і Copy VMDK спостерігається невідповідність. Наприклад:
Виробнича віртуальна машина:

ddb.adapterType = "buslogic"
ddb.deletable = "true"
ddb.geometry.biosCylinders = "0"
ddb.geometry.biosHeads = "0"
ddb.geometry.biosSectors = "0"
ddb.geometry.cylinders = "13054"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.iofilters = "spif:vmwarelwd"
ddb.longContentID = "17189fda646b30fa8e07a2e11be39f0e"
ddb.sidecars = "vmwarelwd_1,<VM NAME>.vmfd"
ddb.thinProvisioned = "1"
ddb.toolsInstallType = "1"
ddb.toolsVersion = "12389"
ddb.uuid = "60 00 C2 9b 41 72 92 4a-01 1b 5c a1 cb 73 7d ff"
ddb.virtualHWVersion = "4"

Копіювати ВМ:

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "13054"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "7632d38b5d143766f99a7787ce2dec62"
ddb.thinProvisioned = "1"
ddb.toolsInstallType = "1"
ddb.toolsVersion = "12389"
ddb.uuid = "60 00 C2 98 06 fb 7b 22-6a 46 d0 9c c4 8a 89 27"
ddb.virtualHWVersion = "14"

Файли дескрипторів диска здебільшого невидимі для RecoverPoint для віртуальних машин і не впливають на те, як такий файл створюється в цільовій віртуальній машині.
Зазвичай віртуальна машина Copy приймає значення за замовчуванням VMware на основі налаштувань віртуальної машини.

Якщо віртуальна машина створюється в старішій версії vCenter (навіть якщо зазначений vCenter з тих пір був оновлений), а потім віртуальна машина дублюється з тими ж налаштуваннями в новішій версії. Віртуальні машини мають дещо інші файли дескрипторів. Отже, ця проблема частіше зустрічається з віртуальними машинами, які створюються в старих версіях vCenter.

Зазвичай ці відмінності не мають значення, але іноді спосіб, яким дескриптор диска представляє блоки та інформацію до ОС віртуальної машини, може змусити віртуальну машину прочитати інформацію неправильно або вважати, що диск пошкоджений. Згідно з RecoverPoint Engineering, налаштуванням, яке може спричинити значний вплив, є версія апаратного забезпечення. Зміна цієї версії обладнання схожа на фізичне вилучення диска з комп'ютера та розміщення його в новому. Така дія може дозволити віртуальній машині завантажитися, але вона, швидше за все, спричинить проблеми, якщо вони несумісні.

Спосіб вирішення:

Щоб змінити файл дескриптора диска в копіюванні віртуальної машини так, щоб він відповідав робочій віртуальній машині, виконайте такі дії:

1. Запишіть сховище даних, у якому знаходиться віртуальна машина Copy
2. Зніміть захист із відповідних віртуальних машин
3. Вимкнення живлення Копіювання віртуальної машини
4. Видаліть копію віртуальної машини з інвентарю, натиснувши правою кнопкою миші >«Видалити з інвентарю»
5. Визначте відмінності між файлами VMDK за допомогою журналів або використовуючи сеанс SSH як root для відповідних хостів ESX
6. Змініть файл VMDK віртуальної машини Copy , щоб він відповідав робочій віртуальній машині

   Наприклад, у файлах дескрипторів диска, наданих раніше у статті, до Copy VM необхідно додати такі поля:

   • ddb.deletable = "true"
   • ddb.geometry.biosCylinders = "0"
   • ddb.geometry.biosHeads = "0"
   • ddb.geometry.biosSectors = "0"

   І існуючі поля повинні бути змінені, щоб вони відповідали Production VM:

   • ddb.adapterType = "lsilogic" to ddb.aapterType = "buslogic"
   • ddb.virtualHWVersion = "14" to ddb.virtualHWVersion = "4"
7. Після внесення відповідних змін повторно додайте віртуальну машину до інвентарю, перейшовши до сховища даних, зазначеного на кроці 1>Знайдіть правильний каталог для віртуальної машини та натисніть папку > Знайдіть файл імені> віртуальної машини.vmx<, натисніть кнопку «Зареєструвати віртуальну машину»>
8. Увімкніть Copy VM, щоб переконатися, що він завантажується належним чином
9. Повторний захист віртуальної машини та перевірка доступу до образів після ініціалізації