У меня есть несколько виртуальных машин ESXi (4.1), которые изначально были созданы с использованием дисков с тонким предоставлением, но затем были физически перемещены в другие хранилища данных (все они iSCSI); поскольку это автономные хосты, vCenter Server для управления ими недоступен, поэтому операция была выполнена из командной строки ESXi с использованием mv
команда.
Теперь ВМ демонстрируют довольно интересное поведение: формат диска в настройках ВМ отображается как «толстый», файлы VMDK не иметь ddb.thinProvisioned = "1"
строка, но фактический размер файла намного меньше, чем размер виртуального диска. При просмотре через браузер хранилища данных он показывает два разных столбца для «Размер» и «Предоставленный размер», как и в случае с диском с тонким предоставлением.
Тем не менее, это не кажется проблемой, поскольку машины работают нормально.
Затем была сделана еще одна их копия для резервного копирования; эта копия также была сделана из командной строки с использованием cp
между двумя хранилищами данных на одном хосте (опять же, оба они iSCSI).
Затем мы потеряли оригинальные виртуальные машины, и нам потребовались резервные копии.
И они больше не работают, жалуются на повреждение файлов VMDK.
Итак, резюмируем:
Я попытался вручную отредактировать файл VMDK, чтобы добавить ddb.thinProvisioned = "1"
line, но это не устранило проблему. Я пробовал надуть виртуальный диск, клонировать и преобразовать: ничего не работает, каждая команда жалуется на то, что диск поврежден.
Мне очень трудно снова запустить эти виртуальные машины; может кто-нибудь помочь?
Похоже, физическое копирование дисков с тонким предоставлением плохая идея. VMFS делает странные вещи с дисками с тонким выделением ресурсов, которые cp
или mv
не могу справиться. Возникает коррупция.
Не делай этого. vmkfstools
справляется с ними намного лучше (и безопаснее).
Я подозреваю, что ваше хранилище - это хранилище данных VMFS, а не NFS?
Вы можете попробовать загрузить / скопировать рассматриваемый vmdk в безопасное место, где затем вы можете начать работать с ним, используя vmware-vdiskmanager или vmware-mount - как часть сервера / рабочей станции VMWare, так и доступную как отдельную загрузку IIRC.
Если все это не удается, попробуйте использовать сторонние инструменты - такие инструменты, как qemu-img
из пакета QEMU или VBoxManage clonehd
из VirtualBox могут конвертировать vmdks в необработанные файлы который вы затем можете просто вернуться к гостю ESX.
Также есть альтернативный драйвер диска под названием "vdk" для Windows (исходная страница автора кажется недоступной, но есть загрузки старых сборок и 64-битная сборка around), который, по слухам, может довольно хорошо читать частично поврежденные файлы vmdk - хотя мне еще предстоит это попробовать.
Что касается возможной причины повреждения, я бы предположил, что виновата не команда «cp». Существует множество способов повредить данные - с помощью целей iSCSI, которые не поддерживают / не реализуют Резервирование SCSI один из них. В любом случае, я думаю, что лучше всего задокументированный способ копирования - это использовать vmkfstools - вы должны придерживаться этого.