Yes it does.
KALAE1VMWin7 is the folder I have copied containing (as far as I know) the full virtual machine.
The files in the folder is:
c:ToolsVM-ware maskinerKALAE1VMWin7caches <DIR> 22-06-2019 23:46 —-
c:ToolsVM-ware maskinerKALAE1VMWin7vmware-2.log 514.285 22-06-2019 18:09 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7vmware-1.log 382.192 22-06-2019 21:15 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7vmware-0.log 375.880 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7vmware.log 67.103 26-06-2019 08:53 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s034.vmdk 524.288 22-06-2019 12:29 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s033.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s032.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s031.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s030.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s029.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s028.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s027.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s026.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s025.vmdk 589.824 09-06-2019 11:42 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s024.vmdk 327.680 22-06-2019 12:29 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s023.vmdk 524.288 05-06-2019 09:52 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s022.vmdk 524.288 05-06-2019 09:52 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s021.vmdk 524.288 05-06-2019 09:52 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s020.vmdk 524.288 05-06-2019 09:52 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s019.vmdk 524.288 05-06-2019 09:52 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s018.vmdk 1.140.523.008 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s017.vmdk 524.288 05-06-2019 09:52 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s016.vmdk 65.536 22-06-2019 12:29 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s015.vmdk 524.288 09-05-2019 13:04 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s014.vmdk 524.288 09-05-2019 13:04 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s013.vmdk 524.288 22-06-2019 12:29 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s012.vmdk 524.288 22-06-2019 12:29 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s011.vmdk 997.785.600 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s010.vmdk 2.089.484.288 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s009.vmdk 3.672.899.584 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s008.vmdk 2.895.380.480 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s007.vmdk 2.311.847.936 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s006.vmdk 3.922.853.888 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s005.vmdk 3.303.931.904 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s004.vmdk 1.655.701.504 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s003.vmdk 2.050.424.832 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s002.vmdk 4.227.399.680 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-s001.vmdk 4.180.475.904 22-06-2019 21:38 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-0-pt.vmdk 64.512 18-06-2019 13:13 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7-0.vmdk 1.011 22-06-2019 21:34 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7.vmxf 3.603 15-05-2019 10:54 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7.vmx 3.955 26-06-2019 08:53 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7.vmsd 0 09-05-2019 13:04 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7.vmdk 1.949 22-06-2019 21:34 -a—
c:ToolsVM-ware maskinerKALAE1VMWin7KALAE1VMWin7.nvram 8.684 22-06-2019 18:09 -a—
В работе имеется Blade-сервер Dell VRTX на лезвиях которых используется гипервизор VMware vSphere 6.5. Так как все лезвия используют одну дисковую корзину VRTX, то перемещениемиграция виртуальных машин осуществляется путем обычного разрегистрирования на одном лезвии и регистрация на другом.
Такой метод миграции VM соответственно требует обязательного выключения машины, в отличии от использования vCenter. Но vCenter дорогой и не каждая организация готова его себе позволить, как в моем случае.
В очередной раз понадобилось переместить 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
Если в выводе 00000000-00000000-0000-000000000000 , то это значит что файл никем не заблокирован
Методом просмотра по каждому хосту 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
Обращаю внимание что 572109 это LWID моего процесса, в команду kill поставляем свой LWID!
Теперь если снова проверим состояние блокировки файла 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.
ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА
Загрузка…
Hi Fellows,
I have installed VMware converter 5.0 on one of my physical web servers and converted the local machine to VMware workstation 8.0 and copied the vmdk and vmx files to the local datastore on the new server after this added the vmx file to the inventory.
now when I try to power on the machine I’m always getting the same error as follows.
Failed to start the virtual machine.
Module DevicePowerOn power on failed.
Unable to create virtual SCSI device for scsi0:0, ‘/vmfs/volumes/5243b855-254abfea-a0c8-40618694acd5/DCS/MYSRVR.vmdk’
Failed to open disk scsi0:0: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
please note that i have tried all methods described in this Opens a new window article but none of them worked for me.
Please advise,
Thank you all in advance,
check
Best Answer
In my limited experience with VMware Workstation, it seems that the VMDK format is not identical to that used in ESXi. So since you did your first VM Convert and selected to convert to VMware Workstation, the resulting VMDK and VMX files will work (and hence import) fine into Workstation, but do not work on an ESXi host without further manipulation.
I’ve only had to use Workstation as an intermediate form perhaps twice, and both times it was necessary to do a second conversion from Workstation to ESXi — the VMX and VMDKs did not work as-is on the ESXi host.
Was this post helpful?
thumb_up
thumb_down
View Best Answer in replies below
Read these next…
Laptop screen went black — can’t find the cause/ solution!
Hardware
Hi guys, I’m new here and really hope I can get some help :)I was using my laptop normally (Samsung np-sa31, Bremen — M motherboard), I turned it off, by pressing the power button and then closing the lid if I remember correctly since I was in a hurry…
O365 Emails Issue?
Cloud Computing & SaaS
Client in question has 18 O365 email users/mailboxes with MS Business Standard license.In the last 2 to 3 weeks a few users that are using certain business website where they login to these website are having issues creating new logins or resetting the pw…
Snap! — Brain Video, Mosquito-proof Cloth, Sound-Induced Torpor, Nugget Tetris
Spiceworks Originals
Your daily dose of tech news, in brief.
Welcome to the Snap!
Flashback: May 26, 1949: Howard Cunningham was born, the American programmer who developed the first wiki (Read more HERE.)
Bonus Flashback: May 26, 1969: Apollo 10 returns to e…
Bringing IT Infrastructure back in house
Best Practices & General IT
I started with a new company and they want to bring their IT Infrastructure back in house from the MSP they are using. What’s the best procedure to do this and what’s a good management platform to use to mange theses devices?
Finding remote IT work in Europe
IT & Tech Careers
I’m looking for advise for finding remote English speaking IT work in Europe.If you know of any job notice board that specialise in remote work what are they?And any other bits of advice.
I am trying to run Windows 10×64 on my VMware Workstation 16 Pro (16.1.1 build-17801498)
with «virtualize Intel VT-x/EPT» checked
(its needed for my assignment) but i keep getting the error :
«VMware Workstation does not support nested virtualization on this host. Module ‘HV’ power on failed. Failed to start the virtual machine.»
im doing this for school and am totally lost now.
i was previously using vmware 15.5.x.x with same issues.
so tried upgrading to VM 16 to no end.
pls help.
I have also enabled virtualization in the BIOS.
My host system :
OS Name: Microsoft Windows 10 Home
OS Version: 10.0.19042 N/A Build 19042
Version : 20H2
OS Manufacturer: Microsoft Corporation
System Type: x64-based PC
Processor(s): 1 Processor(s) Installed.
[01]: Intel64 Family 6 Model 158 Stepping 10 GenuineIntel ~2201 Mhz
BIOS Version: Razer 01.01, 31/8/2018
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz 2.20 GHz
Ram : 16GB
SSD : 256 GB
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
Problem:
We have a server in which some Virtual Machines (VM) are running on VMware Esxi 5.5. In these Virtual Machines, we have RHEL 5.8, RHEL 6.8, Windows Server 2003, and Windows Server 2008 R2. One day suddenly Windows Server 2008 R2 stopped working and we were not able to take the console or remote of that VM. When we have not found any solution then we have tried to reboot that VM but it not starting and was showing the error “Failed to start the virtual machine. Module DiskEarly power on failed. Cannot open the disk ‘/vmfs/volumes/52b66ab4-8c801b45-fd7a-a0d3c10119c0/BACKUPSERVER/BACKUPSERVER_8.vmdk’ or one of the snapshot disks it depends on.19 (No such device)“.
Reason:
A LUN from SAN was mapped with this VM through RAW Device Mapping for backup of some data. During some activity on SAN, we unmapped that LUN from VM because that was no more required. So VM was giving the disk error for this LUN while we were trying to start the VM.
Solution:
To remove the above error we need to remove the disk (which was mapped from the SAN) from the VM and after removing the disk VM will start successfully.