Компания VMware вместе с vSphere / ESX 4 выпустила продукт VMware Data Recovery 1.0 для резервного копирования виртуальных машин. Как оказалось, в Data Recovery первой версии оказался один очень серьезный баг: снапшоты, сделанные механизмом VMware Dtata Recovery, не удалялись после снятия резервной копии.
Суть бага проста - в файл-дескриптор снапшота (vm_name-000001.vmdk) виртуальной машины добавлялась и не удалялась строчка ddb.deletable = "false", которая не позволяла после отработки механизма VMware Data Recovery удалить снапшот. В результате для виртуальных машин снапшоты множились и росли, очень сильно изменяя инфраструктуру в очень плохую сторону, тем более, что утилиты типа RVTools не могли их обнаружить.
Для решения проблемы предлагается использовать скрипт из KB 1012383, при запуске которого злополучная строчка удаляется из файла vm_name-000001.vmdk.
[root@server]# python fixdeletable.py
Checking disk ./win2k3-thick/win2k3-thick.vmdk: NOT AFFECTED
Checking disk ./8gbDC/8gbDC.vmdk: NOT AFFECTED
Checking disk ./win2k3-thin/win2k3-thin.vmdk: NOT AFFECTED
Checking disk ./xpsp2-temp/xpsp2-temp.vmdk: NOT AFFECTED
Checking disk ./2k3_test/2k3_test.vmdk: NOT AFFECTED
Checking disk ./folder/win2k3-template8gb/win2k3-template8gb.vmdk: NOT AFFECTED
Checking disk ./milkyFT/milkyFT.vmdk: NOT AFFECTED
Checking disk ./test_2k3/test_2k3.vmdk: FIXED
Checking disk ./Win2k8/Win2k8.vmdk: NOT AFFECTED
Далее нужно создать снапшот для каждой их виртуальных машин, которые "Affected" и смержить его (удалить) с помощью операции Delete All. То есть операция очень геморройная.
Но главное, что "The problem is only noticed on ESX hosts upgraded from ESX 3.5 to vSphere installs". Мораль такова: не обновляйте мажорные версии ПО, а устанавливайте их заново. Если есть возможность, конечно же.
RSS
