@stormi

Did minor testing. Seems ok.
Haven't tested Backups.

@stormi

WHAT THIS VERSION OF XEN CHANGES

I must admit I haven't done my homework yet here. You can check the upstream changelogs at the Xen Project. I'll update this post if someone provides a useful bullet list.

Here you go :

Notable Features
This release has seen the increase in hardware support for both x86 and Arm, together with the addition of other improvements and features:

• MISRA-C integration: The project has officially adopted four directives and 24 rules, added MISRA-C checker build integration, and defined how to document deviations. A number of MISRA-C violations have been fixed.
• Static configuration options for ARM: In many embedded environments, we know ahead of time exactly what resources all guests will need at boot time. In constrained resource environments, allocation on use increases the possibility that the allocation will fail at runtime. With static configuration, resources are allocated statically when the hypervisor boots, removing the possibility of runtime failure. Resources which can be statically configured as of 4.17 include event channels, shared memory, and hypervisor heap.
• ARM: Add “tech preview” implementation for VirtIO. Xen now includes full support for VirtIO on embedded systems, on ARM, for the virtio-mmio transport, allowing a wide range of VirtIO devices to be supported. This includes front-end support in Linux, toolstack (libxl/xl) and dom0less support, and a userspace backend. Currently, the following stand-alone backends are available and have been tested: virtio-disk, virtio-net, i2c, and gpio.
• dom0less / Hyperlaunch: cpupools can be specified at boot using device tree. This allows the use of cpupools in dom0less / Hyperlaunch -style configurations; in particular, it makes it possible to assign different types of CPUs of an ARM big.LITTLE system to different cpupools at boot time.
• dom0less / Hyperlaunch: PV frontend / backend connections can now be specified between guests, allowing statically booted guests with PV devices
• On ARM, p2m structures are now allocated out of a pool of memory set aside at domain creation; this provides better isolation between guests against memory resource failures
• ARM: Mitigations against Spectre-BHB
• x86: IOMMU superpage support for all guest types; improving performance of PCI pass-through
• x86: Security support hosts with up to 12 TiB of RAM
• x86: Can now set cpuid parameters for dom0 at boot time
• x86: mwait-idle support: Added SPR and ADL
• x86: Improved speculative mitigation support, including VIRT_SSBD and MSR_SPEC_CTRL features to help guests know what speculative mitigations they don't need to be done (due to mitigations on the hypervisor side), and to control what kind of speculative mitigations the hypervisor performs on their behalf
• Out-of-tree builds for the hypervisor now supported
• ARM: Since addition of Zephyr RTOS guests support (Xen 4.15, Zephyr 3.1.0), work has been done on making it possible to run Zephyr in dom0 improving boot time, stability and paving the way for future safety certification for Xen-based systems

Source : https://wiki.xenproject.org/wiki/Xen_Project_4.17_Feature_List

@ronan-a @dthenot @Team-Storage

Guys, Can you please clarify which method to use for installing XOSTOR in XCP-ng 8.3 ?

Simple :

yum install xcp-ng-linstor
yum install xcp-ng-release-linstor
./install --disks /dev/nvme0n1 --thin

Or the script in the first post ?
Or Some other script ?

Installed fine. Didn't get a chance to deep dive and/or test features.

@stormi said in XCP-ng 8.3 updates announcements and testing:

A few days late because internal tests led to a few fixes, here are the pre-release ISO images for a refreshed XCP-ng 8.3 installer:

https://repo.vates.tech/tmp/

$ cat SHA256SUMS
22deae59e7c5cff7d4691c447af9dbf27b29a372748c1844c280bdc212ef2a5f  xcp-ng-8.3-20250606-linstor-upgradeonly.pre3.iso
9a5dcc8d98949ee207d28307b8b94320d1ffd24841e34ca74e1c0f0422e5ecab  xcp-ng-8.3-20250606-netinstall.pre3.iso
4d6f5a99da0d70920bc313470ad2b14decab66038f0863ca68a2b81126ee2977  xcp-ng-8.3-20250606.pre3.iso

1. No need to upgrade XCP-ng 8.3 with these. It is not a new release. It's refreshed installation images, with all updates included.
2. When we release them, at the same time, XCP-ng 8.3 will be officially labeled LTS. Again, the existing XCP-ng 8.3 that you already use. Not a new XCP-ng release.
3. This is also when XOSTOR becomes officially supported in XCP-ng 8.3 .

This is definitely the best part... I just installed XCP-NG on my test bench (a few days back) with the previous ISOs to test the updates !
Will try this ISO as soon as I get my new PC!
Was eagerly waiting to try XOSTOR in the meantime.

@olivierlambert @stormi

I have a suggestion w.r.t interface-rename.
Can we have a screen at the installation (using iso method) which lists all the NICs and we can rename the interfaces at install time itself ?

@olivierlambert
I don't mean to push or ask for an ETA; but since it's been a few months so I was wondering if there is any update on this ?
Waiting eagerly to have XOSTOR on 8.3

@stormi
Just for clarification sake (I know this might have been said before), installing patches is the same as upgrading from iso in this case ?
(Unlike with previous update where it was mandatory to upgrade using iso)

@olivierlambert
Sure.

Installed in my Homelab. Install went smoothly.

Small bugs I have noticed :
1.

This ONLY happens when using KVM and 'scaling' the display to fit window.

This happens ONLY on the first boot after applying patch ( 6 programs ) once release iso is installed.
This goes away from the second boot.

---

Everything seems to be working smoothly for now. Kudos to the Vates Team !

For everyone who needs to ensure usb-policy.conf remains intact after update/reboot, I have posted a workaround script here.

Please note this is a workaround script only till a better implementation is done by the xcp-ng team.

@olivierlambert

Thanks for the prompt reply !

You are right. The device was filtered. I am now removing from filter and re-testing.

Update: Re-tested and everything seems to work fine.
I will further try to use the signature device to see if it actually works inside the VM.

PS: I see no reason to filter tokens by default. Can we remove the DENY line for smartcards by default ?
We also need to add : DENY: Class=03 subclass=00 prot=00 # HID
as this class is used by some MSI motherboards for HID. Since rest of the HID are filtered, this should be added too for consistency sake.

Very excited to receive a wonderful and detailed reply from @michael-manley.

Thanks @michael-manley for taking over the maintenance of XCP-ng Center!

Hello,

I don't know how many people use this so as per discussion with stormi, the has been removed. If you would like the script to be back, please upvote this post. Once there are enough upvotes, I'll post the script back. Thanks.

Disclaimer:
This script is made as a workaround to prevent usb-policy.conf from getting overridden by new patches/restarts.

Testing Status:

• XCP-ng version 8.3 - Works.
• XCP-ng version 8.2 - Untested. (Should Work)
• Other versions - Completely Untested. Do not use unless you know what you are doing !

Instructions for Install :

1. Please save this script as install_usb_pass.sh
2. Run chmod +x install_usb_pass.sh
3. Run ./install_usb_pass.sh

Instructions for Remove :

1. Run ./install_usb_pass.sh --remove
2. Restart host to complete Uninstallation (this is temporary till I fix last 2 lines of the code)

Script Code

Removed for now, in the interest of not overburdening over lovely devs !
[See Post](https://xcp-ng.org/forum/post/73783)