My Windows server 2019 VM corrupt often

[VMware Community Member]

I encountered a problem in my Mac VMWare. I have several Windows Server 2019 VM stored in the SSD drive. 2 days before I found some VM corrupted. Some can be repaired by command, but some cannot. Even I repair a VM by command prompt, it corrupted again when I reopen it. The only thing I have done before this problem happened is upgrading my MacOS to Sonoma. I wonder the compatibility between current Fusion player 12 and new MacOS may caused this. I upgrade my Fusion player to the latest version (trial version) but no luck. VM is still corrupt. I observed that this problem was mostly on Windows Server 2019 VM. It seems good for my Windows 10 and Ubuntu VM even they are corrupted but can be repaired. I checked my SSD by diskutil. All SSD are good with no problem. I dare not to open any VM now. Can anyone give me advice on solving this problem? I wonder if upgrading my Fushion player to Fushion Pro 13 can solve this problem or not. I want ensure the problem can be solved before place order to buy the Fusion Pro 13.

[Shen88]

Hello ,

 

I would like to point you to a old post on our community where the similar issue is being discussed and resolution is provided, please have a check on this.

Solved: 'Virtual Disk.vmdk' has one or more internal error... - VMware Technology Network VMTN

 

 

[VMware Community Member]

Hi, Thank you for your reply. I follow the 6 steps, replace my vmdk file name with my vmdk file name. After completion, I reboot the VM, the error message come out as attached. It is differs from the previous one, still cannot boot it. I cannot do my work now because I do not know when will the VM corrupt. Any solution? Thanks again. 

[a_p_]

>>> I follow the 6 steps, replace my vmdk file name with my vmdk file name.

That was not a good idea, because the fixes that I posted in the other thread were for that special case.
With running the commands, you modified the file, and even possibly truncated it!

I hope you did not just run the 6 commands, but also followed my advice " I strongly recommend that you backup the .vmdk file before making the modifications."

As mentioned by please provide some details, to see what may be possible with the current state of the virtual disk:

