ova import failing silently. logs show timeout against xcp-ng node

nraynaud

@ITJamie I'm sorry I can't answer about the node version until we get the bug.

I suspect there is some kind of compounding, where an error happens somewhere, but is lost by improper error handling, and no all we see is a corrupted state long after the error happened.

Arraylist

@ITJamie I am having the same issue!
Same error, also trying to import Watchguard Dimension 2.2.
I am on XOA 5.67 (node: 16.13.2) and XCP-ng 8.2.1.
I am using Windows and tried with Firefox 97 and Chrome 98, fails with both.
The VM also kind of gets created (with the [Importing] before the name, which never goes away).
Both disks also get created (Data disk looks complete, but System disk is always attached to control domain on host)

olivierlambert

@Arraylist can you switch to latest branch of your XOA please? We'll see if this has any impact

Arraylist

@olivierlambert just upgraded to 5.68, issue is still here.

olivierlambert

Anything is the console browser? Do you know if any transfer actually started between your browser and the host?

ITJamie

Ive done a fresh install on debian 11 with node 14.18.3
It now works! from windows and mac. ova's and disk imports

Arraylist

@olivierlambert Yes, I can see network troughput from my client to XOA and from XOA to the XCP-ng host:

olivierlambert

That's interesting

@Arraylist would you be able to install XO from the sources with Node 14 and report if it works on your side?

Arraylist

@olivierlambert just did a fresh install of debian 11 with node 14.18.3
Fails. Error is the same.

olivierlambert

That's weird that we got different behaviour with the very same code To me, there's something else causing a problem.

yannik

Hi,

first of all, thank you for developing and supporting these awesome products.

I witnessed a similar issue upon running continuous replication on a VM after growing one of the disks on the source side. I run delta backup to a NFS share and continuous replication to another XCP-ng host in one job.

The most important part of the relevant log messages remind me of this issue - this topic is the only similar reference I was able to find, so I hope this is the right place to post. If not, please let me know, and I'll create a new topic

Mar 21 01:00:29 xcp-ng-2 xapi: [ info||8947241 INET :::80|Importing raw VDI R:3967654dad6b|vhd_tool_wrapper] Executing /bin/vhd-tool serve --source-format vhd --source-protocol none --source-fd 1f47b1fe-a9ea-4bda-ab8e-2101e5677059 --tar-filename-prefix  --destination file:///dev/sm/backend/f7aca870-12e0-8352-9f86-f52d575eb313/6cd16448-6839-476d-93b1-2f8b816c827f --destination-format raw --progress --machine --direct --destination-size 0 --prezeroed
Mar 21 01:00:29 xcp-ng-2 xapi: [error||8947241 INET :::80|Importing raw VDI R:3967654dad6b|vhd_tool_wrapper] vhd-tool failed, returning VDI_IO_ERROR
Mar 21 01:00:29 xcp-ng-2 xapi: [error||8947241 INET :::80|Importing raw VDI R:3967654dad6b|vhd_tool_wrapper] vhd-tool output: vhd-tool: Non-zero size required (either a pre-existing destination file or specified via --destination-size on the command line)\x0A

I'm currently running Xen Orchestra compiled from sources, on commit 5bc44363f9ac9fa534f3247e697f1b3c6991e916. XCP-ng is on version 8.2.0.
I know that this is not fully up-to-date, but after retrying that backup as a first measure, Xen Orchestra ran a full backup for that VM, so I can't reproduce that issue anymore, but I figured posting that here might help resolving the aforementioned issue, if the causes correlate.