>[оверквотинг удален]
> [посикпано...]
>> Есть у кого положительный опыт или ставить систему заново и восстанавливать конфигурации?
> Видимо, нет решения. :(
> Ладно, следующий вопрос: переставил esxi на новый диск, подцепляю старый, чтобы перелить
> гостевые vm-ки, а команды mount нет. :( Пытался подцепить через add
> storage - мастер говорит, что диск пустой и жаждет отформатировать его
> заново. :( В гугле ответов тоже пока не нашлось, хотя я
> ещё в процессе... Линукс vmfs не понимает (пробовал грузиться в kali).
> :(
> Остаётся ещё вариант сливать гостевые системы по ssh, но хочется решения побыстрее... Вобщем, если кому-то придётся ещё ходить по этим граблям, мой вариант выхода из этого анального тупика (возможно, не самый лучший, эффективный, но... то, что обобщил из опыта народного в интернете):
Вариантов замены загрузочного диска VMWare ESXI нигде не предусмотрено. Предполагается, что серьёзная система будет устанавливаться на аппаратный raid-массив, и замена диска в массиве - это тривиальное решение на уровнет контроллера. Варианты скромно-бюджетных организаций или домашних тестовых лабораторий - это несерьёзно. Если дома "поиграться" - то игрушку можно же переустановить. Один из сертифицированных гуру VMWare даже задавал вопрос: "can you please explain the use case for cloning a VM host including VMs? I'm really curious... Thanks!"
1. Я слил содержимое /etc - там всего около 8 МБ. В идеале - слить куда-нибудь ещё файлы гостевых систем, но я был ограничен в свободном дисковом пространстве, о чём потом пожалел - несколько седых волос дальнейшее развитие событий мне добавило. :(
2. В итоге, после всех блуканий и тырканий, я переставил систему заново на другой диск на том же железе, перенёс лицензию (хранится в файле /etc/vmware/vmware.lic). Имена системы и прочее, по возможности я сохранил прежние при установке. Перенёс руками /etc/vmware/esx.conf - всё основное, касающееся системы и её внутренностей (внутренние свитчи, сети) восстановилось.
Оказалось, что одна из версий Акрониса, которыми я пытался пользоваться при переносе (8, 10, 11, 12), некорректно работает с GPT-разделами и выдала мне предупреждение, про некорректный формат таблицы разделов. Т.к. у меня и в мыслях не было вносить какие-то правки в старый винт до окончательного запуса системы на новом диске, я как-то не особо вчитался и согласился, тем более, что кроме кнопки "Ok", если правильно помню, ничего не предлагалось. Однако акронис ошибку исправил сам - починил MBR по своему усмотрению и затёр первую копию таблицы GPT. В итоге новая инкарнация VMWare никаких разделов не обнаружила, в том числе и хранилище гостевых систем.
Из приятных инструментов, перепробованных мною - testdisk (www.cgsecurity.org/wiki/TestDisk) легко нашёл разделы, нашёл виртуальные разделы гостевух и даже кое-что вытащил из файлов, но vmfs он не понимает. :( Так же отказался восстанавливать раздел vmfs, мотивируя тем, что "fs is corrupted" и максимум предлагал сделать образ (места куда у меня не было). Но среди гостевых систем у меня есть экспериментальная Netware - оттуда данные он тоже не вытащил. :(
Поигрался я с gpart-ом по инструкции http://bu7cher.blogspot.com/2010/10/gpt-gpart.html, но в последний момент очко сыграло и результат я на диск не записал.
Решилась проблема с помощью dmde (http://dmde.ru/) Программа платная, но её тестовых возможностей вполне достаточно, чтобы восстановить раздел целиком, не влезая в файловую систему (на что как раз ограничения в тестовой версии и распространяются).
3. В общем, после восстановления раздела с хранилищем гостевых систем VMWare увидела старое хранилище сразу, после чего средствами клиента гостевые системы были без проблем перенесены на новый диск. Внесение их в Inventory и настройка параметров запуска - уже банальность, все остальные настройки гостевых систем (к какому свитчу подключены и пр.) сохранились.
Вариант для распечатки
(??) on 10-Фев-17, 13:36 
