Hello,
I have not found an information related to this "bug", but though it might help someone else saving some time. If you have further information, please feel free to link or add as a reply. If this is an unknown phenomenon, VMware should have a look at it.
What I did
I was migrating my ESXi 6.0 host to a new hardware. By "migrating" I mean setting up an entirely new host (ESXi 6.5) and copying (rsync) all VMs to the new host, updating the paths within the vmx file, registering them there and starting them on the new host. This worked for a few, but not for the major part of the VMs.
The Error
When trying to start the VM (using Web Client, pSphere client, or vim-cmd vmsvc/power.on) the connection of the client was immediately lost, as if the Management Service would restart. The VM did not start, there was no vmware.log and I also was not able to find any information in any of the other log files.
ESXi versions
Originally, the source host was a ESXi-6.0.0-20150902001-standard and the destination host was ESXi-6.5.0-4564106-standard, but later I have updated both to ESXi-6.5.0-20170404001-standard (Build 5310538) and re-transferred the VMs. As such, the source datastore was on VMFS-5.60 (Raw Major Version: 14), while the destination datastore was VMFS-6.81 (Raw Major Version: 24). But I believe this has nothing to do with the error.
Solution
Eventually I could make the VMs start by removing the following properties from the vmx file. However, I have not identified which exact property or combination thereof made the difference. However I have always managed to start the VM after removing them:
- migrate.hostLog
(both file and entry will be re-created after starting up) - monitor.phys_bits_used
(was "42" after starting up) - replay.*
- sched.swap.derivedName
(both file and entry will be re-created after starting up) - uuid.location
(is probably irrelevant, but helped not asking if I copied or moved the VM) - vc.uuid
(is probably irrelevant, but helped not asking if I copied or moved the VM) - vm.genid
(is probably irrelevant, but helped not asking if I copied or moved the VM) - vm.genidX
(is probably irrelevant, but helped not asking if I copied or moved the VM) - vmci.filter.enable
- vmci0.id
(entry will be re-created after starting up) - vmotion.checkpointFBSize
(is probably irrelevant) - vmotion.checkpointSVGASize
(is probably irrelevant)
Error when starting disks
Also I have noticed, that I had difficulties with some disk descriptor files (vmdk) when
- the version was set to 3, instead of 1,
- the ddb.virtualHWVersion was not matching the virtualHW.version in the vmx file,
- ddb.toolsInstallType was present,
- ddb.toolsVersion was present,
- ddb.thinProvisioned = "1" was present, although the disk was actually thick.
Again, I have not completely gone to the root of the cause. Specially the ddb.tools* entries might have nothing to do with it and can be left as they are.
Not related to ...
- Update ESXi 6.5.0a | 02 FEB 2017 | ISO Build 4887370
See Attempts to perform vMotion of VMs from earlier releases of ESXi to ESXi 6.5 might fail with an error in the VMware ESXi 6.5.0a Release Notes, as there was no purple screen. The host did not crash and the client could reconnect again nearly instantly. - ESXi 6.5 host fails with PSOD: GP Exception 13 in multiple VMM world at VmAnon_AllocVmmPages,
as none of the properties mentioned there, made any difference.
Warning
Please be careful when adapting any of these practice and only do it when you know what you're doing. And always have a backup copy of any file you edit!
again