@MajorP93 that’s fine - I never use ballooning anyway so I guess I am covered good

@Rod-G These have 9.4.2-xxxx and I need to go through and update everything now that I see how far behind I am. the second VM completed fine after its reboot, something was just stuck in a dirty state and got in the way of the import or health check.

I'm not positive, but this may be available RSN in xo-lite.

@Danp I was going to do the upgrade over the December / January Christmas break in Australia but that is when this issue became apparent so we didn't want to be making major changes until it was resolved. I note @anthoineb noted the first report was late August / September 2025 which was just before 8.2.1 reached EOL, so it would be a shame not to have a fix for it tested on 8.2.1 as it seems an upgrade to 8.3 would be unwise while we still have this issue?

@tonyp90 great, thanks !

@florent said: where does this disk comes from From my Redhat 10 @florent said: if you have access to your SR from the outside, you can also put the qcow2 file directly I create a VM to be a NFS to access the 3 HDs, the qcow disks are on the Redhat 10 that I was trying to import from. Do you mean I put the qcow disks on one of the HDs and access them when I create a VM?

@julienXOvates PR is here https://github.com/vatesfr/xen-orchestra/pull/9868 fbeauchamp opened this pull request in vatesfr/xen-orchestra closed fix(xo-web): ignore the number of snapshot of replicated VM in the health dashboard #9868

@Danp fully patched 8.3 (through the most recent May patches). XO commit d810e (master commit e3a58). I usually update XO around the first of each month; so it's a little bit behind master. There are crash logs in /var/crash. I can provide a log bundle if needed, or copy/paste some info here if I know what to provide.

Thanks for the clarification, @dsmteam !

The sr.scan-driven SMlog growth angle that gumbo2k surfaced is a real lead; there's some context in the storage-related log files reference, but the docs don't go as far as "here's how to throttle it safely on a pool where the underlying disks should spin down." Soft ping to @Team-Storage and @Team-Hypervisor-Kernel: could one of you weigh in on whether other-config:auto-scan=false on the SR is the supported way to reduce scan pressure, or if there's a better lever? I don't want to send anyone down a path that breaks an SR. Apologies if this has already been answered somewhere I haven't seen.

Thanks for confirming! This is really helpful

@julienXOvates Thanks for the quick reply, that’s very helpful!

@dthenot said: you will also likely need to give the host-uuid of the host the disk is on Thanks, and I'm assuming this UUID or Machine ID from: [14:45 xcp-kbbn NAS]# dmidecode --type SYSTEM # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 3.3.0 present. # SMBIOS implementations newer than version 3.0 are not # fully supported by this version of dmidecode. Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: ASUS Product Name: System Product Name Version: System Version Serial Number: System Serial Number UUID: E7AE9723-CB08-A278-5C45-7C10C9473BD0 Wake-up Type: Power Switch SKU Number: SKU Family: To be filled by O.E.M. OR [12:46 xcp-kbbn NAS]# hostnamectl Static hostname: xcp-kbbn Icon name: computer-desktop Chassis: desktop Machine ID: c668f529e66c42b9815fe12f3401df82 Boot ID: dd70b200b25341c688aee9fbc58d20a2 Virtualization: xen Operating System: XCP-ng 8.3 Kernel: Linux 4.19.0+1 Architecture: x86-64 the command would look like this correct: xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=E7AE9723-CB08-A278-5C45-7C10C9473BD0 or c668f529e66c42b9815fe12f3401df82 UPDATE: I tried the new command but I got these error messages: [14:45 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=E7AE9723-CB08-A278-5C45-7C10C9473BD0 The uuid you supplied was invalid. type: host uuid: E7AE9723-CB08-A278-5C45-7C10C9473BD0 [15:14 xcp-kbbn NAS]# ls [15:19 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=c668f529e66c42b9815fe12f3401df82 The uuid you supplied was invalid. type: host uuid: c668f529e66c42b9815fe12f3401df82 then I was successful (I believe with you confirmation) when I left our the host-uuid param: [15:19 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" b802722e-67ac-5aba-8d6c-e565d2d7fa0d and then it was listed as a SR: [image: 1779139583485-screenshot-from-2026-05-18-15-24-03.png] now to the next task command: xe sr-scan uuid=b802722e-67ac-5aba-8d6c-e565d2d7fa0d was successful, but I have another Question, the size of the device is not showing, is this normal being that it was done this way? UPDATE 2.0: I just discovered the xe command: [15:27 xcp-kbbn NAS]# xe host-list uuid ( RO) : 9a5e5bb3-bdb9-41ea-9505-6f6fe630f369 name-label ( RW): xcp-kbbn the uuid does not match the ones provided above, do I need to remove the SR and do it over again using this uuid? I will give it a try using another folder.... UPDATE 2.1: I executed the command using the above uuid: [15:35 xcp-kbbn srv]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=9a5e5bb3-bdb9-41ea-9505-6f6fe630f369 6fc531a0-19a0-b9c1-c78e-c687fce5ff84 and was successful, but now my question for the device size, is it normal or not due to creating it this way? UPDATE 2.2: I forgot to do: ln -s /dev/sda /srv/NAS/sda #although it might be better to use a stable identifier if you have multiple disks xe sr-scan uuid=<UUID of the udev SR> be right back..... UPDATE 3.0: Success, I have all HDs attached to my VM, access all files and the sizes are reported! : [image: 1779147782991-screenshot-from-2026-05-18-17-25-38.png] List of attached disks: [image: 1779147797114-screenshot-from-2026-05-18-17-18-07.png] The VM: [image: 1779148373193-screenshot-from-2026-05-18-17-51-19.png] Thanks for your help!...

