@julien-f Hello !

Ok, not problem, I hope it will arrive soon in the UI 🙂

Thank you for the command, I don't think I saw this command in the docs, maybe I can add it ^^
I will look, and I will make a PR if I found in which section I can add the command 🙂

@olivierlambert 👌

@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.

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.

Yes, it should be safe enough to try importing the backup, then starting the VM without network (ie VIFs) and see if it stays up for a few minutes.

I think we could start by adding a manual feature and then see in a second step how we could automate it.

Thanks @cookie-eater2000, we'll take a look.

@adzmedia Hi adzmedia,

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.

@marcungeschikts Yes, it's the third point of the GitHub issue 🙂

@julien-f

Apologies, I'm not sure how to do that, but it seems easier to run the server as root instead of these workarounds.

@pdonias @olivierlambert hey thanks for adding this in latest release!!

45658591-208e-46f6-b3af-74144019b94e-CleanShot 2021-07-02 at 19.36.01@2x.png

Hello @Zevgeny .
Finally, we won't be able to display if the vm has changed since the snapshot.

I agree it makes sense.

Ping @pdonias

@olivierlambert issue created
https://github.com/vatesfr/xen-orchestra/issues/4515

abaughGHW created this issue in vatesfr/xen-orchestra open Support IPv6 in IP pool #4515