@cobordism said:

yum update --disablerepo=* --enablerepo=xcp-ng-base,xcp-ng-updates

It's currently in testing and will move to updates if everything (not only nut) is ok:

yum install --disablerepo=* \
   --enablerepo=xcp-ng-base,xcp-ng-updates,xcp-ng-testing  nut

Package landed in testing repo please check the related announcement:

https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/432

Then please confirm the issue is gone by editing post topic with "[SOLVED]" prefix

@Andrew said:

@rzr Installed on test machines with some warnings:

  Updating   : blktap-3.55.5-6.4.xcpng8.3.x86_64                           9/87
cat: /usr/lib/udev/rules.d/65-md-incremental.rules: No such file or directory
warning: %triggerin(blktap-3.55.5-6.4.xcpng8.3.x86_64) scriptlet failed, exit status 1
Non-fatal <unknown> scriptlet failure in rpm package blktap-3.55.5-6.4.xcpng8.3. x86_64

Yes this was reported as "Known issues"

On blktap update a non blocking error is reported,the fix is ongoing and will be delivered soon

  Updating   : sm-fairlock-3.2.12-17.2.xcpng8.3.x86_64                    32/87
Warning: fairlock@devicemapper.service changed on disk. Run 'systemctl daemon-reload' to reload units.

I observed this too, maybe this should be documented too, a reboot will work too.

New feature, security and maintenance update candidates for you to test!

This release batch contains a major storage feature,
read the RC2 announcement for QCOW2 image format support for 2TiB+ images.

The whole platform has been hardened with a major OpenSSH update.

The updated Windows Guest Tools bring support for the XSTDVGA driver, allowing display resizing.

We also publish other non-urgent updates which we had in the pipe for the next update release.

What changed

Storage

QCOW2 image format support is the major feature of this release batch,
check related announcement in forum.

• sm: 3.2.12-17.2
  • Add support for the QCOW2 image format
• blktap: 3.55.5-6.4
  • Add support of new QCOW2 disk type

Maintenance updates

Virtualization & System

• xen: 4.17.6-6.1
  • Sync with XenServer's xen-4.17.6-6.xs8
    * Fix boot failure on some UEFI systems. WIP
• kernel: 4.19.19-8.0.46.1
  • Fix regarding use of the correct MAC address in the rndis_host driver
  • Backport fix regarding a potential bug in the ext4 driver (CVE-2020-14314)
  • Backports fixes in SUNRPC (related to NFS). This prevents host crashes under some circumstances.

Control plane

• xapi: 26.1.3-1.6
  • Several fixes to QCOW2 enablement for importing and exporting, like reducing memory usage on disk import
• xcp-ng-xapi-plugins: 1.16.0-1
  • sdncontroller.py: add support for new optional cookie argument to add-rule and del-rule functions
• xcp-ng-pv-tools: 8.3-16
  • Update to XCP-ng Windows PV Tools 9.1.146.0
  • Include the XSTDVGA driver and improvements to the guest agent/installer

UI

