abudef

abudef

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.

abudef

@olivierlambert Thanks for the good news!

I've used VMware for years. ESXi as a server hypervisor and VMware Workstation Pro on the desktop. Even for some labs and test environments I got by with the free version of ESXi with limited APIs. The new licensing policy does not suit me and my companions at all and as a bonus Broadcom has cut the free version of ESXi. Bravo! I think Broadcom should get the award for best marketing of XCP-ng, H-V, Citrix etc. for 2024

On desktops, I need to keep VMware Workstation Pro for many reasons. That's why I was impressed by the videos @lawrencesystems made about XCP-ng & Xen Orchestra. The capabilities that are close to vSphere and vCentre, the ability to import and export VMDK so easily through XO blew me away. And to top it all off, transferring VMDK disks through XO works noticeably faster than migrating VMs between VMw WS and ESXi!

abudef

@dinhngtu said in XCP-ng Windows PV tools announcements:

@abudef Got it, the agent was not changed since the last version so the build number was not bumped. I'll keep that in mind for the next release.

abudef

Great, it's working fine now

abudef

To conclude this: @florent and I discussed the issue in a private conversation. I provided the vmdk file that was causing the problem. It turned out that the problem was caused by the vmdk thin file from VMware Workstation Pro, which has a slightly different structure than the vmdk files on ESXi hypervisors. Currently XO imports these files fine and the problem can be considered solved. Thank you very much @florent for your cooperation and help.

abudef

That's exactly it, thank you

abudef

@tjkreidl We don't need performance, but we do need to test how XCP-ng pools, networking, migration, live migration, backup, import from VMware and so on work. It's just a playground where we can have relatively many XCP-ng hosts, but it's not about performance, it's about efficiency and low requirements, because it's just a playground where we learn, validate how things work, and prepare the process for the final migration from VMware to XCP-ng. We originally had two R630s ready for this, then 4, but that would have been unnecessary, given the power consumption, to have physical hypervisors, so in the end we decided to virtualize it all. Well, on ESXi it's because XCP-ng works seamlessly there in nested virtualization.

abudef

@stormi That's not quite what I meant. The point is that if the host is 8.3/4.17, then virtualization is not working on its guest and therefore no other nested guest can be started on this guest. And actually, yes, if 8.3/4.17 appears somewhere in the cascade of nested hosts, then nested virtualization will no longer work on its guest.

abudef

But I have a suspicion that it hasn't worked since the last or second to last batch of updates for XCP-ng, that it worked before.

abudef

Hello,
on XCP-ng host v. 8.3 (latest updates), I created an XCP-ng 8.3 virtual machine using the CentOS 7 template and enabled Nested virtualization. However, XO shows a "Hardware-assisted virtualization is not enabled on this host" alert and the nested virtual machine cannot be started on the virtualized host.

vm.start
{
  "id": "b2b6c96b-f6c8-a99c-5e72-d6cd1b123022",
  "bypassMacAddressesCheck": false,
  "force": false
}
{
  "errors": [
    "xcp-ng-brxbamkk: VM_HVM_REQUIRED(OpaqueRef:e0855019-e6dd-595d-648c-62872961b97f)"
  ],
  "code": "NO_HOSTS_AVAILABLE",
  "params": [],
  "message": "NO_HOSTS_AVAILABLE()",
  "name": "Error",
  "stack": "Error: NO_HOSTS_AVAILABLE()
    at Xapi._startVm (file:///opt/xo/xo-builds/xen-orchestra-202404302058/packages/xo-server/src/xapi/index.mjs:909:11)
    at Xapi.startVm (file:///opt/xo/xo-builds/xen-orchestra-202404302058/packages/xo-server/src/xapi/index.mjs:948:7)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202404302058/packages/xo-server/src/xo-mixins/api.mjs:366:20)"
}

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.

abudef

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

abudef

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.

abudef

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

abudef

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

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?

abudef

@stormi said:

This is not exposed in Xen Orchestra yet.

When will it likely be available in the GUI?

abudef

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.

abudef

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.

abudef

@AlexanderK said:

@abudef this causes some vms not to boot

You mean that when you enable Nested virtualization in the VM settings under the Advanced tab, the VM then fails to boot?