I just noticed that yum install xen does not pull in the xen kernel on c7, is this by design ?
From George’s original email, I had to:
* Install CentOS-release-xen from CentOS-extras
Then a yum update followed by a yum install xen.
That worked for me…
Scot P. Floess RHCT (Certificate Number 605010084735240)
Chief Architect FlossWare http://sourceforge.net/projects/flossware
i had to do something similar, but my question is – one cant run xen without the kernel, so why not have the xen package require the xen kernel as a prereq ?
You can run Xen on any Xen dom0-enabled kernel. While the stock CentOS
kernel does not qualify as such there are kernels available for CentOS
other than the Xen4CentOS kernel which do, such as kernel-ml from elrepo. To require the Xen4CentOS kernel would cause issues if someone wanted to use a different dom0-enabled kernel.
Hit the send key before actually typing anything :(
Was going to say – ah OK didn’t understand your original question. I’m not entirely sure – I just followed directions :) However, you ask a reasonable question.
IMHO, the best way to solve this would a additional line in the spec-file:
“Provide: kernel-dom0” for those kernel that are provide this functionality.
Then the xen-packages could “Require: kernel-dom0”
no matter which way the kernel functionality came to be.
Maybe ask even across distros for such a implemention, to get a more coherent experience for xen.
Have a nice weekend,
The issue there is you can’t expect every third-part kernel vendor to add that provide. Many of them won’t even realize that their kernel is dom0 capable because any kernel from 3.0 and up is by default (Red Hat went to lengths to actually rip this functionality out of their kernels). So by doing this you still end up forcing people who want to use other legitimate kernels to jump through a lot more hoops.
I think a better way would be to create a group that includes xen and the kernel (and possibly other things) and have the installation instructions install the group instead of individual packages. It becomes much easier to replace individual packages (or simply not install them) without breaking deps for yum that way.
yeah, the CentOS-5 and 6 Xen stacks already do something similar – which is why I was expecting the CentOS 7 one to do that as well. Let me work this with George and see where he thinks.
Everyone who cared to should have done in the last 8 odd years the xen stack has been available on CentOS – beyond that, we should build a good local story and ensure other vendors have the opportunity to come along.
You seem to be arguing for a broken story for some third party corner case,
We have a local kernel, built for purpose, tested for purpose, and used within the ecosystem by other efforts that require or provide a xen interface, lets just stick with trying to make that better.
besides, there is nothing stopping users from later installing whatever other keys they want. Pretty sure a majority of the userbase wont.
AFAICS, a simple “Requires: kernel >= 3.18” in the xen package should be enough, at least for the CentOS ecosystem… although I think that elrepo’s kernels, on purpose, do not provide “kernel” but “‘kernel-ml”.
Actually… kernel-ml provides both ‘kernel’ and ‘kernel-ml’. Providing
‘kernel’ is necessary so it is installed, not updated, by yum.
The same is true with the CentOS-plus kernel for CentOS-7.
I mostly took the packages as I got them; and for C6, “yum install xen” always just grabbed the newer kernel automatically; but this was apparently because of the version, not because of any advertised capability it provided.
This seems like a good idea. If anyone wants to send pull requests to https://github.com/CentOS-virt7/xen and https://github.com/CentOS-virt7/xen-kernel implementing the change I’ll be happy to merge them. Otherwise I’ll put it on my to-do list.
I just looked at the Fedora xen package, and it doesn’t seem to have any requirement of that sort. I think most distro kernels just have Xen enabled by default, because it’s a lot harder to support two packages than just have it enabled all the time. RH is the odd one out to have it disabled entirely.
you would still need to do yum upgrade to get the new libvirt and seabios bits to support xen, so I don’t see why also relying on that for the kernel is any more a problem.