VDI export to VMDK results in a corrupted disk

abudef

Hi,
I want to ask if anyone has encountered this issue. If I use XO to download VDI directly in VMDK format, the content is corrupted. VMware Workstation does not see the NTFS partition on the disk; instead it shows it as a RAW partition and the disk is unreadable.

I tried downloading the same VDI as VHD and then converting it to VMDK using qemu-img, and this disk worked in VMware WS without any problems.

Could there be an issue somewhere in the export process when exporting directly to VMDK?

XO 99312 and 280c0 tested.

Danp

@abudef What steps are you performing to export the VDI as a VMDK?

abudef

Danp

Ah... ok. I think I originally checked the VM export.

This could be a bug. Does it occur with all VDIs? What happens if you try to import the file back into XO?

abudef

I tried to export 3 VDIs from 2 different XCP-ng pools. 2 VDIs from Windows Server 2025 VMs and 1 from Windows Server 2022 VM. All 3 VMDKs seem to be corrupted when I try to use them in VMware Workstation.

I also tried reimporting 1 of the exported VMDKs back into the XCP-ng repository and the VM booted without any issue using the reimported VDI.

Maybe there is either an issue with this VMDK format in VMware Workstation or the XO´s export/import method creates VMDK files that can be exported and reimport back into XCP-ng repository while preserving the original state of the VDI in the XCP-ng repository even if it´s unusable in VMware WS.

abudef

Danp

Have you attempted to analyze the exported file using qemu-img?
For example:

qemu-img info file.vmdk
qemu-img check file.vmdk

abudef

qemu-img.exe info Windows Server 2025.vmdk
image: Windows Server 2025.vmdk
file format: vmdk
virtual size: 64G (68719476736 bytes)
disk size: 64G
cluster_size: 65536
Format specific information:
    cid: 2849992906
    parent cid: 4294967295
    create type: streamOptimized
    extents:
        [0]:
            compressed: true
            virtual size: 68719476736
            filename: Windows Server 2025.vmdk
            cluster size: 65536
            format:

qemu-img.exe check Windows Server 2025.vmdk
No errors were found on the image.

It seems that the disk itself is formally OK, but the content is somehow corrupted.

Danp

It's possible that the issue lies within VMware Workstation.

abudef

I don't think it's a VMware issue. If the XO export created a VMDK with incorrect data block contents, qemu-img check can still complete without reporting any errors. It only means that it did not find any problems with the VMDK structure.

abudef

I´m not a developer so I asked Ai what it "thinks" about it...

┌─────────────┐
│  XCP-ng VDI │
└──────┬──────┘
       │
       │ VDI_exportContent()
       │ format = VDI_FORMAT_VHD
       ▼
┌──────────────────┐
│    VHD stream    │
└────────┬─────────┘
         │
         │ vhdToVMDK()
         ▼
┌─────────────────────────┐
│  vhdToVMDKIterator()    │
└───────────┬─────────────┘
            │
            │ parseVhdToBlocks()
            ▼
┌─────────────────────────┐
│    parseVhdStream()     │
│                         │
│    VHD blocks           │
│    { id, data }         │
└───────────┬─────────────┘
            │
            │ onlyBlocks()
            │
            │ lba = id * blockSize
            ▼
══════════════════════════════════════════
     POSSIBLE ERROR HERE
     Incorrect mapping of id ↔ data
     or incorrect block ordering
══════════════════════════════════════════
            │
            ▼
┌─────────────────────────┐
│   generateVmdkData()    │
│                         │
│   VHD block             │
│      ↓                  │
│   grainData             │
│      ↓                  │
│   createMarkedGrain()   │
│      ↓                  │
│   tableBuffer           │
└───────────┬─────────────┘
            │
            ▼
┌──────────────────┐
│   VMDK stream    │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│    VMDK file     │
└──────────────────┘

abudef

Ah, I see it now. What XO exports is the streamOptimized format, which is used in OVAs for transfer. Such a standalone VMDK cannot be used directly and needs to be converted for both VMware Workstation and ESXi , or you can use the OVA import, which performs the conversion automatically.

So before such a VMDK can be attached to a VMware VM, it needs to be converted to monolithicSparse e.g.:

qemu-img.exe convert -p -f vmdk -O vmdk -o subformat=monolithicSparse WS25.vmdk WS25-2.vmdk

abudef

So in the end, I think the best approach is to export the VHD and convert it, because the conversion has to be done anyway, and the native VHD export is faster.

Emmanuel V

It might be worth adding a message in XO at export, or in the documentation ?

abudef

@Emmanuel-V In my opinion, it would make more sense if a standalone disk exported in VMDK format were exported directly as monolithicSparse, so that it would not need to be converted. This makes more sense to me because when only the disk is exported, rather than the entire VM (OVA), it can be assumed that the disk will be attached directly to some VM.