I've confirmed the discrepancy when health checks are performed. Let's see what @Team-XO-Backend has to say about this.

For those of you that are observing a difference in the reported transfer size between XO5 and XO6, can you please let us know if the affected backup jobs are performing health checks?

I'm not seeing this discrepancy on either XOA 6.8.2 or XO from sources (commit a1dba). Does it occur with all backup jobs or only some of them?

Also, I'm not sure that I understood your reference to the side panel. Are you not able to view it in XO6?

Edit: Just saw your comment regarding health checks. This is certainly something to investigate.

@probain I assume that you are running XO from sources. What is your current commit? Have you tried updating to the latest source?

It's possible that the issue lies within VMware Workstation.

Have you attempted to analyze the exported file using qemu-img?
For example:

qemu-img info file.vmdk
qemu-img check file.vmdk

Ah... ok. I think I originally checked the VM export.

This could be a bug. Does it occur with all VDIs? What happens if you try to import the file back into XO?

@abudef What steps are you performing to export the VDI as a VMDK?

@jcdick1 Ideally you should open a ticket via the Support Portal and provide the tunnel ID there along with a link to this discussion.

@jcdick1 We can take a look using the support tunnel of your XOA instance.

Have you check the status of the nodes and for faulty resources?

linstor n l
linstor r l --faulty

Please switch back to the Stable release channel and then let us know if the issue goes away.

Details for switching release channels can be found here -- https://help.vates.tech/help/en-us/30-versions-and-updates/21-xoa-versions

If you are running XOA, not XO from sources, then we could take a look remotely using the support tunnel.

Otherwise, make sure that you have patched and rebooted each pool member.

Check the output of dmesg -T|grep -Eiv 'guest|capacity|promiscuous' on the host. It's likely that there was a network disconnect at some point and you have a stuck mount. You could also check to see if df -h hangs when you execute it on the host.

@msupport Thanks for the detailed report. Please answer these questions to help us to better understand the source of the issue:

• What OS were the affected VMs running?
• Which guest tools were installed?
• Were the affected VDIs in VHD or QCOW2 format?

Hi,

I found your original request. I will make sure someone from the Sales team responds ASAP.

Regards,
Dan

Hi!

Which documentation did you follow?

Did you verify the md5sum of the downloaded XVA file?

The XCP-ng logs may provide further insight into the error: https://docs.xcp-ng.org/troubleshooting/log-files/

Regards,
Dan

@acebmxer Pretty sure that coming from Veeam. Did you try the option to Restore with different settings?

Actually, isn't XAPI 24.19.2 what is shipped with the original XCP-ng 8.3 release? If so, then you could just do this --

• Reinstall XCP-ng on the new host
• Restore the pool metadata
• Patch the host

This is the safest method to allow the metadata restore --

• Reinstall XCP-ng on the new host
• Patch it to bring it to the correct XAPI level (use https://help.vates.tech/kb/en-us/14/103 as a reference)
• Restore the pool metadata
• Patch the host again to install any remaining updates

See https://xcp-ng.org/forum/post/101039 for a prior example of this. Your case involves a different XAPI version, so a custom list of required packages would be required for it to work.