abudef

I have to say that the acceleration of the migration is really dramatic, which is particularly useful for occasional ad hoc migrations where another task needs to be performed immediately after the migration is completed.
and thanks!

@pierrebrunet Tested and working again, thanks

@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.

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.

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

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     │
└──────────────────┘

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.

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.

In any case, rolling back XO to an older build helps, so hopefully it will be fixed soon.