VDI export to VMDK results in a corrupted disk

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.