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

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.

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.

https://xcp-ng.org/forum/topic/11875/master-commit-a3139-failing-backups

Hi,
I got this error during the last backup. Any idea what could be wrong? Thanks.

XO commit 99312

 {
      "id": "0mtxmc70v-3ew1fc28kiw",
      "start": 1789171202191,
      "status": "failure",
      "tasks": [
        {
          "id": "0mtxmc714-no836gl44qs",
          "start": 1789171202200,
          "status": "success",
          "end": 1789171233085,
          "result": {
            "removedFiles": [],
            "changedFiles": [],
            "merge": false,
            "size": 0
          },
          "message": "clean-vm"
        },
        {
          "id": "0mtxmcv1f-0b2n37nmhd1u",
          "start": 1789171233315,
          "status": "success",
          "end": 1789171236104,
          "result": "cbb23056-280d-224a-c8d7-d9f8d477fd39",
          "message": "snapshot"
        },
        {
          "id": "0mtxmcx6w-67x8mlawksw",
          "start": 1789171236104,
          "status": "failure",
          "tasks": [
            {
              "id": "0mtxmfj61-f15a842hptd",
              "start": 1789171357897,
              "status": "failure",
              "end": 1789171385911,
              "result": {
                "code": "NOT_SUPPORTED",
                "message": "Can't init vhd directory without using alias",
                "name": "Error",
                "stack": "Error: Can't init vhd directory without using alias\n    at RemoteVhdDisk.init (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backup-archive/dist/disks/RemoteVhdDisk.mjs:74:41)\n    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)\n    at async openDisposableDisk (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backup-archive/dist/disks/index.mjs:32:9)\n    at async Promise.all (index 0)\n    at async checkDisk (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/_runners/_writers/_checkDisk.mjs:5:3)\n    at async DiskConsumerVhdDirectory.write (file:///opt/xo/xo-builds/xen-orchestra-202609112300/packages/vhd-lib/disk-consumer/DiskConsumerVhdDirectory.mjs:98:7)\n    at async writeToVhdDirectory (file:///opt/xo/xo-builds/xen-orchestra-202609112300/packages/vhd-lib/disk-consumer/index.mjs:43:10)\n    at async RemoteAdapter.writeVhd (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/RemoteAdapter.mjs:487:14)\n    at async asyncEach.concurrency (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:276:31)"
              },
              "message": "transfer"
            }
          ],
          "end": 1789171385913,
          "result": {
            "code": "NOT_SUPPORTED",
            "message": "Can't init vhd directory without using alias",
            "name": "Error",
            "stack": "Error: Can't init vhd directory without using alias\n    at RemoteVhdDisk.init (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backup-archive/dist/disks/RemoteVhdDisk.mjs:74:41)\n    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)\n    at async openDisposableDisk (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backup-archive/dist/disks/index.mjs:32:9)\n    at async Promise.all (index 0)\n    at async checkDisk (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/_runners/_writers/_checkDisk.mjs:5:3)\n    at async DiskConsumerVhdDirectory.write (file:///opt/xo/xo-builds/xen-orchestra-202609112300/packages/vhd-lib/disk-consumer/DiskConsumerVhdDirectory.mjs:98:7)\n    at async writeToVhdDirectory (file:///opt/xo/xo-builds/xen-orchestra-202609112300/packages/vhd-lib/disk-consumer/index.mjs:43:10)\n    at async RemoteAdapter.writeVhd (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/RemoteAdapter.mjs:487:14)\n    at async asyncEach.concurrency (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:276:31)"
          },
          "message": "export",
          "data": {
            "id": "b9438bf1-1439-4aaf-b62f-31f3c7d3f93d",
            "isFull": false,
            "type": "remote"
          }
        }
      ],
      "infos": [
        {
          "message": "Transfer data using NBD"
        },
        {
          "message": "will delete snapshot data"
        },
        {
          "data": {
            "vdiRef": "OpaqueRef:11cb87e5-ce7f-4a20-4051-a9033e0c218c"
          },
          "message": "Snapshot data has been deleted"
        }
      ],
      "end": 1789171387177,
      "result": {
        "code": "NOT_SUPPORTED",
        "message": "Can't init vhd directory without using alias",
        "name": "Error",
        "stack": "Error: Can't init vhd directory without using alias\n    at RemoteVhdDisk.init (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backup-archive/dist/disks/RemoteVhdDisk.mjs:74:41)\n    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)\n    at async openDisposableDisk (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backup-archive/dist/disks/index.mjs:32:9)\n    at async Promise.all (index 0)\n    at async checkDisk (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/_runners/_writers/_checkDisk.mjs:5:3)\n    at async DiskConsumerVhdDirectory.write (file:///opt/xo/xo-builds/xen-orchestra-202609112300/packages/vhd-lib/disk-consumer/DiskConsumerVhdDirectory.mjs:98:7)\n    at async writeToVhdDirectory (file:///opt/xo/xo-builds/xen-orchestra-202609112300/packages/vhd-lib/disk-consumer/index.mjs:43:10)\n    at async RemoteAdapter.writeVhd (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/RemoteAdapter.mjs:487:14)\n    at async asyncEach.concurrency (file:///opt/xo/xo-builds/xen-orchestra-202609112300/@xen-orchestra/backups/_runners/_writers/IncrementalRemoteWriter.mjs:276:31)"
      },
      "message": "backup VM",
      "data": {
        "id": "f855838c-1130-75fc-ae72-158fc75241ae",
        "type": "VM",
        "name_label": "WSDB01",
        "progress": 0
      }
    },

