Good morning,
I find it truly incredible that I'm still at the same point.
It's been 4 months since I reported the problem which started after I successfully updated VMware Fusion to version 13.5.0 on macOS Sonoma 14.0.
Now, after successfully updating VMware Fusion to version 13.5.1, I still find that when I open my W11 pro ARM virtual machine, VMware tells me it is encrypted with the previous encryption scheme.
I then select the Refresh button, but the error appears: "the virtual machine could not be re-encrypted: disk problem"
What should I do to fix it?
Thank you!
I'll tag @Technogeezer as he's a Fusion guru. I'm aware of other chronic problems with Fusion on Mac, but he will likely have much better insight.
@webears could you post the following:
@Technogeezer, first of all thank you
I'll try to give you the answers to your questions.
Virtual Disk:
- maximum size: 250GB
- fully allocated? Yes
- divided into parts? Yes
I attach the vmware-vmfusion*.log files found in ~/Library/Logs/VMware
I attach the vmware*.log files present in the VM bundle folder
I attach list.rft file with the list of what is present in the VM bundle folder
Please tell me if I did something wrong or if you need anything else.
Thanks again
bears
You provided the wrong files. You posted files from the system-wide /Library folder, not your user's Library folder - that's what ~/Library means.
Go to the Finder, click on Go > Go to folder... in the menu bar and then type in ~/Library
Your Library folder will then open. Expand the Logs folder, then the VMware Fusion folder. The vmware-vmfusion*.log files can be found there.
Forgive me @Technogeezer, you're right.
I attach the correct logs here (... I hope!... 😳)
Sorry again for the time I wasted on you.
bears
HI @scott28tt,
You're right, I didn't report it to anyone in Support.
I tried but I couldn't.
Probably because I didn't buy a technical package that includes the possibility of communicating with support.
I am a normal user, not a technician, who purchases VMware software for personal use, for its basic functionality and not for developments, system activities, etc.
So I just posted here in the VMTN Communities and found that I'm not the only one having this problem.
I was surprised that a fairly widespread problem hadn't received a fix with the new release.
Then, don't hurt anyone's feelings or make anyone work unnecessarily.
I am a customer, even quite ignorant, I encountered a problem, I verified that I was not the only one with it and, wrongly, I thought that it was of interest to those who developed and marketed the software to look into it...
bears
@webears No need to apologize - you are not wasting my time. Just want to see if I can see if I can help. I’ll take a look and see what I can find out.
Have you been running this VM with automatic snapshots (AutoProtect) enabled? It appears from the logs that's the case.
If so, disable it. While the feature at first appears to be useful, it is more trouble than it's worth. Many times people using this feature either find they're running out of disk space because of the snapshots, or they find they have a system problem and find the snapshots are corrupted. And of course, snapshots do not protect you against the loss of the disk the virtual machine resides on.
There are some complaints in the logs about a missing key. I'm wondering if that's due to trying to convert the encryption of the virtual machine while autoprotect snapshots are enabled. If this has been happening since Fusion 13.5, then the evidence of what happened is probably long gone.
I think I might be able to help you get around this, though. Hold on while I dig up some instructions I gave other folks on something similar.
While you're waiting, shut down Fusion and make a complete copy of this VM to another disk using the Finder. That's going to be necessary before we proceed further.
Hold on for a while more. I'm running into something quite unexpected with Fusion that I have to track down.
Ok. I think I can proceed here... I was trying to prototype this on a VM that I'd converted from an Insider Preview VHDX file and something is wonky with that. The steps below work with my main Windows 11 VM...
Here's something to try.
First make sure you have the virtual machine copied via the Finder to some other disk.
Then:
You can double check that you chose the virtual disk. Then click "Continue"
Once you get the new VM up and running, you can delete the old one. Note that you may need to reset your PIN when you powered up your VM if you used Windows Hello and a Microsoft account to avoid typing in your password at login.
@Technogeezer WOW!
I hope to be able to try to do what you wrote today
I'll update you as soon as it's done
Thank you!!!!!!
bears
Here I am
I think I did something wrong, but I don't know what having followed what you told me step by step...
I attach the last three screenshots of the steps I did:
I don't understand why the result is the error "Unable to decrypt the disk because the key or password is invalid"...
The only doubt I have concerns the selection of the .vmdk file.
She advised me to choose the file "Virtual Disk-000005.vmdk".
However, looking in the settings of my current VM I find what is shown in the screen I attach below.
Maybe it has nothing to do with it, but I had this doubt.
bears
You didn’t do any really wrong, but what you are seeing looks like the same issue I had with the VM that gave me a problem. Could you zip up and post that particular .vmdk file - I’d like to see if it’s the same problem I ran into. The file should (it should be a small file that’s the descriptor file for the slices that make up the virtual disk).
for the sake of clarity I am attaching all the vmdk files [virtual disk 000001 - 000002 - 000003 - 000004 - 000005].
bears
Well, this is what I was afraid of. You hit the exact same problem that I did.
It appears that Fusion has marked something in the virtual disk as encrypted. From the disk descriptor entry:
version=1
encoding="UTF-8"
CID=6c0d80be
parentCID=7e1d1f24
createType="twoGbMaxExtentSparse"
keyID=93356c19
encryptionKeys="vmware:key/list/(pair/(null/%3cVMWARE%2dEMPTYSTRING%3e,HMAC%2dSHA%2d1,qjolwwEVYt%2bNbhq%2fhNKpokIXH%2bn6I2EssJqEpi%2fyvdGbQdew52kBk9THfYdGlLu%2f8K3TLhw8%2fSOBFAtxfNuzZC7cTvYyrXJbD9uEPx5ehH8IWCiYlBkB0%2fFlfNuW6KkFAUa2gsxQwS6NUhd%2f2JsPdrTc2BaC90qe19bai%2fnXh518779xiue3nnzBeQjbleHkzacHH1Ij6FNbBnaGSxu0oqGyFyL9fZCG06OvDbhXHNG7azK1rWNv5a8W6ayaljkLGa18%2fGUq7x1FPB3PQfWLqDhdCC4BuxJ6khg3xkAuO836Pv6r%2bVNKJsCHCqMsZmFiiSPPQ92BtpiQ6I%2f7Pp5bSTTa2PUcQmQbsMIVEIxzNmNOi8PZveM22mZ0DnYOVJA9Xbcu65Vf7ghu6VgS9i5ByrceOMYv5V0fo2wvJ%2fOv8QIaJGMEAmjPM7uP%2bHo35cIUyzkdBLHycSikP9vWiod6IifzP%2bxQGQ1hAExqjk0gwicVUATv))"
parentFileNameHint="Disco virtuale.vmdk"
The "keyID" and "encryptionKeys" lines in the descriptor file don't exist on an unencrypted virtual machine. But this virtual disk shouldn't be encrypted at all since it's part of a partially encrypted virtual machine.
I don't think should be happening for a VM that is partially encrypted. I had this happen on a virtual machine that I converted from a VHDX Windows Insider Preview. Simply manually editing the two entries removes the errors, but the data in the virtual disk is lost. Something apparently remains encrypted within the VM (perhaps the grain table)?
@a_p_ as the resident VMDK guru, do you have any idea why these entries would be set in a supposedly unencrypted VMDK file. And, more importantly, is there any way of getting rid of them?
@Mikero - this is very serious and I'd open a support ticket if I could - that's how bad this is. Can you bounce this by your developers and find out a) how this could happen and b) how it can be corrected? I'm wondering if this could be the reason why people are having problems with converting from the old encryption scheme to the new one even though there is plenty of disk space available for the conversion.
Thanks André - it was worth a shot seeing if you'd seen anything like this before.
I must also note that those lines in the descriptor do not appear in a virtual disk whose VM is partially encrypted. They also seem to prevent the VM from being unencrypted.