Hi all,
This was my first ESXI 7.0.1 U1 HPE image Gen10+ homelab
Long story short there was an issue with the old RAID drivers and I lost the instance. From looking around online I managed to get the vmx and vmdk files etc via sshing into the old host and using scp to copy the files out before I formatted and zeroed the ssds before re-installation.
I have a new one build but neither of the Windows server 19 VMs will boot properly. One will not even start and get stuck at the blue boot screen, as in select source to boot from.
The other will attempt a Windows repair and always fails, even booting the source media and selecting 'repair this computer' just results in it going back to the start, therefore in a loop. The new ESXI host gives no errors on the vmx file when trying to register and I select 'I moved it' so as to keep the same UUID and MAC.
I understand that I should have maybe detached the VM / HD before, but I did not. Any idea on why these will not boot? I get no reported issue when trying to register the 2 VMs back in.
Interestingly, If I select 'Install', instead of the repair attempted earlier - then it sees the partitions but states that they are all 'Offline'
Any ideas on getting these back online or are they just knackered !?
Why dont you read the vmdks with
- another helper VM
- thirdparty vmdk-reading tools
- convert them to another format
> One will not even start and get stuck at the blue boot screen, as in select source to boot from.
Check wether you have set the correct boot-order in BIOS
> The other will attempt a Windows repair and always fails,
Sounds like you assigned the basedisk and ignored one or more snapshots.
Ulli
Hi,
Yes, it does not matter which option I choose in the boot manager, it does not recognise the vdisk.
Any ideas on what could be wrong? Any tools I could use to check the vmx vmdk for any boot issues ?
The 2nd image, I am not experienced enough to know about the snapshots, I do not recall ever taking one however I know there are quite a few different files, they appear greyed out in the datastore browser. I only right clicked on the vmx file to register it.
> Any ideas on what could be wrong?
All the information I have at the moment says: something is kaputt ...
In other words - send a filelist and latest 3 vmware.logs
Ulli
Hey, thanks for taking a look.
Here are the files for each VM minus the large flat_vmdks
You try to run VMs with ESXi-style VMFS-vmdks on Workstation.
That used to work in the past but this is WS 16.2.3 !
I would suggest to modify the vmdk-descriptor files and change:
createType="vmfs"
# Extent description
RW 268435456 VMFS "2019Srv-flat.vmdk"
to
createType="monolithicFlat"
# Extent description
RW 268435456 FLAT "2019Srv-flat.vmdk" 0
Do this for both vmdks.
I forgot to mention that after the esxi move, I tried Workstation Pro with the same files, exact same responses I was getting in ESXi.
I guess it had edited the files slightly.
Editing back as you say and re-registering results in the same for each VM ..
1st still says Windows boot manager - no media
EFI VDisk 0.0 no media
2nd VM still attempting repair and going nowhere.
Beginning to wonder if the previous RAID issues had damaged the datastore also, as they were on the same array back then.
It would really help to know wether you try to launch the VMs in Wrkstation or In ESXi.
The log files you attached last time were created on Workstation.
Ulli
Hi,
Originally they are from ESXI but after having the issues, I thought I try loading them into VMWare Workstation to see if that could load them. It has obviously altered the config files, I did not know that.
In trying to re-register them again (from the same backup external HD) on ESXI it had loaded the modded files.
But they were not loading originally in esxi and produced exactly the same errors in Workstation
In the vmware.log it looks like the disks just time out or are so slow that nothing happens.
Other than that the logs appear to be ok
Thanks for taking a look.
I think i'll have to give up on these 2 VMs!
Why dont you read the vmdks with
- another helper VM
- thirdparty vmdk-reading tools
- convert them to another format
I have already rebuilt them but good points, appreciate that
Many thanks