• a listing of the files in the virtual machine bundle and
• (assuming that you have configured the defaults of a virtual disk split into multiple pieces) the small virtual disk descriptor file virtual-disk-name.vmdk (file without the -s0**.vmdk at the end of the file name. 

André

 

[VMware Community Member]

Hi, 

I have completed moving VM from one exFAT 2TB SSD to another APFS SSD. It took 2 days to copy all VM to the new SSD. After completion, I boot up every VM in the new SSD at least three times each one by one; they seem good with no corruption, except two VM already corrupted in the old SSD. Copying did not make them become good again. I wonder if there is a solution to rescue them? Attached is the screen snapshot for the list of files inside the VM and the error messages during the boot process. 

Finally, thank you everyone here in this post giving me invaluable advice. 

[a_p_]

I can see that a new vmware.log file was created. Please attach this file to your next reply, to see whether it contains helpful information.

André

[Technogeezer]

---

 wrote:

Copying did not make them become good again. I wonder if there is a solution to rescue them?

---

This is as expected. Copying a VM does not fix any problems contained in it.

Before proceeding further, make a copy of this VM.

In order for someone like to assess whether this VM's virtual disk file is intact or if it needs to be repaired. To do that  please post the following for this virtual machine:

Go into the Terminal, and execute the following (the quotes are necessary):

ls -alR "/Volumes/Sandisk SSD/TWGUIV20/WIN19Y2V20" > ~/Desktop/WIN19Y2V20_file_list.txt
cp "/Volumes/Sandisk SSD/TWGUIV20/WIN19Y2V20/Windows Server 2019.vmdk" ~/Desktop

Then zip up the .vmdk file and the .txt file we just created, as well as the vmware.log file from the last power-on attempt and attach it to a reply in this thread.

From the VMware point of view, though, if no errors are being thrown by Fusion about a problem with the virtual disk, that means the virtual disk structure from the Fusion side is intact..  You may be faced with corruption of the data within VM (including overwriting of the partition table and/or boot sector), which is outside of what Fusion can do for you. You're then looking at methods to repair a disk from Windows.

Do you have bootable installation media handy for Windows Server 2019? If not, I'd get one because you're going to need it.

At best, the boot sector of the virtual disk is trashed, and that may be able to be repaired with Windows utilities booted from the installation media. At worst, the entire disk structure of the virtual disk has been trashed, and you're faced with recovery either by restoring from a good known backup or re-installation of WIndows (with potential of data loss). 

[VMware Community Member]

Hi Paul,

Thank you so much for your help. Attach the zip file for your reference. I have downloaded a Windows Server 2019 iso trial version from Microsoft website and try to fix the problem. But because of my limited knowledge, I do not know how to proceed. Is this iso useable? 

Thanks again!

Leo

Attachment(s)

WIN19Y2V20.zip   50 KB 1 version

[bluefirestorm]

From the screenshot, it looks like the VM is stored on an external Samsung T7 SSD.

What filesystem is used on the Samsung T7? Is it exFAT or APFS? Did you reformat the SSD to APFS before using it with your Mac hardware?
The exFAT filesystem is not good for running VMs and it is prone to corruption as there is no journaling mechanism.
If it is exFAT, that it the likely cause of frequent VMDK corruption.

 

[Technogeezer]

 's note about file system formatting is definitely something to check.

Also consider that Fusion 12 is not supported or tested for use on Sonoma. Fusion 13.5 is the first version that supports Sonoma. You really should be running Fusion 13.5.

There's no need to consider an upgrade to Fusion Pro. It doesn't enable any features that would be related to fixing this problem.

 

[VMware Community Member]

I have upgraded to Fusion player Version 13.5.0 already. The problem still exist.

 

[VMware Community Member]

Surprise! One of a corrupted VM suddenly allows me to get in. I try to create a snapshot immediately but it prompts an error said it is not a virtual disk! Any idea?

[VMware Community Member]

It is exFAT. I did not change it since I purchase it. I have 3 SSD in exFAT format. They are used over 2 years without a problem. It is strange that they have come out with the same problem suddenly in the past two days. Any solution to rescue the corrupted VM? 

[Nathan Savolskis]

Is there a reason you cannot run the VM on your Mac (versus using an external SSD)?  

I agree, using a set-up like this (while valid) introduces a lot of room for error.  And as was pointed out, if you're using the exFAT filesystem on the SSD, that is very prone to error/corruption - which is not captured well by diskutil

If you have the space on your Mac, try migrating one of your VMs to the internal storage and see if you still encounter that problem. 

If you are able to migrate (non-critical, non-VM) files from your Mac to the SSD, that should free up space to try the workaround above.

The next best solution would be to upgrade your Mac storage (if possible) or worst case get a new Mac with larger storage.

 

[VMware Community Member]

I use separate VM for difference project, include Windows Server VM, Windows 10 and Ubuntu VM. My 1T SSD mac does not have space to hold so many VM. I have put one Windows Server VM on my local Mac. It also come out error but can be fixed by vmware-vdiskmanager. I dare not to open any VM. I am afraid it will collapse before I have any rescue solution.

[Technogeezer]

You will need disk space to copy those VMs off of the Samsung SSD (using the Finder and with Fusion shut down). The copy operation typically won’t introduce further damage. Reformat the disk as HFS+ or APFS in the Disk Utility. Copy your VMs back to the SSD. 

Also exclude the SSD from being backed up with Time Machine.

You are lucky that you had not seen issues running your VMs on an exFAT formatted disk. It’s been observed for a while that Fusion has issues running VMs on anything other than HFS+ or APFS disks. Apple’s ExFAT implementation does not support the file system API operations that Fusion needs.

Plus as  notes, the file system itself as defined by Microsoft does not contain resiliency features like APFS, HFS+ or even NTFS. It’s good for data transport, but not as a medium to run applications from. 

[VMware Community Member]

Thanks for your advice. I will buy a new SSD immediately and format to APFS. Copy the VM to new SSD and have a try. For those showed corrupted VM, is there a way to rescue them?

[Technogeezer]

Depends on what's reporting the corruption. If Fusion is not reporting a problem with a corrupted virtual disk, then you'll need to treat the problem as if it were a physical machine and use Windows recovery tools. 

If Fusion is detecting a corrupted virtual disk like your screen shot in the original post, I'd post

• a listing of the files in the virtual machine bundle and
• (assuming that you have configured the defaults of a virtual disk split into multiple pieces) the small virtual disk descriptor file virtual-disk-name.vmdk (file without the -s0**.vmdk at the end of the file name. 

Then let's see if our resident experts such as  can guide you in how/if you can repair the virtual disk.  Note that even if the virtual disk can be repaired, you might have some file system corruption within the virtual disk that may or may not be able to be repaired - so be prepared. 

 

[VMware Community Member]

Thank you so much for your advice. I have followed your instruction to run it on vmdk. My file is "Windows Server 2019.vmdk". Unfortunately, it does not make the VM boot again. I will take your advice to copy my VM to APFS disk to see whether corruption will happen again. The corrupted VM is indicated by vmware-vdiskmanager it is corrupted. It will be perfect if the corrupted VM can be rescued. It can save me tons of time to find out which is the last version of my jobs. Anyway, thanks again for your advice.

[Technogeezer]

Copying the VM doesn't fix any vmdk corruption issue. Most likely the problem is not ExFAT file system corruption, but Fusion introducing the issue because the ExFAT file system just isn't fit for running VMs on.

I'd copy the VM the properly-formatted SSD, and then work to get the VMDK fixed on the copy.  Performing repairs on the copy leaves the original VMDK intact should you need to start the repair over.

When you do get things sorted out, you should devise a backup strategy for your VMs. When you do, make note that:

• Virtual machine snapshots should never be considered as backups.
• Time Machine should not be used for backing up virtual machines.
• At a minimum, you should shut down both your VM and Fusion, and use the Finder to copy the VM to another disk.