Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

И снова траблешутинг VmWare.

На днях столкнулись с печальной картиной: в определенный момент наш виртуальный сервер Vcenter показал картинку, мол нужна консолидация дисков.

snap1

Вроде ничего страшного, нажал Snapshot-Consolidate

Все бы не плохо, если бы не вот такая ошибка:

snap2

И вот такая картина на в папке виртуальной машины на сторадже

snap3

Но это еще не все, сам виртуальный сервер начал тормозить так, будто это Pentium2 (это и логично, так как судя по всему, виртуаль стала использовать не основной vmdk, а снепшот, по факту это так и оказалось).

Начали копать «откуда ноги растут», оказалось, что Veeam в определенный момент  при сохранении бэкапа что-то пошло не так, и после этого случилась то, что случилось, при том в снепшотах отображалось два не удаленных снепшота Veeam (хотя, как видим на картинке на самом сторадже их значительно больше, да и сам сторадж при открытии этой папки стал дико тормозить, открывая папку примерно 10 минут).

Требовалось хирургическое вмешательство в процесс. А процесс оказался долгим и не простым…

Удаляем существующий диск vc-0000156.vmdk и подставляем vc.vmdk в настройках виртуальной машины, но машинка в этом случае не стартанет останавливаясь на 47% и показывая

Failed to lock the file

Cannot open the disk ‘/volume/…….

snap4

Здесь будут полезны вот такие рекомендации:

http://www.running-system.com/cannot-open-the-disk-reason-the-parent-virtual-disk-has-been-modified-since-the-child-was-created/

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026353

После чего виртуалка стартует, тормоза пропадают, но с консолидацией все же остаются проблемы.

«Пляски с бубном»  продолжились, не буду детально вдаваться, но в решении помогут следующие ссылки:

http://virtual-stones.stonemountains.nl/2013/07/virtual-machine-disk-consolidation-is.html

https://www.vnotions.com/2015/06/29/vmware-esxi-5-5-unable-to-consolidate-virtual-machine-disk-files/

https://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=10051

https://www.vmadmin.co.uk/resources/35-esxserver/411-disk-consolidation-needed-unable-to-access-file-since-it-is-locked

http://terenceluk.blogspot.ru/2014/12/extending-vmware-vms-vmdk-disk-with.html

«Три дня и три ночи скакал Иван Царевич- пока скакалку не отобрали.» В итоге консолидацию удалось выполнить (на выключенной виртуальной машине).

Виртуалка благополучно стартанула, при том стала работать как положено, достаточно быстро. Сам vCenter также благополучно стартанул, но тут всплыл новый «косяк»:

На самом Vcenter Server «отвалились» все локальные учетные записи, то есть при подключении, как через Web, так и клиентом Vmware под доменными учетками авторизация проходит, а под локальными нет (обычно бывает наоборот). Что привело к этому, пока не ясно? Если есть этому объяснения, прошу написать в комментарии?

По добавлению локальных прав будет полезна вот эти ссылки:

http://www.vkernel.ro/blog/add-users-in-vmware-vcenter

http://www.mustbegeek.com/change-root-password-of-esxi-server-using-vsphere-client/

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034608

P.S. 

Вчерашний день не закончился восстановлением vCenter… Точнее после его восстановления появились еще 2 проблемы: первая нода вылетела из HA, на второй оказался недоступен Vmotion

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2042654

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030264

пришлось снова достать бубен с полки (благодарю за содействие Романа и Данилу).

Почему перестал работать Vmotion было непонятно вовсе (виртуалки никак не хотели перемещаться для начала поиска проблемы на ноде). Проблема оказалась странной:

snap1

Выключаешь порт на Cisco (в нашем случае vmnic2) виртуалки начинают мигрировать, включаешь перестают, но пришли к пониманию этого момента не быстро (с таким вообще ранее не доводилось сталкиваться).

Далее руками удалось смигрировать машинки на соседний хост, текущий перевести в  Maintanance Mode, с помощью Update Manager накатили на ноду обновления и вернули в строй. После этого включили vmnic2 на Cisco и нода благополучно вернулась в строй. Попутно накатили обновления и на первую ноду, после чего ошибка с РФ тоже исчезла. Ближе к ночи кластер благополучно вернулся к своему обычному состоянию. Это неприменно радовало…

snap2

Всем хорошей работы!!!

Реклама

09.06.2016 Posted by | vmware & hyper-v Infrastructure | Комментарии к записи И снова траблешутинг VmWare. отключены