What to do when a VMDK conversion just won’t work

I recently wrote an article here at TechGenix in which I described how to use PowerShell to convert a VMware virtual hard disk file (a VMDK file) into a VHD or VHDX file that works with Microsoft’s Hyper-V. Although the process I described in that article is relatively straightforward, the conversion process doesn’t always go smoothly. Sometimes, attempting to use the Microsoft Virtual Machine Converter to convert a VMDK file results in an error stating that there is an unsupported disk database entry. This can happen whether you are using PowerShell to perform the conversion or you are working from the GUI.

How to fix a VMDK conversion gone wrong

I actually ran into this problem myself while working on the PowerShell-based conversion article I alluded to above. Fortunately, I found some information on TechNet about how to fix the problem. As such, I wanted to share the fix with you.

Before I explain how the fix works, I wanted to show you what the problem looks like. If you look at the image below, you can see that I am attempting to use PowerShell to convert a VMDK file that is appropriately named Bad.vmdk. The attempted conversion results in an error message stating “The entry 9cfda0db-fd49-43c9-bc58-44b2a08d10b1 is not a supported disk database entry for the descriptor.” You can see the error in the screenshot below.

VMDK conversions
To fix the problem, you are going to need a pair of tools named dsfo.exe and dsfi.exe. These tools are a little bit hard to find, but thanks to this article, I found them here.

The trick to fixing the problem is to use the DSFO.EXE and DSFI.EXE tools to change the descriptor information for the VMDK file. The first step is to write the VMDK file’s descriptor to a text file. Once you have done that, you can use the DSFI.EXE file to use that text file to modify the descriptor on the VMDK file. So, let’s take a look at how it’s done.

I began the process by downloading the files from the location specified above. The download consisted of a ZIP file, which I extracted and saved to the system containing the VMDK file that needed to be converted. You should place the DSFO.EXE and DSFI.EXE files where ever is convenient on your own system. For this article, I have these files saved in a folder named C:\DSFOK.

The next step in the process is to open an elevated command prompt window, navigate to the folder containing the DSFO and DSFI files, and then enter the following command:

DSFO “<path to the VMDK file>” 512 1024 Descriptor.txt

This command retrieves the descriptor (1024 bytes at offset 512) and writes it to a text file named Descriptor.txt. You can see what this looks like in the screenshot below.


So now that the Descriptor.txt file has been created, let’s take a look at its contents. Since I didn’t include a path for the Descriptor.txt file in the command that I used, the file was written to my C:\DSFOK folder. You can see what the file looks like in the screen capture shown below.


The TechNet article that I mentioned earlier explained that you need to look through the file and locate a line that references ddb.toolsInstallType. Once you have found this line of code, place a pound sign in front of it to comment it out. While I completely agree that this is an important step in the process, there are a couple of other things to think about.

First, depending on what the VMDK file contains, the ddb.ToolsInstallType line might not exist. You might have noticed that the descriptor file shown in my previous screen capture doesn’t have such a line. If there is no ddb.ToolsInstallType line, then you don’t need to do anything with regard to the tools.

In my case, there were a few other lines that the conversion tool didn’t know how to handle. These lines reference:

  • ddb.uuid.image
  • ddb.uuid.parent
  • ddb.uuid.modification
  • ddb.uuid.parentmodification

If you see any of these things mentioned within your Descriptor file, then they will need to be commented out or removed. There are only five things that must typically appear within the DDB section of the descriptor file. These file things include:

  • ddb.virtualHWVersion
  • ddb.adapterType
  • ddb.geometry.cylinders
  • ddb.geometry.heads
  • ddb.geometry.sectors

If anything else appears within the DDB portion of the descriptor, chances are that it will need to be removed. However, I recommend commenting out unwanted lines rather than deleting them in case you later discover that you need to put those lines back. Here is what my descriptor file looks like after being modified.

VMDK conversions
Once you have modified the descriptor file and saved your changes, the last step in the process is to import the descriptor. The command used for doing so is:

DSFI “<path to the VMDK file>” 512 1024 Descriptor.txt

You can see what the import process looks like in the image below.


Assuming that your modifications to the descriptor file are correct, you should now be able to convert your VMDK file into either VHD or VHDX format. As you can see in the screenshot below, I was able to convert my VMDK file after making the required descriptor modifications. It’s worth noting that the conversion can take a long time to complete.
VMDK conversions

Keep the descriptor simple

As you can see, there is sometimes a little bit of guesswork involved in making the descriptor changes that are necessary to convert a VMDK file into a VHD or VHDX file. My advice is to try to keep the descriptor as simple as you possibly can. If you see lines within your descriptor file that do not appear in my screen capture, try commenting those lines out and see if that will allow you to perform the conversion.

Featured image: Shutterstock

2 thoughts on “What to do when a VMDK conversion just won’t work”

  1. Followed the instructions and it is finally running the conversion. This is a life saver. I’m keeping my fingers crossed this will actually work. We have been struggling with this conversion from VMware to Hyper-v for a day.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top