on my side importing backup config in a new XO installation worked (Using Webinterface). (i build from sources). Only thing wich bugs are backup jobs - i had to open and resubmit every backup job to get them work...
@olivierlambert Yes this is really great. I have a windows box where I experiment with bluetooth a bit and having backup on this machine at least once a week or so feels very good I think 🙂
I think it also makes sense that a machine that needs to be taken down in order to make backup also probably will need another backup schedule.
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.
I can give my nails cut for the fact that this is due to the overall slowness between the xcp-ng and XOA.
I've been having similar issue and was pulling my hair, in a usecase where my xcpng was on the other side of the VPN wire, and the virtual console of the VM, could not be drawn on time to allow me hitting any key to run the content within the mounted iso. (in my scenario I I've been using xcp-ng centre)
this issue become the relict of the past, when I did the same thing within my network (still over the vpn but utilizing a RDP of the machine within the LAN network).
maybe apache quacamole will do the trick for you, to expose some way of reching it out.
think about it.
ps. I've been having this with BIOS / UEFI, at first place I thouht this is an uefi, but it was not.