Skip to content

vGolovatyuk — О Виртуализации, СХД и Бекапах

  • Главная
  • Тестирование СХД
  • Всякое
  • CommVault
  • VMware
  • Обо мне

VMware #2 — Synchronization \ Migration

31.03.2021 by admin

Продолжаем ходить по граблям съезда с облака. Есть 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»

Facepalm | Know Your Meme

Отлично, 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-. Когда в нормальной миграции такого нет.

Post navigation

Previous Post:

VMware #1 — DRaaS медленная миграция

Next Post:

VMware + Synology + iSCSI + MPIO = One Love

Добавить комментарий Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Login Menu

  • Log in
  • Register

Рубрики

  • CommVault
  • NetApp
  • Pfsense
  • SNR
  • Synology
  • Unraid
  • VMware
  • vSAN
  • Исправляем
  • Сеть
  • Тестирование СХД
© 2023 vGolovatyuk — О Виртуализации, СХД и Бекапах | WordPress Theme by Superbthemes