On Thu, Aug 2, 2018 at 11:58 AM T.Weyergraf T.Weyergraf@virtfinity.de wrote:

Hi

Thanks for providing updated Packages, they are much appreciated. At work, we are currently running an entire production infrastructure on Xen4CentOS, with quite some success.

We are looking into a refresh towards CentOS 7 along with newer Xen and Dom0 Kernel packages. However, even the updated packages are quite old. Xen 4.8 is out of active support since June and will see the end of security support in less than a year. Likewise, a newer LTS kernel (4.14) exists for quite some time, while the Xen4CentOS effort currently uses 4.9.

Re Xen, our ideal goal is to always be running the most recently-released even-numbered point release; i.e., I would ideally like to be on 4.10 now, and probably be on 4.12 as soon as 4.12.1 comes out. But Anthony and I are normal developers with lots of stuff to do, so we get to it when we can. Pull requests make improvements happen much faster. : -)

Regarding Linux, I don't personally have any preference; historically the sense was that CentOS users liked "old stodgy and boring", and so staying on the oldest possible kernel to pick up the latest bug fixes *without* picking up the latest bugs was seen as the thing to do. We might make an exception to get PVH. Did you have an alternate suggestion for the community to consider?

Are there any short to mid-term plans to bump both versions to more current ones (i.e.: 4.10 and 4.14)? Currently, our update-tests are based on 4.10 candidate packages with kernel 4.9. Given the support timelines, I'd rather prefer 4.10 over 4.8. A change in Xen versions has been never successfully performed using live-migration between versions, so a reboot of more or less our entire infrastructure is required. Something you would not consider light-hearted.

Supporting any -> any live migration is a testing load that upstream Xen doesn't have yet. If that's important, you might consider one of the paid-for options, like XenServer.

As a side note, is there anything reasonable, people like me could to, to support the speed-up of that process? I would consider testing to be important, but are there any regression test-suites, one could use? I am aware, there are such tests, but I have not found something to actually try in our test-infrastructure.

There are three general things that need testing: 1) Xen core virtualization 1a) Xen / CentOS package usability 2) CentOS packaging (making sure installs / updates work, &c) 3) Kernel testing -- device driver bugs, &c

#1 is generally taken care of pretty well by upstream testing at this point, so doesn't need any coverage.

#1a of course is something that is difficult for upstream developers to do, because we're too close things, and because we don't do everything our users do.

#2 is something that we really should get into a CI somewhere; but generally a combination of ad-hoc and community testing seems to work OK.

#3 is something that it's not really possible for anyone to do other than a company with massive amounts of dedicated resources and an HCL; we really rely on our users to test their own hardware and report / help track down issues.

So, probably the best thing is to help test out new kernels on your own hardware whenever you can; and also give feedback / suggestions on the usability of the software and packages that we can feed in to improve the process.

Finally a big shout-out and kudos to the Xen community and Xen4CentOS. Your work is used and much appreciated.

Thanks! Glad to know it's useful. :-)

-George