• xo-lite: Update to 0.20.0-1
  • [VM/New] Added secureBoot support (PR #9423)
  • [Dashboard] Fix reactivity of dashboard (PR #9378)
  • [VM] Fixed duplicated ip addresses in the network tab Forum#101359 (PR #9547)
  • [Stats] Return null instead of 0 when no stats available (PR #9634)
  • [Treeview/Pool/Host] Add button to download bugtools (PR #9419)

Network

• gnutls: 3.3.29-10.2
  • Fix dane removal (no more replacing dane with devel package)
• openssh: Update to 9.8p1-1.2.2
  • Deprecate old OpenSSH clients (7.2 and lower) that use weak SHA1 with ssh-rsa:
    • For now, a warning will ask to use an up to date client, on next update weak configurations will be rejected.
• net-snmp: 5.9.3-8.2
  • Fix SNMP regression (daemon configuration was lost in earlier version)
• xcp-ng-deps: 8.3-14
  • Install traceroute to troubleshoot connectivity problems

Additional packages

Best effort support is provided for additional packages provided by the XCP-ng project.

• lldpd: version 1.0.4-1.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng 8.3 updates. However, please prefer the pre-installed lldapd whenever possible.
• nut: version 2.8.0-2.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng updates.
  • User feedback is welcome

Drivers updates

More information about drivers and current versions is maintained on the drivers wiki page.

• emulex-lpfc-alt: 14.4.393.31-1.1
  • This is an alternative driver which handles newer Emulex lpfc devices.
• sfc-module-alt: 5.3.18.1012-1
  • Initial alternate driver for Solarflare SFN5XXX|6XXX|7XXX|8XXX|X2, version 5.3.18.1012

Versions:

• blktap: 3.55.5-6.3.xcpng8.3 -> 3.55.5-6.4.xcpng8.3
• gnutls: 3.3.29-10.1.xcpng8.3 -> 3.3.29-10.2.xcpng8.3
• kernel: 4.19.19-8.0.44.1.xcpng8.3 -> 4.19.19-8.0.46.1.xcpng8.3
• net-snmp: 1:5.9.3-8.1.xcpng8.3 -> 1:5.9.3-8.2.xcpng8.3
• openssh: 7.4p1-23.3.3.xcpng8.3 -> 9.8p1-1.2.2.xcpng8.3
• sm: 3.2.12-17.1.xcpng8.3 -> 3.2.12-17.2.xcpng8.3
• traceroute: 3:2.1.5-2.xcpng8.3
• xapi: 26.1.3-1.3.xcpng8.3 -> 26.1.3-1.6.xcpng8.3
• xcp-ng-deps: 8.3-13 -> 8.3-14
• xcp-ng-pv-tools: 8.3-15.xcpng8.3 -> 8.3-16.xcpng8.3
• xcp-ng-xapi-plugins: 1.15.0-1.xcpng8.3 -> 1.16.0-1.xcpng8.3
• xen: 4.17.6-5.2.xcpng8.3 -> 4.17.6-6.1.xcpng8.3
• xo-lite: 0.19.0-1.xcpng8.3 -> 0.20.0-1.xcpng8.3

Optional packages:

• lldpd: 1.0.4-1.1
• nut: 2.8.0-2.1

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

Known issues

• On blktap update a non blocking error is reported,the fix is ongoing and will be delivered soon

What to test

The most important change is related to storage: adding QCOW2 support also affects the codebase managing VHD disks. What matters here is, above all, to detect any regression on VHD support (we tested it deeply, but on this matter there's no such thing as too much testing). Of course, you are also welcome to test the QCOW2 image format support.

See the dedicated thread for more information.

Other significant changes requiring attention:
* SSH connectivity
* SNMP, if you use it

And, as usual, normal use and anything else you want to test.

Test window before official release of the updates

~2 weeks

@FritzGerald said:

@rzr Just for curiosity.

As far as I understand you assess the risk as low for the nut package - and only for that - to use ci-repo. I am fine with that for my personal servers.

• Would you consider to integrate this into "stable" branch?

yes it's the plan, we usually test packages in ci repos for a couple of weeks and once we're happy of the packages set it goes to testing repo, then users can officially test it (and based on feedback (or absence of feedback) then everything lands in update repo after a week or more (it depends on risk or hurry)..

• What would be the next steps on our side to support this?

I think nothing should be done your side you did your job before the testing window, early feedback is always appreciated (as long people know what they are doing )

But If I were you, just to be safe i would keep trace of packages i have installed from ci or testing repo, in case anything is not going as expected, you can still reinstall those packages from update channel.

• How long would does that roughly take?

It depends usually a couple of weeks, but this next batch might be a bit longer because there is a long waited feature planned.

Check the future announcement in the forum.

Thank again!

thank you for the detailed howto, if there is traction for this feature maybe it worth documenting officially, I'll ask product managers.

@FritzGerald said:

@rzr: Sorry, first and foremost I totally forgot to say thank you very much. I really appreciate you work and effort for this "non-core" issue.

You're welcome !

Keep in mind using/enabling ci repo can be dangerous but for this nut update the risk is low.

Is there maybe anything particular you are interested in for me to test?

Nothing specific, the regular use case but feel free to share to community your experience with your hardware:

https://networkupstools.org/ddl/APC/Smart-UPS_750.html

Then others can compare with other devices supported by N.U.T. :

https://networkupstools.org/ddl/

This makes me think, I have scavenged an APC BE400 but it looks like an offline device, unsure I will make anything useful soon.

Hi, I had a look at it and may have something to be tested soon (TBC https://github.com/xcp-ng-rpms/nut/pull/1 )

Is any of you volunteering for testing an extra (unsupported?) package ?
Or if the client is enough maybe we can put this on hold unless there is more traction?

Reminder: https://docs.xcp-ng.org/management/additional-packages/

@Kajetan321 said:

It looks like "yum remove nut" does the trick.

Yes this "extra" tool was not (never?) supported ,

If you really need it, there are 2 options to consider:

• 1st is convince us to add it to the distro
• 2d rebuild it yourself (to link with updated dep, and also rebuild its deps like neon)

@Mitchel-APD said:

Just updated 1 pool with 3 hosts.
SNMP did not work anymore, config file was not changed.
Got the following error: Authorization Error (SNMP error # 16)

Thank you for your feedback, we're going to investigate, I see that there are many changes between both versions:

https://github.com/net-snmp/net-snmp/compare/v5.7.2...v5.9.3

@gb.123 said:

Wrong diagnostic page; asked for 1 got 8
Failed to get diagnostic page 0x1
Failed to bind enclosure -19

be there in previous updates and may not be related to this particular update.

I think you're right because the issue you are facing is reported by kernel itself (which was not updated), Can you please share more details about the hardware you're using (is any USB device involved ? try smartmon tools too) eventually post details in other sections of forum.

@Andrew said:

@gduperrey The new OpenSSL/SSH blocks existing/working RSA keys from older SSH clients. While you can still use a password for SSH, it will block old keys from working which will break things (not good for existing LTS installs). To maintain compatibility add PubkeyAcceptedAlgorithms +ssh-rsa to /etc/ssh/sshd_config

Hi @andrew, thank you for your feedback, the fallback option you're suggesting will work but it will downgrade the security of your system, we suggested to update clients:

"Note that older ssh-clients (with weak ciphers) will need to update, if connection is rejected."

Let me make it more explicit that older keys should be also refreshed:

  ssh-keygen # To generate new $identity_file 
  ssh-copy-id \
        -i $identity_file \
        -o HostKeyAlgorithms=+ssh-rsa \
        -o PubkeyAcceptedAlgorithms=+ssh-rsa \
        $user@$host
  ssh $user@$host

Ideally this can be done before the update, but let's us think if we have a better strategy to provide a smoother experience, meanwhile if anyone is curious please check:

https://www.openssh.org/releasenotes.html

https://www.openssh.org/txt/release-8.8

"We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519)."

https://datatracker.ietf.org/doc/html/rfc8332

As I understand, RSA is safe unless it was coupled with SHA1 hash function which was then decoupled in later versions (and then obsoleted in V_8_7_P1-4-g234475025 with https://github.com/openssh/openssh-portable/commit/2344750250247111a6c3c6a4fe84ed583a61cc11 "The use of RSA/SHA1 can be re-enabled by adding "ssh-rsa" to the
PubkeyAcceptedAlgorithms directives on the client and server.") .

Regen keys will be needed, better sooner than later, meanwhile we could support weak keys clients during a short (TBD) deprecation period.

Update: I think I was able to reproduce the issue @andrew reported using a RSA key generated with
OpenSSH_5.1p1 Debian-6.maemo2, OpenSSL 0.9.8e 23 Feb 2007

ssh-keygen -lf ~/.ssh/id_rsa.pub
2048 SHA256:abcde+0123456789012345678901234567890/vwxyz user@Nokia-N810-43-7 (RSA)

Used along a later client (in a debian chroot jessie amd64) :
OpenSSH_6.7p1 Debian-5+deb8u4, OpenSSL 1.0.1t 3 May 2016

While it worked as expected (in a debian chroot stretch amd64) : with:
OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019

So to conclude using rsa keys need ssh-7+ while ssh6 can be used using stronger cypher like id_ed25519 (not rsa).

PS: this post may be updated

@ph7 said:

Well I was and still is on v0.19.0:

So you're up to date ! it was a mistake, let me generate an up to date list

Latest XO can be new tested along XCP-ng (with OpenSSL 3):

https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/363

Feedback welcome

New security and maintenance update candidates for you to test!

The whole platform has been hardened with crypto libraries updates.
We also publish other non-urgent updates which we had in the pipe for the next update release.

Important notice

️ Xen Orchestra's sdn_controller users should be aware that OpenSSL was updated to major version 3, causing XCP-ng to reject previously generated self-signed certificates for the SDN Controller: they must be updated manually, accordingly to the guide's procedure.

User feedback is valuable to all, feel free to report success or ask for clarification in the related forum thread.

What changed

OpenSSL and OpenSSH major version update

• openssl: Update to 3.0.9
  • The OpenSSL 3 upgrade is improving the security and maintainability of the system, but has impact regarding certificates generation in sdn_controller, as documented above.
  • To enable backward compatibility with older deprecated APIs, a new package, openssl-compat-10 has been introduced.
• openssh: Update to 9.8p1
  • Note that older ssh-clients (with weak ciphers) will need to update, if connection is rejected.
• libssh2: Update to 1.11.0

Maintenance updates

Virtualization & System

• xen: Update to 4.17.6
  • Xen sources updated to v4.17.6 and synchronization of previously released patches for XSA-477 and XSA-479.
• qemu: Bug fixes
  • qemu would crash when a framebuffer is relocated on a migrated HVM guest.
  • A race condition could cause events to be sent before capabilities negotiation.
• varstored: Update to 1.3.1
  • No further functional change from 1.2.0-3.5 (Fixes for XSA-478 / CVE-2025-58151 were backported).
  • Just syncing with XenServer, rebuilt with openssl-3.

Control plane

• xapi: Update to 26.1.3
  • User agents of clients are now tracked. Fetchable by using Host.get_tracked_user_agents.
  • Now it's possible to delete a VM with a snapshot that has a vTPM associated.
  • Speed up exports for mostly empty disks.
  • Now the tags of VDIs are copied when they are cloned or snapshotted done.
  • Fixed RPU scenario where pool members don't get enabled.
  • Added API for controlling NTP.
  • Fixed falling back to full backups instead of delta backups in cases where a VM was hosted in a local SR with more than 256 disks. This could also cause migrations to fail.
  • Added API to limit the number of VNC connections to a single VM.

UI

• xolite: Update to 0.19.0
  • [VM/New] Added vTPM support.
  • [VM/New] Fix wording in "Memory" section.
  • [TreeView] Scroll to current item in list view.
  • ChangeLog

Storage

• sm: Bug fixes
  • Improve Robustness FileSR GC when a host is offline.
  • Ensure LVM VDI is always active before relink.
  • Remove GC flag DB_GC_NO_SPACE when necessary to avoid errors.
  • Improve error messages when vdi_type is missing on LVM VDIs.
• blktap: Bug fix
  • Fixes a crash happening when scanning a SR with corrupt VHDs.
• lvm2: Update to 2.02.180
  • Add scini device support (Dell PowerFlex).

Network

• netsnmp: Update to 5.9.3
• openvswitch:
  • Rebuild with openssl-3 plus minor maintenance change.
• gnutls: Remove dane tool

Misc

• xcp-ng-release: UX improvement
  • The shell command history now record timestamps to improve consumer support.
• createrepo_c: Update to 0.21.1
• krb5: Synchronized with XenServer 8.4 and rebuilt for OpenSSL 3.
• ipmitool: Update to 1.8.19
• libarchive: Update to 3.6.1
• trousers: Update to 0.3.15 and rebuild for OpenSSL 3.
  • This version includes security fixes for known vulnerabilities in earlier upstream version, deemed not exploitable realistically on XCP-ng.
• wget: Update to 1.21.4

Note that libraries updates (libopenssl, notably) impacted several other packages which had to be rebuilt (some had to be patched too). Refer to the package list below.

Drivers updates (check details below)

More information about drivers and current versions is maintained on the drivers wiki page.

• broadcom-bnxt-en: Update to v1.10.3_237.1.20.0
  • No functional changes expected.
• intel-i40e : Update to 2.25.11
  • PTP-related kernel crash bugfixes for Intel i40e driver version 2.25.11.
  • ️ Google for the "intel <model-name> compatibility matrix" and make sure to update the non-volatile memory in NIC with the matching NVM version, after updating the driver.
  • This is also applicable for the intel-i40e-alt flavour of the driver package.
• intel-ixgbe: Update to 6.2.5
  • More Ethernet PCI Express 10 Gigabit Intel NIC devices are handled (E600 et E610 series).

XOSTOR

In addition to the changes in common packages, the following XOSTOR-specific packages received updates:

• drbd: Reduce the I/O load and time during resync.
• drbd-reactor: Misc improvements regarding drbd-reactor and events.
• linstor:
  • Resource delete: Fixed rare race condition where a delayed DRBD event causes "resource not found.
  • Misc changes to improve robustness LINSTOR API calls and checks.
• sm:
  • Wait for DRBD UpToDate state during LINSTOR VDI resize.
  • Improve LINSTOR error messages in the case of an excessively long VDI resize.
  • Simplify LINSTOR SR scan logic removing XAPI calls.
  • Use worker threads during LINSTOR SR's scan to improve performance.
  • Ensure a XOSTOR volume can't be destroyed if used by any process (outside of the SMAPI environment).
  • Use ss to obtain the controller IP: it's a significant improvement to avoid relying on DRBD commands or XAPI plugins.
  • Avoid issuing errors if the size of a LINSTOR volume cannot be fetched after a bad delete call.
• python-linstor: updated to version 1.27.1. LINBIT's changelog:
  • "Added api method to check the controller’s current encryption state (locked/unlocked/unset)"
• linstor-client: updated to version 1.27.1. LINBIT's changelog:
  • "Added new alias --drbd-diskless to command r td to mimic the option from r c.
  • "Added new sub-command encryption status to show the current locked-state of the controller.

Versions:

• bind: 32:9.9.4-61.el7_5.1 -> 32:9.9.4-63.1.xcpng8.3
• blktap: 3.55.5-6.1.xcpng8.3 -> 3.55.5-6.3.xcpng8.3
• broadcom-bnxt-en: 1.10.3_232.0.155.5-1.xcpng8.3 -> 1.10.3_237.1.20.0-8.1.xcpng8.3
• coreutils: 8.22-21.el7 -> 8.22-22.xcpng8.3
• createrepo_c: 0.10.0-6.el7 -> 0.21.1-3.xcpng8.3
• curl: 8.9.1-5.1.xcpng8.3 -> 8.9.1-5.2.xcpng8.3
• gnutls: 3.3.29-9.el7_6 -> 3.3.29-10.1.xcpng8.3
• gpumon: 24.1.0-71.1.xcpng8.3 -> 24.1.0-83.2.xcpng8.3
• intel-i40e: 2.25.11-2.xcpng8.3 -> 2.25.11-4.xcpng8.3
• intel-ixgbe: 5.18.6-1.xcpng8.3 -> 6.2.5-1.xcpng8.3
• intel-microcode: 20251029-1.xcpng8.3 -> 20260115-1.xcpng8.3
• ipmitool: 1.8.18-7.el7 -> 1.8.19-11.1.xcpng8.3
• iputils: 20160308-10.el7 -> 20160308-10.1.xcpng8.3
• krb5: 1.15.1-19.el7 -> 1.15.1-22.1.xcpng8.3
• libarchive: 3.3.3-1.1.xcpng8.3 -> 3.6.1-4.1.xcpng8.3
• libevent: 2.0.21-4.el7 -> 2.0.21-4.1.xcpng8.3
• libssh2: 1.4.3-10.el7_2.1 -> 1.11.0-1.xcpng8.3
• libtpms: 0.9.6-3.xcpng8.3 -> 0.9.6-3.1.xcpng8.3
• lvm2: 7:1.02.149-18.2.1.xcpng8.3 -> 7:2.02.180-18.3.1.xcpng8.3
• mdadm: 4.0-13.el7 -> 4.2-5.xcpng8.3
• net-snmp: 1:5.7.2-52.1.xcpng8.3 -> 1:5.9.3-8.1.xcpng8.3
• openssh: 7.4p1-23.3.3.xcpng8.3 -> 9.8p1-1.2.1.xcpng8.3
• openssl: 1:1.0.2k-26.2.xcpng8.3 -> 1:3.0.9-2.0.1.3.xcpng8.3
• openvswitch: 2.17.7-2.1.xcpng8.3 -> 2.17.7-4.1.xcpng8.3
• python: 2.7.5-90.el7 -> 2.7.5-92.1.xcpng8.3
• python3: 3.6.8-18.el7 -> 3.6.8-20.xcpng8.3
• python-pycurl: 7.19.0-19.el7 -> 7.19.0-19.1.xcpng8.3
• qemu: 2:4.2.1-5.2.15.2.xcpng8.3 -> 2:4.2.1-5.2.17.1.xcpng8.3
• rsync: 3.4.1-1.1.xcpng8.3 -> 3.4.1-1.2.xcpng8.3
• samba: 4.10.16-25.2.xcpng8.3 -> 4.10.16-25.3.xcpng8.3
• sm: 3.2.12-16.1.xcpng8.3 -> 3.2.12-17.1.xcpng8.3
• ssmtp: 2.64-14.el7 -> 2.64-14.1.xcpng8.3
• stunnel: 5.60-4.xcpng8.3 -> 5.60-5.xcpng8.3
• sudo: 1.9.15-4.1.xcpng8.3 -> 1.9.15-5.1.xcpng8.3
• swtpm: 0.7.3-12.xcpng8.3 -> 0.7.3-12.1.xcpng8.3
• tcpdump: 14:4.9.2-3.el7 -> 14:4.9.2-3.1.xcpng8.3
• trousers: 0.3.14-2.el7 -> 0.3.15-11.1.xcpng8.3
• varstored: 1.2.0-3.5.xcpng8.3 -> 1.3.1-2.1.xcpng8.3
• wget: 1.14-15.el7_4.1 -> 1.21.4-1.1.xcpng8.3
• xapi: 25.33.1-2.3.xcpng8.3 -> 26.1.3-1.3.xcpng8.3
• xcp-featured: 1.1.8-3.xcpng8.3 -> 1.1.8-6.xcpng8.3
• xcp-ng-release: 8.3.0-36 -> 8.3.0-37
• xen: 4.17.5-23.2.xcpng8.3 -> 4.17.6-2.1.xcpng8.3
• xo-lite: 0.17.0-1.xcpng8.3 -> 0.19.0-1.xcpng8.3

XOSTOR:

• linstor: 1.33.1-1.el7_9
• linstor-client: 1.27.1-1.xcpng8.3
• python-linstor: 1.27.1-1.xcpng8.3
• xcp-ng-linstor: 1.2-6.xcpng8.3

Optional packages:

• iperf3: 3.9-13.1.xcpng8.3
• ldns: 1.7.0-21.1.xcpng8.3
• socat: 1.7.4.1-6.1.xcpng8.3

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

If you are using XenOrchestra's SDN controller please apply the OpenSSL upgrade procedure.

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

What to test

• XAPI tests:
  • Check that the NTP servers used by hosts are set to Factory, test changing them to DHCP, or Custom.
  • Check that the console limit is 0 by default, test changing it to 1, and set a timeout.
• System: Check updated tools (ssh, wget, samba, mdadm...)
• Normal use and anything else you want to test.

Test window before official release of the updates

~1 week

Instruction published:

https://docs.xen-orchestra.com/sdn_controller#openssl-3--sdn-upgrade-path

Any volunteer to test this along upcoming XCP-ng update ?

said in Commit 109e376 Implications:

we are currently drafting a procedure to make it the easiest possible.

FYI: https://github.com/vatesfr/xen-orchestra/pull/9525

More details to come in upcoming weekS

@Emmanuel-V said in Low end devices , share your experiences:

I wonder to which extend we could lower dom0 memory

According to:

https://wiki.xenproject.org/wiki/Tuning_Xen_for_Performance

Memory If the host has more memory than a typical laptop/desktop system, then do not rely on dom0 ballooning. Instead set the dom0 memory to be something between 1 and 4GB adding dom0_mem=1024M to the Xen command line. 1GB is enough for a pretty large...

IIRC, I couldn't go below 1.6GB (400M was reserved for VM , maybe I should try again with the above tweak to make sure)

Hi @kawreh

Thank you for looking at my commit:
https://github.com/vatesfr/xen-orchestra/pull/9507

If you are using sdn-controller, yes you will have to regenerate certificates (for XCP-ng on openssl-3), we are currently drafting a procedure to make it the easiest possible.

Thank you every visitors and for those who did not had the chance to visit fosdem check this report:

https://xcp-ng.org/blog/2026/02/19/fosdem-2026-follow-up/

One question, I promised to forward to the forum, how many VM are you running on XCP-ng ?

Dozen, hundreds, thousands or more ?

@MajorP93

Fix has been merged, expect a package in your updates soon.

Meanwhile check this notice about upcoming changes regarding remote syslog.

https://github.com/xcp-ng-rpms/xcp-ng-release/pull/41#issuecomment-3800419449