jvanabra

@olivierlambert I'm not sure what I'm looking for in the XCP logs, and these are busy hypervisors so fishing stuff out is difficult. I'm gonna build a new machine that's not doing anything else and try and get a clearer view.

I feel like I used to know this answer, but that could be my imagination.

I have a Windows Server 2008 R2 Standard VM that was exported from Xenserver 6.5 perhaps 10 years ago. The export is servername.ovf along with a pair of [uuid].vhd files. The source of the export was an HP server with a paid of Xeon E5s... maybe 2640 or similar. The new target is variety of Dell Poweredges with various "modern" Xeons (eg, 6226R). There's a HUGE architectural difference.

I have tried:

1. Importing the OVF, which fails complaining about the disks
2. TAR'd the OVF and VHDs into an OVA, which also fails
3. I've tried these with two versions of XCP Center and two versions of XO targeting three versions of XCP (8.1, 8.2, and 8.3)
4. Importing just the VHDs via XO, that fails

I poked around on the google and Gemini suggested using vbox to convert the VHD to a VMDK, but I think that's incorrect, and it doesn't work anyway.... Vbox bombs out with "could not get the storage format" of the VHD.

Does anyone have any idea on how I might be able to get this ancient @$$ VM running again?

@pierrebrunet I inadvertently found more information yesterday. I installed an old e492b commit on a new machine, configured identically to the original, and got a different error but the same effect. The new error is:

xcp xo backup Error: read ETIMEDOUT

That lead me to this page:

https://xcp-ng.org/forum/topic/10799/backup-timeout-error

I moved the XO machine onto the same subnet as XCP, leaving the storage behind in a different network. This fixed the issue, at least on commit e492b ... I have not yet tried it on the new release... however I am pretty confident it will be successful.

If I'm honest, I think this is a tuning issue between XO and XCP. XO is now mounting an NFS share across this subnet boundary and that mount is not having any sort of performance issue, but for some reason XO times out transferring the same data from dom0? That seems off to me.

It's not a probem moving XO to the other subnet, so I've done that, but maybe this deserves a look in the future.

I updated XO again - just thought I would add the API error details:

Error: ENOENT: no such file or directory, open '/run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/645b7426-0b09-e192-40ea-4f6c36e35c23/vdis/8190942e-8b0d-4044-95b6-6b8d91a463f7/7b86306a-fffa-4528-b946-d0bc60dcb609/20260527T000011Z.vhd'
From:
at NfsHandler.addSyncStackTrace (/opt/xen-orchestra/@xen-orchestra/fs/dist/local.js:21:26)
at NfsHandler._openFile (/opt/xen-orchestra/@xen-orchestra/fs/dist/local.js:154:35)
at /opt/xen-orchestra/@xen-orchestra/fs/dist/utils.js:29:26
at new Promise (<anonymous>)
at NfsHandler.<anonymous> (/opt/xen-orchestra/@xen-orchestra/fs/dist/utils.js:24:12)
at loopResolver (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:83:46)
at new Promise (<anonymous>)
at loop (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:85:22)
at NfsHandler.retry (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:87:10)
at NfsHandler._openFile (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:103:18)

The error in XO remains:

Error: ENOENT: no such file or directory, stat '/run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/645b7426-0b09-e192-40ea-4f6c36e35c23/vdis/8190942e-8b0d-4044-95b6-6b8d91a463f7/c1e95b3b-cca1-457a-a0d4-0a37924c8170/20260527T181636Z.alias.vhd'

What's bizarre is that I absolutely nuked the path

/run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups

with

rm -rf /run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups

so that there was nothing left behind. After starting the job, XO rebuilds the path fine:

ls -al /run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/645b7426-0b09-e192-40ea-4f6c36e35c23/vdis/8190942e-8b0d-4044-95b6-6b8d91a463f7/c1e95b3b-cca1-457a-a0d4-0a37924c8170/

total 13
drwxr-xr-x 3 3001 3001 3 May 27 18:16 .
drwxr-xr-x 4 3001 3001 4 May 27 18:16 ..
drwxr-xr-x 2 3001 3001 2 May 27 18:18 data