the last rewrite of the stream processing ( spring 2025 ) focused on stability and memory footprint, and , on a standard cpu, it tops at around 300MB/s per backup job. Your benchmarks are very interesting, and they confirm most of it. this limit was not really an issue since, in most case the xapi was limiting around 100MB/s per disk , but it will be more a more visible limit Note that master have some fixes on the memory usage (not related to backups) That's why we have started an internal workforce focused on performance, with all the teams from the kernel to the backups, including storage, network and xapi. If I can brag a little : [image: 1779106650898-afd7b59b-a4f0-4a92-88ee-2c7ba52d18bf-image.jpeg] i9 , nvme disk , backup to a nvme disk in passthrough, xoa and vm are on the same host, so it's quite far from real world data, but it shows where the limit is

@JL457 Hi, For now it looks like Wasabi is not sending us the correct date format, which is strange because we support this provider and don't usually have issues. In order to allow us to investigate further, could you send us the full backup job logs ? You can find them by clicking on the failed backup status and then on the download logs button: [image: 1779106635704-export-logs.png] Relevant XO logs would also help. If you are a client, also don't hesitate to open a ticket with an open support tunnel. Thanks.

@taghjichte From my testing you would need to passthought a device for audio. If need for professional audio work then yes a pci passthough would be the perferred option. With that said. @dinhngtu As for sound I have never looked much into it but the only vm I heard make sound is from Fedora even while booted from install iso. Kubuntu or windows with xen drivers installed no audio. (find for me at the moment) While audio seems to work in Fedora from iso it seems to be limited to left channel. Local system is connected to 5.1 sound.

@tsukraw I am taking the ticket and will keep you informed as soon as possible

@johnnezero The full HTML versions will render much better. The PDF conversion is less than perfect. iIll try to get those uploaded, as well.

Take it with a grain of salt, but I think bonds are usually managed as a whole rather than edited port by port in the UI. As far as I can tell, the supported route is from the network section in Xen Orchestra (the bonding part of the infrastructure docs is here: https://docs.xen-orchestra.com/xo5/manage_infrastructure#network-bonding), and on the CLI side, the bond commands are documented at https://docs.xcp-ng.org/appendix/cli_reference#bond-create (there's a matching bond-destroy command alongside it). My honest guess is you may end up destroying and recreating the bond with the four ports you want to keep, since I'm not sure removing a single member in place is exposed anywhere, but I could easily be wrong. If there's a cleaner way that avoids the recreate, someone will let us know.

This is a nice bit of community tooling, and thanks for keeping it updated and being upfront about the "use at your own risk" part. On the naming point a few people raised, I think the distinction folks are drawing is fair: XOA is the Vates-built appliance, and anything you compile yourself is XO from sources. The official docs cover that path at https://docs.xen-orchestra.com/xo5/installation#from-the-sources, including the note that there is no pro support for that method. Hope the project keeps going well!