That "VM" is a snapshot of that running XOA - xbackup1 machine. Open that VM in Xen Orchestra and check snapshots tab, you'll see that the name and uuid (copy button next to snapshot) matches the results from command line.
You can ignore snapshots in listing with: xe vm-list is-a-snapshot=false
Looking at the cli output this sounds like a classic confusion of how memory is used in linux. As you can see from free command output, you actually have majority of the memory still available. Graph in XO doesn’t tell much how the memory is actually being used so it might be confusing as most of it is in cache and buffers which usually is something that can be released into use immediately if an application needs ram.
I suggest reading for example this to understand more: https://www.linuxatemyram.com/
What does the memory min/max settings look like in the advanced tab of those VM's? You could try to set the dynamic min/max to same values. Could very well be that your guest OS doesn't handle it properly when host is trying to dynamically adjust the available VM memory. Although this shouldn't happen (afaik) if there's plenty of memory available on the host, but worth a try at least.
That "VM" is a snapshot of that running XOA - xbackup1 machine. Open that VM in Xen Orchestra and check snapshots tab, you'll see that the name and uuid (copy button next to snapshot) matches the results from command line.
You can ignore snapshots in listing with: xe vm-list is-a-snapshot=false
Isn't that just XenCenter/XCP-ng Center feature, nothing to do with OVA pulling image from internet. Not sure how Xen Orchestra goes around it. In that sense, Xen Orchestra section in this forum isn't probably the correct place for this thread if XCP-ng Center was used 
Feature documented here for example: https://docs.citrix.com/en-us/xencenter/7-1/vms-exportimport-about.html
"If the VMs you are importing were built on a hypervisor other than XenServer, you will need to configure the Operating System Fixup feature to enable the imported VM to boot correctly on XenServer. You will also need to configure networking for the Transfer VM, a temporary VM used when importing/exporting VMs from disk images and OVF/OVA packages."
Stumbled to the same error. Retry finished okay and no issues really. Couldn't really find anything except this thread and no info if this is something that will be fixed/is fixed already.
Not running the latest versions (xo-server 5.50.1, xo-web 5.50.2), but because of the above, i'm sharing logs as well if found useful.
{
"data": {
"type": "VM",
"id": "ae0fd9f4-6915-475e-7809-c3c501177c51"
},
"id": "1585875600008:4",
"message": "Starting backup of vmname (8b5016a9-6ffa-4614-8e6f-c87fe4bcb93f)",
"start": 1585875600008,
"status": "failure",
"tasks": [
{
"id": "1585875600009",
"message": "snapshot",
"start": 1585875600009,
"status": "success",
"end": 1585875651531,
"result": "49545d5f-633c-3bb2-ca7e-8d1cfdb60fc9"
},
{
"id": "1585875651534",
"message": "add metadata to snapshot",
"start": 1585875651534,
"status": "success",
"end": 1585875651595
},
{
"id": "1585875651700",
"message": "waiting for uptodate snapshot record",
"start": 1585875651700,
"status": "success",
"end": 1585875651962
},
{
"id": "1585875652432",
"message": "start snapshot export",
"start": 1585875652432,
"status": "success",
"end": 1585875652432
},
{
"data": {
"id": "aac606cd-a5f0-4a8e-935c-854f144145b7",
"isFull": false,
"type": "remote"
},
"id": "1585875652432:1",
"message": "export",
"start": 1585875652432,
"status": "failure",
"tasks": [
{
"id": "1585875652633",
"message": "transfer",
"start": 1585875652633,
"status": "success",
"end": 1585875804106,
"result": {
"size": 444748288
}
},
{
"id": "1585875804106:0",
"message": "merge",
"start": 1585875804106,
"status": "failure",
"end": 1585875830977,
"result": {
"type": "TypeError",
"message": "\"value\" argument is out of bounds",
"name": "TypeError",
"stack": "TypeError: \"value\" argument is out of bounds\n at checkInt (buffer.js:1185:11)\n at Buffer.writeUInt32BE (buffer.js:1278:5)\n at Vhd._setBatEntry (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:244:16)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:254:111\n at Generator.next (<anonymous>)\n at asyncGeneratorStep (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:24:103)\n at _next (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:26:194)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:26:364\n at Promise._execute (/etc/xen-orchestra/node_modules/bluebird/js/release/debuggability.js:313:9)\n at Promise._resolveFromExecutor (/etc/xen-orchestra/node_modules/bluebird/js/release/promise.js:488:18)\n at new Promise (/etc/xen-orchestra/node_modules/bluebird/js/release/promise.js:79:10)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:26:97\n at Vhd.createBlock (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:256:7)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:282:34\n at Generator.next (<anonymous>)\n at asyncGeneratorStep (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:24:103)"
}
}
],
"end": 1585875830977,
"result": {
"type": "TypeError",
"message": "\"value\" argument is out of bounds",
"name": "TypeError",
"stack": "TypeError: \"value\" argument is out of bounds\n at checkInt (buffer.js:1185:11)\n at Buffer.writeUInt32BE (buffer.js:1278:5)\n at Vhd._setBatEntry (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:244:16)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:254:111\n at Generator.next (<anonymous>)\n at asyncGeneratorStep (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:24:103)\n at _next (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:26:194)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:26:364\n at Promise._execute (/etc/xen-orchestra/node_modules/bluebird/js/release/debuggability.js:313:9)\n at Promise._resolveFromExecutor (/etc/xen-orchestra/node_modules/bluebird/js/release/promise.js:488:18)\n at new Promise (/etc/xen-orchestra/node_modules/bluebird/js/release/promise.js:79:10)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:26:97\n at Vhd.createBlock (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:256:7)\n at /etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:282:34\n at Generator.next (<anonymous>)\n at asyncGeneratorStep (/etc/xen-orchestra/packages/vhd-lib/dist/vhd.js:24:103)"
}
},
{
"id": "1585875830979",
"message": "set snapshot.other_config[xo:backup:exported]",
"start": 1585875830979,
"status": "success",
"end": 1585875831050
}
],
"end": 1585875918847
},
@chevybeef said in [SOLVED] XO From source restore backup fails with VDI_IO_ERROR:
@ronivay, @Danp Yes, 2 different install scripts, 2 different distros and 2 different remotes, NFS and SMB, same results. They are always the same ones failing, the commonality being they are not running VMs, they are larger that the others i.e. 40GB and 16GB, and they are located on a HD not SSD, the HD also being used by another VM to capture CCTV. Transfer speed is 1Gbps, SMB share is on same HD as well.
I'm running version 8.0.0. and the latest XO running on updated version of Debian 9 with your latest version of the script (a note here is that it hadn't installed cifs-utils but even after installing that manually it didn't help). Debian is running with a single CPU and 2GB of RAM.
The host itself is a relatively low spec machine, G4600 (2c4t) with 16GB, 2 x SSDs and 1 x HD.
Issue 3242 looks interesting.
Okay, thanks. cifs-utils dependency is actually fixed recently, but manually installing it should do the trick as well.
Unfortunately i can’t figure out any reason in the installation procedure my script makes that could cause this issue.
I’ve seen some issues even with installation when XO VM had 2GB RAM (even though that should be enough). Maybe you could try increasing that just to rule it out?
@Danp said in [SOLVED] XO From source restore backup fails with VDI_IO_ERROR:
I haven't personally used this script, but perhaps @ronivay will jump in with some advice. Also, you could try building the XO VM manually using the official guide.
@chevybeef Indeed hard to tell with this information only. I understood that two different install scripts give the same outcome? Also only some of these fails. Are they always the same ones?
Which XCP-NG version you’re running? What kind of delay and transfer speed you have to your remote from XO?
Check this: https://github.com/vatesfr/xen-orchestra/issues/3242
I suppose this could also have same effect while restoring.
Hi,
@julien-f from sources documentation still instructs to set path relative to packages/xo-server like it used to be:
[http.mounts]
'/' = '../xo-web/dist/'
sample.config.toml says that paths are relative to configuration file so this would end up looking xo-web/dist path from $HOME/.config/ since configuration is at $HOME/.config/xo-server/config.toml
Noticed this while fixing my "well known installer script"
