В работе имеется Blade-сервер Dell VRTX на лезвиях которых используется гипервизор VMware vSphere 6.5. Так как все лезвия используют одну дисковую корзину VRTX, то перемещение\миграция виртуальных машин осуществляется путем обычного разрегистрирования на одном лезвии и регистрация на другом.

[stextbox id=’info’]Такой метод миграции VM соответственно требует обязательного выключения машины, в отличии от использования vCenter. Но vCenter дорогой и не каждая организация готова его себе позволить, как в моем случае.[/stextbox]

В очередной раз понадобилось переместить VM (webserver_1) с одного лезвия на другой и в процессе этого столкнулся с трудностями запуска VM на целевом лезвии. В качестве памятки себе опишу свою проблему и ее решение.

На исходном лезвии выполнил завершение работы на виртуальной машине, но она не выключилась. Решил принудительно завершить ее работу через консоль, но в активных процессах виртуальную машину (webserver_1) не обнаружил, а вместо нее висела виртуальная машина с названием vm.572109.

Принудительно завершил процесс vm.572109 и разрегистрировал ее из текущего лезвия. На другом лезвии зарегестрировал ее и попытался запустить, но она не запустилась.

Долго висел статус «Running…»

После некоторого времени система выдала ошибки неудачного запуска VM:

• Failed — An error occurred while creating temporary file for /vmfs/volumes/52d528e0-0d3b4675-5b88-18a99bdc13c1/webserver_1/webserver_1.vmx: The file already exists
• Failed to start the virtual machine (error -18)

Эти ошибки означают что виртуальная машина, а точнее ее *.vmx файл (конфигурационный файл VM) заблокирован другим хостом и поэтому доступа к нему нет.

Через консоль видно что в каталоге VM присутствует файл блокировки *.vmx~

ls -l

total 37925912
-rw-------    1 root     root       2344806 Nov 23 10:08 vmware-1.log
-rw-------    1 root     root        210642 Nov 23 10:51 vmware-2.log
-rw-------    1 root     root        183345 Nov 23 10:58 vmware-3.log
-rw-------    1 root     root        362461 Nov 27 04:54 vmware.log
-rw-------    1 root     root       1311232 Nov 27 04:53 webserver_1-ctk.vmdk
-rw-------    1 root     root     21474836480 Nov 27 04:53 webserver_1-flat.vmdk
-rw-------    1 root     root          8684 Nov 27 04:53 webserver_1.nvram
-rw-------    1 root     root           612 Nov 26 21:20 webserver_1.vmdk
-rw-------    1 root     root            44 Nov 26 21:20 webserver_1.vmsd
-rwx------    1 root     root          3867 Nov 27 04:53 webserver_1.vmx
-rw-------    1 root     root          3445 Oct  9 05:07 webserver_1.vmxf
-rwx------    1 root     root          3868 Nov 27 04:53 webserver_1.vmx~
-rw-------    1 root     root       6554112 Nov 27 04:53 webserver_2-ctk.vmdk
-rw-------    1 root     root     107374182400 Nov 27 04:53 webserver_2-flat.vmdk
-rw-------    1 root     root           618 Nov 26 21:20 webserver_2.vmdk

Смотрим какой хост держит блокировку файла. Выполняем команду:

vmkfstools -D webserver_1.vmx

В выводе видим владельца блокировки файла:

• 5d988d2f-2f22bc92-f10e-18a99bdc13db — где 18a99bdc13db mac-адрес (18:a9:9b:dc:13:db) хоста.

Lock [type 10c00001 offset 246724608 v 67168, hb offset 4161536
gen 203, mode 0, owner 5d988d2f-2f22bc92-f10e-18a99bdc13db mtime 10479
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 529, 15>, gen 66976, links 1, type reg, flags 0, uid 0, gid 0, mode 100700
len 3867, nb 1 tbz 0, cow 0, newSinceEpoch 1, zla 2, bs 8192

[stextbox id=’warning’]Если в выводе 00000000-00000000-0000-000000000000 , то это значит что файл никем не заблокирован[/stextbox]

Методом просмотра по каждому хосту ESXi вкладки Physical NICs находим нужный хост который держит блокировку файла.

Либо через консоль можно вывести параметры сетевых адаптеров:

esxcfg-nics -l

Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 0000:01:00.0 bnx2x Up 1000Mbps Full 18:a9:9b:dc:13:db 1500 QLogic Corporation NetXtreme II BCM57810 10 Gigabit Ethernet
vmnic1 0000:01:00.1 bnx2x Up 1000Mbps Full 18:a9:9b:dc:13:de 1500 QLogic Corporation NetXtreme II BCM57810 10 Gigabit Ethernet

На искомом хосте необходимо завершить процесс который держит блокировку. Находим LWID процесса по имени файла блокировки (webserver_1.vmx~) командой:

vmkvsitools lsof | grep webserver_1.vmx~

Процесс найден:

572109 vmx FILE 46 /vmfs/volumes/52d528e0-0d3b4675-5b88-18a99bdc13c1/webserver_1/webserver_1.vmx~

Завершаем принудительно процесс командой:

kill -9 572109

[stextbox id=’warning’]Обращаю внимание что 572109 это LWID моего процесса, в команду kill поставляем свой LWID![/stextbox]

Теперь если снова проверим состояние блокировки файла webserver_1.vmx, то видим что более он никем не заблокирован:

vmkfstools -D webserver_1.vmx

Lock [type 10c00001 offset 246724608 v 67168, hb offset 4161536
gen 203, mode 0, owner 00000000-00000000-0000-000000000000 mtime 10479
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 529, 15>, gen 66976, links 1, type reg, flags 0, uid 0, gid 0, mode 100700
len 3867, nb 1 tbz 0, cow 0, newSinceEpoch 1, zla 2, bs 8192

После всех этих манипуляй у меня успешно запустилась VM на целевом лезвии. Вот такие случаются ньюансы при подобном методе переноса VM между лезвиями Dell VRTX.