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.

Thanks for the reports and the detailed analysis. I'll make sure that the XOA team is notified.

Does it fail every time or is it an intermittent issue?

@pedro_udifar Please update to the latest code base and then let us know if you still encounter this issue.

@pedro_udifar What is your current commit for the XO VM? Can you share the full error log as an attachment?