Updates published: https://xcp-ng.org/blog/2025/07/03/july-2025-security-and-maintenance-update-for-xcp-ng-8-2-lts/ Thank you for the tests!

Hello, I plan to install my XOSTOR cluster on a pool of 7 nodes with 3 replicas, but not all nodes at once because disks are in use. consider: node1 node2 node ... node 5 node 6 node 7. with 2 disks on each sda: 128GB for the OS sdb: 1TB for local sr ( for now ) I emptied node 6 & 7. so, here is what i plan to do: On ALL NODES: setup linstor packages Run the install script on node 6 & 7 to add their disks so: node6# install.sh --disks /dev/sdb node7# install.sh --disks /dev/sdb Then, configure the SR and the linstor plugin manager as the following xe sr-create \ type=linstor name-label=pool-01 \ host-uuid=XXXX \ device-config:group-name=linstor_group/thin_device device-config:redundancy=3 shared=true device-config:provisioning=thin Normally, i should have a linstor cluster running of 2 nodes ( 2 satellite and one controller randomly placed ) with only 2 disks and then, only 2/3 working replicas. The cluster SHOULD be usable ( i'm right on this point ? ) The next step, would be to move VM from node 5 on it to evacuate node 5. and then add it to the cluster by the following node5# install.sh --disks /dev/sdb node5# xe host-call-plugin \ host-uuid=node5-uuid \ plugin=linstor-manager \ fn=addHost args:groupName=linstor_group/thin_device That should deploy satelite on node 5 and add the disk. I normally should have 3/3 working replicas and can start to deploy others nodes progressively. I'm right on the process ? aS mentionned in the discord, i will post my feedbacks and results from my setup once i finalized it. ( maybe thought a blog post somewhere ). Thanks to provide xostor in opensource, it's clearly the missing piece for this virtualization stack in opensource ( vs proxmox )

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

@manilx We recently upgraded our Koji build system. This may have caused disruptions in this recent update release yesterday, where an XML file was generated multiple times. This has now been fixed and should not happen again. This may explain the issue encountered this time, particularly with the notification of updates via XO. Note that normally yum metadata expires after a few hours and so it should normally return to normal on its own.

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