NFS remote; jobs for all backup-up VMs are affected.

Hi,
is there any documentation describing the directory structure of the backup directory on an XO remote storage? I’m trying to understand at which level the different GUIDs are stored and what they represent, so I can determine which VM or VDI a particular part of the structure belongs to.

Thanks in advance!

xo-vm-backups$ ls
0160580e-99c1-3d3d-2aa3-f1a6354f0ad9  555a250a-59f2-89a0-4225-e5fe17e78523  9901590b-9ed7-6b5a-9898-f4fec7d27881
02f15303-bd87-4eec-e3fd-8cc57fc9c363  587d66ad-40a2-519b-2521-15ac5f123acf  a715f6bd-66c7-9d28-5ff5-acdc8e8bc75a
039f5b86-ea3f-d4a4-e4ff-1c449b38d0c3  61141d66-f3ff-3e21-f7d3-de86943167a6  c5f8ee71-feb0-164b-fc66-3582debce67b
0bb23cac-556a-e9af-1f3b-8d3f1b3e1154  659a6dd4-1f37-83da-3504-fff133250751  c9bf5991-946e-1a34-d0c6-29c077fdb74e
0d5d0c53-414b-69d7-1a48-c9463bcd82d3  66d9213d-baaa-f15d-e1ec-c2e51863c741  c9cc715b-5fca-618d-7e61-c9c34a25846e
25591059-a6c0-fab1-dc7e-91713c7e3958  696df785-eb69-2413-7ce0-8604289e05da  d25dad37-030b-d3e4-9e34-1d019a887849
2939d5eb-9d4a-df46-d203-595dff30bf15  712e05e9-1bf9-e7be-68ba-99cbfc4c1d3b  d3d51860-e539-73cd-eff9-6a1d96e55903
29fd8cbb-5f80-9d07-9232-f749958e0eaa  732de318-79af-8ddb-1e64-8c80dca4b58c  e213fe74-043b-8dc3-a840-757f42ba5ab6
35b9d734-210d-973a-f288-baac79661c0a  77a3fdf6-8ea7-b44e-f938-52dfb5ecd68f  e4397408-fc69-98ca-945b-689fbd670b14
38fdf0a0-f449-6816-5d84-c7eb766293f8  7b2b3e97-7d7d-60b8-4593-48a3637c9bca  ed491703-bb13-edc6-8717-b11efd0a7cca
3e148249-3fe9-57a4-e081-096b8673aafe  7ca6d543-9299-f7a9-9f1d-1f8378ef02e5  ee4cc0fd-0ddb-73ab-5e98-6fd48142aabc
3ef27488-c8b0-4482-9092-ae13a052002c  84dd7371-717e-039e-d75f-c9675a3bc5c3  f1d88ed9-bfdd-8658-f217-ca2a6dff8aea
4ab02355-b998-9c16-78d4-327d73f91ed8  86e93acf-feee-ea5d-92fd-0d31c4195ad7  f855838c-1130-75fc-ae72-158fc75241ae
4b6b4ef8-f61f-664d-0ce1-664b8fcd264f  97411e1b-0d70-8431-b93b-86790943e97b

Hi,
for several weeks, since 23 June 2026 (see below), I have been experiencing the same issue. XO (from source; daily updated) is running as a VM on the host (updated on the day or day + 1 the patches were released) being backed up.

result	
name	"BodyTimeoutError"
code	"UND_ERR_BODY_TIMEOUT"
message	"Body Timeout Error"
stack	"BodyTimeoutError: Body Timeout Error\n    at FastTimer.onParserTimeout [as _onTimeout] (/opt/xo/xo-builds/xen-orchestra-202607312004/node_modules/undici/lib/dispatcher/client-h1.js:688:28)\n    at Timeout.onTick [as _onTimeout] (/opt/xo/xo-builds/xen-orchestra-202607312004/node_modules/undici/lib/util/timers.js:162:13)\n    at listOnTimeout (node:internal/timers:605:17)\n    at processTimers (node:internal/timers:541:7)"

