@Danp ╭───────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞═══════════════════════════════════════════════════════════════════╡ ┊ host1 ┊ COMBINED ┊ XX.XX.XX.16:3366 (PLAIN) ┊ Online ┊ ┊ host2 ┊ COMBINED ┊ XX.XX.XX.17:3366 (PLAIN) ┊ Online ┊ ┊ host3 ┊ COMBINED ┊ XX.XX.XX.15:3366 (PLAIN) ┊ Online ┊ ╰───────────────────────────────────────────────────────────────────╯ [16:14 host1 ~]# linstor r l --faulty ╭──────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ Node ┊ Layers ┊ Usage ┊ Conns ┊ State ┊ CreatedOn ┊ ╞══════════════════════════════════════════════════════════════════╡ ╰──────────────────────────────────────────────────────────────────╯

@Forza Comparing against the weaker XOCE Strong: net.ipv4.tcp_mem = 90147 120196 180294 net.ipv4.tcp_rmem = 4096 131072 6291456 net.ipv4.tcp_wmem = 4096 16384 4194304 Weak: net.ipv4.tcp_mem = 41766 55688 83532 net.ipv4.tcp_rmem = 4096 131072 6291456 net.ipv4.tcp_wmem = 4096 16384 4194304

@florent No explicit assigned migration or backup network set. Backups generate errors somewhat randomly. As one VM won't get the "error" one time. But on the next backup run it will. And the third time it might not. This even happens on VMs that are turned off, and therefore shouldn't have any changed bytes between backups. Host is reachable from XO Network has NBD enabled All VMs use VHD IPv4 Backup type is Delta

@poddingue Thank you for the reply, and correction. I totally missed the fact that the Load Balancer plugin has DRS-Type functionality (as well as many more customizable options and features). I'll have to look into it. Thanks again, and Happy Day

On one machine in my lab, /etc/rsyslog.d/xenserver.conf defines 17 outchannels, every one of them at 104857600 bytes, and /var/log/messages isn't one of them; it's written by the stock *.info;mail.none;authpriv.none;cron.none line in /etc/rsyslog.conf and rotated by /etc/logrotate.d/syslog, so nightly and with no size trigger. The docs at https://docs.xcp-ng.org/guides/logs#rsyslog describe the 100 MiB rule but don't list which files it actually covers, which is probably why this is hard to work out without reading the config the way you did. Whether messages can realistically outrun a nightly rotation I don't know, and I'd be guessing if I said either way; the one thing in your favour is that /var/log is its own filesystem, 3.9 GB on the box I looked at (small lab machine, I haven't searched in the code, so I don't know where that size is decided), so it can't take the rest of dom0 with it. Whether that omission is deliberate or just inherited (or even something fancier) is really a question for whoever owns that file, so it might be worth a mention to @Team-OS-Platform-Release.

install_xen_orchestra v0.5.0 — build your own cloud-init VM templates As I am sure most of you know that XOA Hub is not accessible from Xen Orchestra from sources. So v0.5.0 of my install script adds a VM Template Library — a new --build-templates flag (and menu entry) that builds the equivalent on your own pool, from each distribution's own published cloud image. ./install-xen-orchestra.sh --build-templates It runs from your workstation over SSH against the pool master, like --deploy does. Nothing is installed locally and your XO install isn't touched. What you get A sealed template that shows up next other vm templates you have, with: cloud-init — supply an SSH key or a full cloud-config at VM creation. XCP-ng guest tools, installed from guest-tools.iso on the pool. Without these XO never reports the VM's IP. On Debian 13 there's no xe-guest-utilities package, and a failed package install doesn't stop cloud-init, so an apt-first approach silently gives you a template that looks fine and is useless. The ISO is what the XCP-ng docs prescribe anyway. A scrubbed identity — machine-id, SSH host keys, cloud-init state and logs are all wiped before sealing, so clones don't collide on DHCP leases or share an SSH fingerprint. growroot, so the disk size you ask for at creation is actually filled. One template for both BIOS and UEFI — the Debian generic images carry an ESP and a BIOS boot partition, so you just flip "Boot firmware" in XO's advanced settings. The build itself isn't prompted for storage or network — it uses your pool's default SR (or the emptiest one, if you haven't set a default) and the management network. Both are just build-time choices; you pick whatever you want when you actually create a VM from the template. Images are pulled from the distribution's own mirror (nothing redistributed), downloaded onto the pool master so the ~3 GB never crosses your workstation's link, and verified against the origin's published SHA512SUMS at build time —so new upstream releases get picked up without me editing anything. Allow roughly five to ten minutes per template; it has to boot the VM once to install the guest agent and run the scrub. Distros Debian 13 (Trixie) is the only one for now. That's a starting point, not the limit — the catalogue is a table with one row per distro, and adding another is a row in that table, not a change to the build. So: comment here if there's a specific distro you'd want to see sooner rather than later and I'll prioritise accordingly. Repo: https://github.com/acebmxer/install_xen_orchestra Docs for this feature: https://github.com/acebmxer/install_xen_orchestra/blob/main/docs/templates.md

Hello everyone ! I rebuild a new OME appliance with the latest version (4.7) What i did on the rebuild: Via live CD add xen-blkfront and xen-netfront driver, and rebuild the initrd change root password activate SSH. Via TUI Change admin password Set interface to DHCP Via SSH sed -i -e 's/sda/xvda/g' /opt/dell/omc/utilities/tui/bin/ome_disk_config.sh sed -i -e 's/sda/xvda/g' /opt/dell/mcsi/appliance/scripts/appliance_resources.sh bash /mnt/Linux/install.sh # To install XCP-ng tools As usual, please send a DM if you want the link to the VHD Also, if you want to build it yourself, the driver are here https://cecilemorange.fr/drivers/xen-netfront.ko https://cecilemorange.fr/drivers/xen-blkfront.ko Feedback is welcome ! (Disclamer: This build is something I create on my free time and to help people who have difficulty running Dell appliances on XCP-ng. I do not guarantee a fully functional appliance, but I do my best to make it work. If you have a support contract with Dell and require official support for OME, please contact Dell and request compatibility with XCP-ng.)

@acebmxer we are far more explicit on the real usage of NBD, paing the way to mark a failed NBD connexion as an error in a few month also working on a diagnostic tool to be more efficient on the checks thank you all for your time