[15:17 hypervisor1 ~]# !218
xe vm-import filename=/storage/exported.xva 
b8abe09c-165f-00af-34a5-xxxxxxxxxxxx
[15:21 hypervisor1 ~]# uptime
 15:25:53 up 18 min,  1 user,  load average: 0.05, 0.51, 0.36
[15:25 hypervisor1 ~]# 

Thanks!

I exported the VM about 48 hours ago on an 8.3 pool that was fully up to date. When I tried the import yesterday, it failed. When I made the host physically holding the export the pool master, the import worked. I assumed the issue was just being the master or not. I now believe that was coincidental, not my actual problem because......

I completed a long copy over the internet overnight of the same export from 2 days ago. I scp'd it directly to a pool master. The pool master had 28 listed updates in XOA, so I did the simple yum update. It installed the updates, but then when I went to import the xva, I hit the same error again -

[10:07 hypervisor1 ~]# xe vm-import filename=/storage/exported.xva 
The import failed because this export has been created by a different (incompatible) product version

[10:08 hypervisor1 ~]# date
Thu Jul 17 10:08:44 EDT 2025
[10:08 hypervisor1 ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-updates: mirrors.xcp-ng.org
No packages marked for update

We're not doing anything with false DNS or security features that block access to the actual mirrors.xcp-ng.org.

Any ideas?

Yes, master is really the host that controls all of this stuff, so you would need to run the command on a host running as master.

Each host defaults to be its own master, but when you join one to a pool it will "demote" itself from that role.

What I found was that just doing a "yum update" was not enough, though it was needed.

When I was initially getting the error, I was trying to import on a host that was not the master of the pool. After I designated that host as the pool master, the same command worked easily.

I had to do both the update and import on the master only.

If you exported from a version that's more recent, it's normal. XCP-ng 8.3 had a lot of updates recently, so I'm pretty sure that's the reason why. If you update your destination host, it should be able to importe it.

Note: you can also use XO warm migration or incremental backup/restore to ignore this limitation.