Experimental update of CentOS packages
-
tl;dr: we need you to test a spin of XCP-ng with updated CentOS packages
As you probably know, XenServer and XCP-ng are built on top of CentOS. Approximately 75% of the dom0 system is made of packages from CentOS 7.
Most of those packages haven't been updated since XenServer 7.0 was released. The reason for this is probably this: packages that don't change don't bring new bugs. And it's understandable: we all like stability and hate regressions.
However, XCP-ng has an objective of being as close as possible from upstream CentOS. We don't know yet how close we can be, but we think we can be closer than what we are right now.
So I spent several days studying the packages from CentOS, looking at their changelogs, and we finally decided to make an experimental repository in which we would update all the packages that we could, shake vigorously, and see that comes out of this. This repository is now ready. We don't know what the outcome of this experiment will be, but it will for sure help us understand the system and probably allow us to get closer to upstream CentOS sooner or later.
Now we need the most adventurous among you to test it. Not in production, of course!
How to test
On top of an existing XCP-ng 7.6:
wget https://updates.xcp-ng.org/tmp/centos-update/xcp-ng-7.6.repo -O /etc/yum.repos.d/xcp-ng.repo yum clean metadata yum update reboot
Then the game starts: if you find a regression, you win! If you help find why, you double win (... our gratitude )!
If you're in, please say so in this thread, tell us what kind of setup you'll be able to test, and make sure to watch the thread and activate mail notifications if needed to stay informed of future findings and updates.
The packages are synced with CentOS 7.5 for now, but CentOS 7.6 has been released so expect another update.
-
Update: I've removed the updated
rsyslog
package due to ordering cycle issues between its systemd unit and openvswitch. -
Interesting, would you add packages like apcupsd?? I could use a standard PC to install it and do some test, we only have a production pool and few money
-
Adding new packages is not the primary objective here but updating most packages to latest CentOS would clearly help do it.
-
Hi.
What is the purpose of leaving XCP-ng closer to CentOS 7.5 ~ 7.6?Ah... great job guys
-
Fixing CVE on non-updated packages of CentOS 7.2 in XCP-ng (like
openssh-server
or other critical CVEs onsamba
) -
How XCP-ng keep tracking of rebuild due to updated of dependency? That means if A requires B, and B is updated. How XCP-np decides whether and when to rebuild A?
-
Red Hat (and thus CentOS) tries not to make changes to libraries that would then require rebuilding other packages, so usually there's no need to rebuild packages in cascade when updating packages from CentOS 7.
Otherwise we've got the build dependencies in source RPMs.
-
Updating one of my test servers now. (Dell R610)
If all goes well, I will update another test server (Dell R620) later this week.
-
So far I have run into one issue. When I force a live migration the VM I migrate gets stuck at 99% and sits there. I let it sit overnight to see if it would go through, but it didn't .
When attempting to cancel the migration it left a copy of the VM frozen on each host. When attempting to reboot/shutdown or even force reboot/shutdown I would get an error saying they did not exist.
Rebooting the hosts fixed the this issue, but left me with a full copy of the VMs on each host. I was also unable to reboot the host I migrated the VM from unless I used the xsconsole window. XCP-NG Center did not work.
If I get time today I will roll back the R610 to 7.6 and see if I have the same results.
Here are a few photos: https://imgur.com/a/wYw6AdL
Other than this edge case issue, everything seems to be working fine so far!
-
The live migration issue may, or not, be related to this: https://xcp-ng.org/forum/topic/522/unable-to-migrate-live-vms-after-upgrading-from-xcp-ng-7-4-to-7-5/
-
Do you have any suggestions for me to try to help see if this is related?
-
Yes, you could install
emu-manager
from XenServer 7.6 (present on their installation ISO) and see if live migration works better (note that reproducing the issue may depend on VM load or other factors, so if it does migrate well, try several times to confirm the result).Once you've got the RPM:
rpm -e --nodeps xcp-emu-manager yum install emu-manager-version_and_such.rpm xe-toolstack-restart # may not be needed but doesn't hurt
-
This fixed the issue for a few migrations. The latest one put the VM into a suspended mode and then disconnected me from the host. I restarted the tool-stack on each host and when I went to reconnect to the host I was migrating the VM from it would let me in for a moment and then kick me out again and it was in a maintence mode according to the icon. To resolve this I rebooted the host. I'm currently seeing if I can replicate this behavior.
Other than this I haven't run into any issues so far.
Let me know if there is anything specific you would like tested.
-
i know this topic is old, but is this still going on? I would like to participate.
-
Problem is considered solved now.
-
Since I started this topic, XCP-ng version 8.0 came with updated CentOS packages (to CentOS 7.5). Now the versions remain stable but I'm regularly checking CentOS security updates for important updates that may be necessary to us.
-
@stormi I have a doubt, you say that XCP-ng 8.0 comes with packages updated to CentOS 7.5 plus some custom package like kernel.
If I update the host via yum it goes to the latest CentOS 7.x version plus latest updates, I'm right?
I don't see any yum settings that keep it stuck to 7.5.
I mean, the updates repo have this source:
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
and $releasever = 7 widhtout any minor release specification, so I assume an update takes my base OS to the latest minor plus updates. -
@nackstein If you update to latest CentOS you probably basically just break your system. The CentOS repos are not active by default on purpose. We let them as a convenience for those who really really need to (and understand the risk) to cherry-pick additional software that we don't offer in our own repos.
-