Configuration	2026-07-31 20:22	2026-07-31 20:22	a few seconds		
Configuration	2026-07-31 20:16	2026-07-31 20:21	5 minutes		
Configuration	2026-07-31 20:09	2026-07-31 20:14	5 minutes		
Configuration	2026-07-31 19:50	2026-07-31 19:55	5 minutes		
Configuration	2026-07-30 20:53	2026-07-30 20:53	a few seconds		
Configuration	2026-07-30 19:50	2026-07-30 19:50	a few seconds		
Configuration	2026-07-29 19:50	2026-07-29 19:50	a few seconds		
Configuration	2026-07-28 20:05	2026-07-28 20:05	a few seconds		
Configuration	2026-07-28 19:50	2026-07-28 19:55	5 minutes		
Configuration	2026-07-27 19:50	2026-07-27 19:50	a few seconds		
Configuration	2026-07-26 20:49	2026-07-26 20:49	a few seconds		
Configuration	2026-07-26 19:50	2026-07-26 19:55	5 minutes		
Configuration	2026-07-25 19:50	2026-07-25 19:50	a few seconds		
Configuration	2026-07-24 19:50	2026-07-24 19:50	a few seconds		
Configuration	2026-07-23 20:48	2026-07-23 20:48	a few seconds		
Configuration	2026-07-23 19:50	2026-07-23 19:55	5 minutes		
Configuration	2026-07-22 19:50	2026-07-22 19:50	a few seconds		
Configuration	2026-07-21 19:50	2026-07-21 19:50	a few seconds		
Configuration	2026-07-20 19:50	2026-07-20 19:50	a few seconds		
Configuration	2026-07-19 19:50	2026-07-19 19:50	a few seconds		
Configuration	2026-07-19 07:47	2026-07-19 07:47	a few seconds		
Configuration	2026-07-18 19:50	2026-07-18 19:50	a few seconds		
Configuration	2026-07-17 19:50	2026-07-17 19:50	a few seconds		
Configuration	2026-07-16 19:50	2026-07-16 19:50	a few seconds		
Configuration	2026-07-15 19:50	2026-07-15 19:50	a few seconds		
Configuration	2026-07-14 19:50	2026-07-14 19:55	6 minutes		
Configuration	2026-07-13 23:03	2026-07-13 23:03	a few seconds		
Configuration	2026-07-13 19:50	2026-07-13 19:55	5 minutes		
Configuration	2026-07-12 19:50	2026-07-12 19:50	a few seconds		
Configuration	2026-07-11 19:50	2026-07-11 19:50	a few seconds		
Configuration	2026-07-10 19:50	2026-07-10 19:50	a few seconds		
Configuration	2026-07-09 19:50	2026-07-09 19:55	5 minutes		
Configuration	2026-07-08 19:50	2026-07-08 19:50	a few seconds		
Configuration	2026-07-07 19:50	2026-07-07 19:55	5 minutes		
Configuration	2026-07-06 19:50	2026-07-06 19:50	a few seconds		
Configuration	2026-07-06 13:34	2026-07-06 13:34	a few seconds		
Configuration	2026-07-05 19:50	2026-07-05 19:55	6 minutes		
Configuration	2026-07-04 19:50	2026-07-04 19:50	a few seconds		
Configuration	2026-07-03 19:50	2026-07-03 19:50	a few seconds		
Configuration	2026-07-02 19:50	2026-07-02 19:50	a few seconds		
Configuration	2026-07-01 19:50	2026-07-01 19:50	a few seconds		
Configuration	2026-07-01 06:28	2026-07-01 06:28	a few seconds		
Configuration	2026-07-01 00:52	2026-07-01 00:57	5 minutes		
Configuration	2026-06-30 19:50	2026-06-30 19:55	5 minutes		
Configuration	2026-06-29 20:23	2026-06-29 20:23	a few seconds		
Configuration	2026-06-29 19:50	2026-06-29 19:55	5 minutes		
Configuration	2026-06-28 19:50	2026-06-28 19:50	a few seconds		
Configuration	2026-06-27 19:50	2026-06-27 19:50	a few seconds		
Configuration	2026-06-26 19:50	2026-06-26 19:50	a few seconds		
Configuration	2026-06-25 19:50	2026-06-25 19:50	a few seconds		
Configuration	2026-06-24 19:50	2026-06-24 19:50	a few seconds		
Configuration	2026-06-24 07:03	2026-06-24 07:03	a few seconds		
Configuration	2026-06-23 19:50	2026-06-23 19:55	5 minutes			

abudef said:

I was thinking more of updating the entire set of the agent and drivers, similar to how XenServer VM Tools for Windows have it implemented. Using a scheduled job, they regularly check whether an update is available, and if so, they carry out the update of both the agent and the drivers themselves.

Hi, how’s it looking regarding a possible automatic update?

@stormi said:

This is not exposed in Xen Orchestra yet.

When will it likely be available in the GUI?

Thank you, @pilow @bastien-nollet , for the explanation. It would certainly be worthwhile to expand the documentation to make it clear how these settings relate to each other and how to use them correctly, perhaps with some practical examples.

Hello,
I have two questions about backups:

• What is the relationship between the “Backup retention” values within the schedule and the values in the “Long-term retention of backups” settings?

• Is it better to use the “Full backup interval” parameter, or to configure a schedule with the “Force full backup” option? For example, one schedule running once daily Mon–Sat, and another schedule running once daily on Sun with the “Force full backup” option?

versus

I have gone through the documentation at https://docs.xen-orchestra.com/backup, but it is still not entirely clear to me. Thank you.