but it is correct, the file 20260527T181636Z.alias.vhd never appears.

To be, this proves the NFS is 100% fine... XO can mount, test, write, and delete from the mount just fine. But I don't know why it doesn't create the *alias.vhd file.

@pierrebrunet sorry for the delay in responding... I scored some time out of the office.

Before replying, I rebuilt the XO server using the latest version and created a new backup identical to the last. Just wanted to be sure this issue wasn't fixed... I've attached the log.

2026-05-20T21_41_04.958Z - backup NG.json.txt

@pierrebrunet I did try the "merge synchronously" option, but that didn't change anything.

Can you expand on "your chains have an issue?" I understand the concept of chains, but in this particular case the situation is:

1. Fresh install of XCP
2. Brand new VM that has never been backed up before (though was built originally on another pool). There was no previously existing snapshot.
3. New install of XO targeting a new NFS server with a ne backup job

There shouldn't be any chain involved as literally everything is brand new.

I cleaned up:

1. Removed the snapshots from the VMs
2. Unmounted the NFS
3. Cleaned up the filesystem on NFS
4. Remounted NFS
5. Created a new backup job
6. Left NFS with v4.2, enabled synchronous merge
7. Restarted the job
8. Same failure

Some thing I noticed: When kicking off the job, the VHD appears in the NFS filesystem:

/var/run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/e5f62657-8efb-3c2c-3397-2bfe01df5f0d/vdis/c82e4cd1-a0ee-4d7e-9e57-c77d8102593e# ls -alh 82c9959a-b4fa-46a1-a6ea-8cfbbeca864f/.1777916466905.20260504T174106Z.vhd

In this example, this vhd file was 951mb.

It remains there for about one minute, then disappeared. Shortly later the backup job fails, but I notice the snapshot remains, owned by control domain. That never seems to disappear.

I think it's worth noting that I have imported several test VMs, as well as copied VMs cross-pool (from somewhere else to this pool) so it seems like the normal import/export mechanisms work properly.

If you let me know what logs you'd like, I'm happy to upload them.

Not sure what's going on here. Brand new XO installed from Commit 06c3933, running against brand new fully patched XCP 8.3, targeting a TrueNAS Scale dataset exposed via NFS. Backup test is a Windows server VM with two VHDs attached, totally about 300gb. The error is always the same:

Error: read ETIMEDOUT
Error: ENOENT: no such file or directory, open '/mnt/tn-bk02/xo-vm-backups/e5f62657-8efb-3c2c-3397-2bfe01df5f0d/vdis/c82e4cd1-a0ee-4d7e-9e57-c77d8102593e/9110f4f4-e7d0-42bc-94be-b688b35b6a1c/20260501T213823Z.vhd'

It takes somewhere between 3 minutes and 15 minutes for the backup to fail. While the backup is running, I see the vhd file in the file system appear, then disappear. A while later the backup fails. While the vhd file persists, it ranges in side from about 800mb to 2gb.

XO mounts the export just fine, the test always runs successfully. I have tried mounting the export directly in the OS (Ubuntu) and then directing XO to "local" but get the same result. I've tried forcing NFS to v3, it defaults to 4.2. No change.

From the OS, I can generate big files without issue, like:

dd if=/dev/urandom of=/mnt/tn-bk02/random.file bs=1G count=100 iflag=fullblock

When XO is creating the remote, the mount looks like:

172.16.22.9:/mnt/backup-pool-01/xcp-backups /run/xo-server/mounts/0e60da8f-d41d-4d9a-8f8c-6c0e1ca03a89 nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.16.22.26,local_lock=none,addr=172.16.22.9 0 0

which seems fine to me.

I have tried a few adjustments on the TrueNAS side, including adding and removing permissions and forcing NFS versions.

I think if it I could explain why the vhd file appears in the file system, but then disappears, I'd be closer to understanding what's happening....

If anyone has any thoughts, I'd love to hear them. FWIW, I have three deployments very similar to this elsewhere that work perfectly. The only difference between this install the other three is that this one is on the latest version of XO, and the other installs are considerably older.