@rjt yes exactly.

I opened that ticket myself. But it's an old bug that should have been solved or not reproduced since. You should at least upgrade to a supported version to see if it's still happening.

That's the part where are potential/future public API could be very helpful

Well, if you pay for an LTS version with active support on it, indeed, update to a more recent version shouldn't be the solution to a bug. But there's no such thing as LTS for Xen Orchestra, since there's a monthly release cycle. And I'm not aware either that you are paying for it

@bberndt the sdn controller communicate with the hosts on port 6640, opening it on the host should be enough. I don't know what's happening. !this TLS error should have been solved by the override-certs option set to on.

@brodiecyber Looks like it was some fluke with the way i scheduled the backup job as after i reorganized the times for the backup jobs im not encountering the error anymore. so entirely my fault was experimenting with incremental backups Thanks

@olivierlambert said in Some questions to VM and XO and so on: remote in Xen Orchestra is the place Thank you so much! to 3. I think I just go with mounting the NFS or SMB share to a VM to store some data in it. to 4. Was just interested if it works @Darkbeldin Thank you for sharing this tool

@gojjily Hi Gojjily, Not sure i fully understand your question so let me clarify some points and perhaps you can ask some questions after that. XO allow you to make backups to what we call a remote, this remote is a network share (or local but not recommended) inside the XCP network where you can store your backups. You can also backup XCP metadata this allow you in case of a major crash of one of your host to restore the host configuration. Once your backups are setup you can restore them directly from your XO. If you want to protect further your data you could copy your backup to another place but it's not directly include in XO even if you could set two remotes for the same backup job and have you backups directly replicated hope this clarify a bit.

As I said, we can extend it, just ask us

Check the Settings/logs view for more details.

Is there any option to set for timeout value? I say this because, monitoring the process, everything seems to be going well until the moment when it starts to check the free space. XCP-NG is 8.2 up to date, the disk on which the VM is it is formated as local ext. The connection to the backup server is on NFS on the LAN at a speed of 1Gb. On the iotop it seems that the space check goes with speed 650Gbits +.

@darkbeldin For the record, both vm's were running on the same esxi host when exported. This may or may not be a factor (I suspect it is).

@olivierlambert I've dug into the issue a bit more, and it just gets stranger. Downloading to my Macbook on the same network gets ~4MB/s. This means there is something strange going on with the control domain around remote downloads. When I test the disk speed (which is an Samsung NVMe), the speed is 1.7GB/s: [14:31 xcp-host ~]# dd if=/dev/zero of=testfile oflag=direct bs=1M count=5000 status=progress 4998561792 bytes (5.0 GB) copied, 3.000607 s, 1.7 GB/s 5000+0 records in 5000+0 records out 5242880000 bytes (5.2 GB) copied, 3.15049 s, 1.7 GB/s When I test the network speed with Ookla's speedtest-cli it confirms a 1G connection, and a 1G transit to Europe (checked this twice because 1G Atlantic transits are rare): [14:44 xcp-host ~]# speedtest -s 2023 Speedtest by Ookla Server: LaFibre.info - Lyon (id = 2023) ISP: Bell Canada Latency: 108.05 ms (0.49 ms jitter) Download: 960.47 Mbps (data used: 1.5 GB ) Upload: 172.11 Mbps (data used: 293.4 MB ) Packet Loss: 0.0% Result URL: https://www.speedtest.net/result/c/b8f1da9f-5c57-4ad8-ad3b-729e1625affe On my Macbook (on 802.11ac) I can download an Ubuntu image at ~14MB/s ➜ wget http://ubuntu.mirrors.ovh.net/ubuntu-releases/21.10/ubuntu-21.10-desktop-amd64.iso --2021-11-16 14:49:41-- http://ubuntu.mirrors.ovh.net/ubuntu-releases/21.10/ubuntu-21.10-desktop-amd64.iso Resolving ubuntu.mirrors.ovh.net (ubuntu.mirrors.ovh.net)... 213.32.5.7 Connecting to ubuntu.mirrors.ovh.net (ubuntu.mirrors.ovh.net)|213.32.5.7|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3116482560 (2.9G) [application/octet-stream] Saving to: ‘ubuntu-21.10-desktop-amd64.iso’ ubuntu-21.10-desktop-amd64.iso 3%[=> ] 107.27M 14.4MB/s eta 4m 14s However on the control domain the download speed is considerably lower: [14:52 xcp-host ~]# wget http://ubuntu.mirrors.ovh.net/ubuntu-releases/21.10/ubuntu-21.10-desktop-amd64.iso --2021-11-16 14:53:03-- http://ubuntu.mirrors.ovh.net/ubuntu-releases/21.10/ubuntu-21.10-desktop-amd64.iso Resolving ubuntu.mirrors.ovh.net (ubuntu.mirrors.ovh.net)... 213.32.5.7 Connecting to ubuntu.mirrors.ovh.net (ubuntu.mirrors.ovh.net)|213.32.5.7|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3116482560 (2.9G) [application/octet-stream] Saving to: ‘ubuntu-21.10-desktop-amd64.iso.1’ 3% [==> ] 106,910,815 3.20MB/s eta 16m 47s Have you ever see something like this before? I saw you had some discussion on another thread regarding slow writes in a VM, but this looks like it affects the control domain as well: https://xcp-ng.org/forum/topic/4865/slow-disk-writes-inside-vm-on-8-2

Well, it's a bit hard to tell you directly what to do vs XOA, because on XOA you are already on a validated OS (Debian) with some packages installed. On which OS did you install Xen Orchestra in the first place?

Sorry for the huge delay, I just stumbled on this thread It's indeed the case now, XO automatically check the integrity and clean any unused files in VM directory on a remote when that VM is backed up.

Hi, Try to disable/enable back the auto power on for one VM, and try again.

@olivierlambert said in Commands in Xen Orchestra Jobs no longer working: The best solution is to rely on XOA, you know I agree with @olivierlambert! Personally, I'm using XO from sources in my home lab environment -- nothing is "production" and I'm mostly having fun trying to give back to the open source community.

@Danp - thank you. Yes, I did, but that was not helping in this case. Found the solution: Both machines are on a hostserver, which has NOT all networks. So the real reason must be a network problem, therefore a quite missleading error message After moving both VMs to the master of this pool (which is connected to the same network where the xoa resides), everything went fine. Same storage, same vhds.

@indyj The file restore issue was due to installing XO on FreeBSD (fine for VM restores, not file extraction). I then installed XO on Ubuntu 20, and this worked for restoring files from Linux VMs but not Windows VMs. Then I installed on CentOS 8 and had the same problem as Ubuntu. I then installed on Fedora 34 and everthing works fine.

Just hold on for this month release