New update candidates for you to test! A new batch of non-urgent updates is ready for user tests before a future collective release. openssh: Fix low priority CVE-2025-26465 DoS attack when VerifyHostKeyDNS is "yes" or "ask" (The Default value has not changed: "no") samba: Fix vulnerabilities which are very unlikely to be exploitable on XCP-ng but are reported by security scanners. xcp-ng-release: This update adds a certificate to resolve a TLS handshake error, particularly when deploying XOA from CLI using curl. Test on XCP-ng 8.2 From an up to date host: yum clean metadata --enablerepo=xcp-ng-testing yum update --enablerepo=xcp-ng-testing reboot The usual update rules apply: pool coordinator first, etc. No specific steps for these updates for XOSTOR users. Versions openssh: 7.4p1-23.3.2.xcpng8.2 samba: 4.10.16-25.el7_9 xcp-ng-release: 8.2.1-16 What to test Normal use and anything else you want to test. The closer to your actual use of XCP-ng, the better. Test window before official release of the updates None defined, but early feedback is always better than late feedback, which is in turn better than no feedback

Okay, I thought the autoscan was only for like 10 minutes or so, but hey I'm not deep down in the stack anymore

Ping @Team-Storage

@john-c said in Introduce yourself!: @TS79 said in Introduce yourself!: Hi. I'm a cloud solutions architect, with around 25 years of working experience in servers, storage, networking (your typical infrastructure stuff) and about 20 years of virtualisation. I started up a homelab many years ago, and through (too) many evolutions, I've ended up with Lenovo M710q mini PCs running XCP-ng, with another mini PC providing NFS storage (with backup and replication to cater for problems and failures). Absolutely love XCP-ng and am promoting it wherever I can. I've architected and kicked off a project at my employer to replace VMware with XCP-ng, so I'm keen to use the forum to read other people's real-world experiences with storage and host specs, hurdles to avoid, and any tips & tricks. Looking forward to interacting with the community more and more. When checking out Xen Orchestra make sure to look at both the Host Maintenance Mode and the SR Maintenance Mode. I came up with the idea for the SR Maintenance mode during the Covid-19 lock down in the UK. The Vates staff developed and implemented the idea, I pitched it as a useful tool for large infrastructures. The reason being that pools (especially large ones) can have multiple shared storage implemented as SRs. The maintenance mode for SR permits, some of the SR to be put in maintenance mode when the backing separate bare metal hardware is in maintenance, while keeping others not in this situation active. So your less likely to need to put the host in maintenance mode, thus improving pools which are using HA, increasing the up time further. So the VMs aren't affected, when the VMs have been migrated to another storage SR, thus aiding in reducing down time for the VMs. This is a great feature, but I havent used it - How does it work? Is it something like: You put the SR in maintenance mode VM's are migrated to another shared SR Notification about SR maintenance completed?

@gduperrey said in XCP-ng 8.3 updates announcements and testing: Since it doesn't indicate that an updated 8.2 is actually 8.2.1, only the major version is displayed. Not a very good example actually (but what's true is that for 8.2 we didn't add a "LTS" mention next to the version number in the system either). [image: 1750243409436-37210535-b72a-49e3-aeb0-ad59cbbdd82e-image.png] But yes, we decided not to increment the version number for XCP-ng 8.3.0. That breaks compatibility with some third party software because they wouldn't recognize a "8.3.1". However we're working on a secondary version identifier that would allow you to know your precise patch level.