Looking at the cli output this sounds like a classic confusion of how memory is used in linux. As you can see from free command output, you actually have majority of the memory still available. Graph in XO doesn’t tell much how the memory is actually being used so it might be confusing as most of it is in cache and buffers which usually is something that can be released into use immediately if an application needs ram.

I suggest reading for example this to understand more: https://www.linuxatemyram.com/

@rj-dsl no way, I need to input it in GUI

@jensolsson-se said in Accedentally set up a pool on an xcp-ng server:

xcp-ng-btdjnqqd

Is seems like the "name" xcp-ng-btdjnqqd is the autogenerated name suggested during installation.

This becomes the "name" of the server, but there is also a "name-label", which is what you see in most places of both the XCP-ng center and XO.

If you look in xsconsole, you will most likely see this "name" i the top right corner of the screen.

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

Still running. Must have been the change I did in the BIOS.

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

Nice! That's a pretty clear goal anyway, to provide this as more "turnkey" 🙂

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