VMware #2 — Synchronization \ Migration

Продолжаем ходить по граблям съезда с облака. Есть 2 варианта перекачки машины из облака на свое железо (ну без всяких вариантов типа выгрузки в ova).

1. Останавливаем VM в облаке, жмем Migrate, ждем перекачки, включаем VM у себя. Долгий способ, долгий даунтайм. Проблемы с ним описаны в соседней статье, пока решения у вендора нет.
2. Проводим sync наживую, останавливаем VM в облаке, жмем Migrate, ждем минут 10, убеждаемся что все стало зеленым, VM запускаем у себя.

НО, ЕСТЬ НЮАНС!

2 пункт был бы отличным, если бы не одно но.

Во время включения VM зависает на 66% или 71% взависимости от того, есть ли HA в кластере. Зависает наглухо. Окей, что же в логах?

[root@esxi:~] vim-cmd vmsvc/getallvms
176 APP15 [LUN1] _H4-ca63ff02-768c-431a-967c-decb5f592b75/TMP-APP-15-zPCe.vmx windows9Server64Guest vmx-11
[root@esxi-:~] vim-cmd vmsvc/power.on 176

Powering on VM:
Power on failed

[root@esxi-:~] vim-cmd vmsvc/get.tasklist 176
(ManagedObjectReference) [‘vim.Task:haTask-176-vim.VirtualMachine.powerOn-1013408858’,

[root@esxi-:~] vim-cmd vimsvc/task_cancel vim.Task:haTask-176-vim.VirtualMachine.powerOn-1013408858 (vmodl.fault.ManagedObjectNotFound) {faultCause = (vmodl.MethodFault) null, faultMessage = ,obj = ‘vim.Task:vim.Task:haTask-176-vim.VirtualMachine.powerOn-1013408858’
msg = «Received SOAP response fault from []: cancel
The object ‘vim.Task:vim.Task:haTask-176-vim.VirtualMachine.powerOn-1013408858’ has already been deleted or has not been completely created»

Отлично, VM в статусе запуска, принудительно запустить нельзя, отменить task нельзя. Пока оно в раскоряченном состоянии его нельзя и дернуть из inventory… ОКЕЙ!
Отменить нельзя задачи, потому что они висят в очереди списка task, т.е. пока не включится, отменить нельзя. И таймута в 30 минут нет.

Погнали, ребутаем службу

[root@esxi-:~] /etc/init.d/hostd restart
watchdog-hostd: Terminating watchdog process with PID 2988354
hostd stopped.
hostd started.

[root@esxi-:~] vim-cmd vmsvc/getallvms
Skipping invalid VM ‘176’

Уууубираем из инвентори…

Тадааам, у вас осталась запущенная VM в ээээ в нигде! Естественно, еще и залоченная.

Проверяем, что же лочит:

[root@esxi-:~] vmfsfilelockinfo -p /vmfs/volumes/LUN1/_H4-ca63ff02-768c-431a-967c-decb5f592b75/TMP-APP15-zPCe.vmx.lck

vmfsfilelockinfo Version 2.0
Looking for lock owners on «TMP-APP15-zPCe.vmx.lck»
«TMP-APP15-zPCe.vmx.lck» is locked in Exclusive mode by host having mac address [‘bc:97:e1:ab:d2:04’]
Trying to use information from VMFS Heartbeat
Host owning the lock on file is 128.0.0.2, lockMode : Exclusive
Total time taken : 7.0388294938020408 seconds.

Дальше расправляемся с этим, опять кладем hostd, потом меняем имя у лок файла:

[root@esxi-:/vmfs/volumes/6036393f-590ca4a6-4fc4-bc97e1abb812/_H4-ca63ff02-768c-431a-967c-decb5f592b75] mv TMP-APP15-zPCe.vmx.lck TMP_DEL

Ребутаем хост, дальше удаляем все что пошло не так… И пишем тикет в суппорт, посмотрим, что предложат в виде решения.

И еще прикол. При 2 варианте миграции (наживую) имя машинам выдается с припиской TMP-. Когда в нормальной миграции такого нет.