Hi,
As you're referring to two links in which I participate as help (I wrote the article at the vimalin site and I am /u/dfguidance at reddit), a few notes.
The data on the disk isn't encrypted so -at least in theory- you should be to get the VM(s?) back to work. The descriptor files describing those virtual disks however are.
How did you configure the virtual disk on the VM you need back?
Note that my article points to a few threads that describe how users recovered their VM. Not destructive, unless you mean it will drop the vTPM itself (yes it will, no way around that AFAIK).
PS: I don't know where the password was saved in the experimental vTPM feature. But even if it was in the keychain then I think it would still be inaccessible and you are still at the same stage unless you saved the keychain in iCloud.
--
Wil
Hi,
With the experimental vTPM feature there's not just .vmx lines that need to be removed.
There are other parts that also have been encrypted, like the vmdk descriptor file. The descriptor file is the vmdk file without the -s00nn.vmdk suffix.
If you don't have a backup copy of that one, then you'll have to recreate the descriptor file yourself by creating a dummy virtual disk of exactly the same size.
Then checking the contents of the descriptor file and drawing up one that matches your disk slice names. It should have the exact same amount of slices.
If you ever have resized your virtual disk, then you have to do that also for the dummy disk.
--
Wil
Hi,
The last time I played with this was probably a year ago, so somehow I don't have exact steps.
In order to be able to help we need more details.
1. a full file list of your VM. (eg. ls -al /foldername/of/vm > ~/Desktop/vm-filelist.txt )
2. a copy of the following files: the .vmx, vmsd, all vmdk files smaller than 4kB
3. all vmware.log files
In order to be able to attach those files to a reply down here, you need to zip/compress them.
An answer to the following questions:
Do you remember when you created this VM? Was this before VMware Fusion 7 or after?
Did you ever increase the size of the virtual disk?
I might have more questions after that.
--
Wil
That file list has no details on size & date.. as such that's not the output of "ls -al"
There are no details about the vTPM password in the log AFAIK, if it would be there than that would be a massive goof up.
I'm asking for those files to get an idea about the correct size of your disk.. nothing more.
--
Wil
FWIW.. you can try the following for creating the virtual disk.vmdk descriptor file as I will be off to bed.
Step 1) Make a backup of the folder of the VM as you're experimenting and you don't want to loose more.
After that (and only after you have that backup) try the following experiment.
Create a new dummy VM with a disk of 68GB, also with a split disk scheme of course. So the file list of that new VM will look similar as what you have here.
Then replace the file "virtual Disk.vmdk" from your copy with the copy of the new dummy VM.
Also remove the lines from the vmx we talked about earlier.
Throw away (or if you want -rename) the .nvram and .vmxf files.
Boot the vm and see if it complains.
If that doesn't work.. then tell us the errors and attach the files I asked for.. get them from the backup please, not the experiment.
--
Wil
Without more details I'll stick to my guess of a 68GB sized virtual disk.
edit:
Let me explain the reasoning. There's 17 disk slices and you're using a VMware Fusion later than Fusion 7.
Because of that I already know the disk is under 128GB. As the disk is under 128GB each slice can only take up 4GB. The rules change once a disk is over 128GB, in that case a disk slice might be bigger, but that is not the case here.
17*4=68. So that is the absolute maximum size your virtual disk could be.
Now that last slice might be less than 4GB in size.
So your disk will be between 64GB and 68GB. Normally you'd type in a round number when creating a virtual disk (that's not a must)
A hint for the real size might be in one of the logs, but as I don't have the logs.. your guess will be as good as mine.
Good luck!
--
Wil
Hi,
I just played a bit with a few dummy VMs.
If you keep the default of 60GB then it creates 16 disk slices.
if you use the 60 GB as default and then resize the disk to 64GB before booting, you already get 18 disk slices.
However if you delete the 60GB disk.. then add back a new disk at 64GB.. it is indeed 17 disk slices.
The log file is useful as it has this line:
2022-06-07T19:11:10.310Z In(05) vmx DISK: OPEN '/Users/alex/Virtual Machines.localized/Win11.vmwarevm/Virtual Disk.vmdk' Geo (8354/255/63) BIOS Geo (0/0/0)
The geometrics there tell me the size of the disk.
When looking at the 64GB disk I just created, then it has the following lines in the descriptor file:
ddb.geometry.cylinders = "8354"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
Looks like that matched!
I'll attach the descriptor file for you so you can use that.
With a tiny bit of luck it is what was needed.
Then you'll only have to take care of the .vmx (& remove the other files I mentioned)
--
Wil