-------- Original Message -------- Subject: Building Xen on RHEL7 Date: Thu, 19 Dec 2013 18:57:22 +0000 From: Wei Liu wei.liu2@citrix.com To: centos-virt@centos.org
Hi all
This is a record of how I build Xen on RHEL 7. Hope this is helpful for people who want to package Xen for the upcoming CentOS 7. Basically it's not too much hassle to build Xen on RHEL 7. I'm in no way a packaging expert on RPM-based systems so I just list what's needed.
The Yum repo I'm using is the public beta mirror at https://mirrors.fedoraproject.org/publiclist/RHEL/7/x86_64/. I cloned Xen tree from git://xenbits.xen.org/xen.git and used master branch.
Dependences and requirements are listed by components.
# To make top level ./configure pass: yum install -y gcc python-devel acpica-tools libuuid-devel ncurses-devel glib2-devel libaio-devel yajl-devel zlib-devel
I also need to install dev86. I downloaded the latest version from http://www.debath.co.uk/dev86/ and installed it by hand. I noticed there's a dev86 package in Xen4Centos repo. We should be able to reuse that.
And we also need to do ln -s /lib64/libcrypto.so.1.0.1e /lib64/libcrypto.so otherwise configure complains it cannot find libcrypto while that library is actually there.
There's no markdown library in existing yum repo so some documents won't be built but that's not critical.
And optionally if you want to use oxenstored: yum install -y ocaml
# To build tools: ## To build hvmloader: yum install -y glibc-devel.i686
## To build qemu-xen-traditional yum install -y SDL-devel
## To build qemu-xen-upstream yum install -y pixman-devel
# To build stubdom yum install -y texinfo
By now you should be able to just run "./configure; make dist" in top level Xen source code directory without getting any error (hopefully). There's warnings though because gcc 4.8 has stricter check than previous versions.
I didn't build blktap, as RHEL 7 uses 3.10 kernel and Xen now has upstream QEMU, which should be able to cover all use cases. However default kernel only has frontend supports enabled (built as module), so we might need to alter its config or supply alternative Dom0 kernel.
Have fun and Merry Christmas.
Wei.
My first thought on seeing this thread was "Is there some reason to compile from source, rather than from an SRPM, say those at http://dev.centos.org/centos/6/xen-c6/SRPMS/ ?"
I went ahead and grabbed RHEL 7 beta from http://ftp.redhat.com/pub/redhat/rhel/beta/7/, where the actual bootable iso's and accessible yum epository actually live, without the burdensome RHEL registration process. I understand there are benefits to registering a temporary license, just to be able to submit your reports to the registered channels, but *sheesh*. The "you must permit our friends to spam you to register for a beta is nasty, which is why I dug around for that http://ftp.redhat.com/pub/redhat/rhel/beta/7 direct access. And it's a *lot* easier to use that website for installation, or setting up a local mirror, than to register with RHEL on this particular project. I love RHEL service and support pricing, aand their software attitudes, I use them along with CentOS and Scientific Linux for various projects, but their registratioin for this project scared me of becuase of the "let us spam you" agreeement required for registration.
After trying to build the SRPM's on RHEL 7 Beta myself I found that the current CentOS Xen publisned SRPM's are quite good. And I say this as the guy who first published SRPM's for Xen, while I was working for the BBC some years back. I'd use the SRPM's over a source download and compilation in a heartbeat. Unfortunately, they don't build on RHEL 7 Beta yet, but it looks like that's a compiler change problem, not an SRPM problem per se. For any of the CentOS Xen project developers here, they're good: Just grab the SRPM's and build up the toolchan in the new environment.
But trying to build from the SRPM's resolved all the build dependency, including satisfying the requirement for the openssl-devel and dev86 dependencies that you encountered. And the dev86 SRPM's published there worked well, with the caveat that it did not have a "gcc" dependencies, which I've added to a .spec file, and the .spec file for dev86 and for Xen both have badly formatted dates in the "%changelog" stanza. RHEL 7 is much less tolerant of this than RHEL 6 was. Again, I've edited some .spec files and will try to submit some patches if I can fiind time.
Once I'd satisfied all the dependencies for the SRPM, I was able to build the Xen 4.3.1 tarball pretty easily. It just didn't work well to plug the tarball into the old SRPM and .spec file. A whole stack of the patches have already been incorporated, such as almost all of the xsa patches, and other patches that were designed to optimize RHEL/CentOS compilation just fail to install on the new codebase. Updating to Xen 4.3.1 is its own whole project, on RHEL 7 or CentOs 6, one I don't have time for myself and wish the project maintainers great success with.
But with all that said: why are you bothering with Xen when RHEL and thus CentOS have KVM support built right in? Is there some feature you require that isn't available in the built-in KVM support?
On 12/22/2013 04:33 PM, Nico Kadel-Garcia wrote:
My first thought on seeing this thread was "Is there some reason to compile from source, rather than from an SRPM, say those at http://dev.centos.org/centos/6/xen-c6/SRPMS/ ?"
My thinking is that the sources from F19 would be better since RHEL7 is based on F19 they would be a lot closer to RHEL7 than the CentOS 6 Xen sources, although both would probably build with no modifications at all.
One thing that the parent didn't mention is where he got the dom0 kernel from. The best place would be just to rebuild the RHEL7 kernel with Xen dom0 support enabled. It is possible that libvirt would need to be rebuilt with Xen support enabled as well, and as I said above, everything else (the Xen tools and hypervisor) could be gotten from Fedora 19.
with the caveat that it did not have a "gcc" dependencies, which I've added to a .spec file,
gcc is considered to be part of the standard build toolset and as such is not required to be listed as a dependency in any spec file.
and the .spec file for dev86 and for Xen both have badly formatted dates in the "%changelog" stanza. RHEL 7 is much less tolerant of this than RHEL 6 was. Again, I've edited some .spec files and will try to submit some patches if I can fiind time.
The F19 spec files should be fully compliant with the EL7 guidelines.
Once I'd satisfied all the dependencies for the SRPM, I was able to build the Xen 4.3.1 tarball pretty easily. It just didn't work well to plug the tarball into the old SRPM and .spec file.
Admittedly F19 comes with Xen 4.2.3, rawhide comes with 4.3.1, though, and can probably be directly rebuilt for EL7 without any fuss.
But with all that said: why are you bothering with Xen when RHEL and thus CentOS have KVM support built right in? Is there some feature you require that isn't available in the built-in KVM support?
Some people like Xen, people like a choice, and it's not all that difficult to add Xen to EL7 anyways. There's no reason to exclude it just because upstream made a political decision.
Peter
On Sun, Dec 22, 2013 at 1:30 AM, Peter peter@pajamian.dhs.org wrote:
On 12/22/2013 04:33 PM, Nico Kadel-Garcia wrote:
My first thought on seeing this thread was "Is there some reason to compile from source, rather than from an SRPM, say those at http://dev.centos.org/centos/6/xen-c6/SRPMS/ ?"
My thinking is that the sources from F19 would be better since RHEL7 is based on F19 they would be a lot closer to RHEL7 than the CentOS 6 Xen sources, although both would probably build with no modifications at all.
That's fair., and a good point. However, the CentOS 6 tools did have some issues, as mentioned below..
with the caveat that it did not have a "gcc" dependencies, which I've added to a .spec file,
gcc is considered to be part of the standard build toolset and as such is not required to be listed as a dependency in any spec file.
Part of a standard build toolset or not, it needs to be mentioned. The dev86 SRPM was pretty old, admittedly. But Fedora, and EPEL, and RHEL, all build their RPM's with "mock" and "koji" these days, and gcc is *not* part of the basic build environment. There are reasons, having to do with cross-compilation and alternative compiler toolchains. So RHEL, Fedora, and EPEL RPM's all specify "cc" or "gcc" as needed,
Do take a good look at those Fedora SRPM's if you think I'm kidding..
and the .spec file for dev86 and for Xen both have badly formatted dates in the "%changelog" stanza. RHEL 7 is much less tolerant of this than RHEL 6 was. Again, I've edited some .spec files and will try to submit some patches if I can fiind time.
The F19 spec files should be fully compliant with the EL7 guidelines.
Quite right, and good point. For the ctntos-virt world, I partly thought I'd work from the centos-xen published tools. Again, you make a good point..
Once I'd satisfied all the dependencies for the SRPM, I was able to build the Xen 4.3.1 tarball pretty easily. It just didn't work well to plug the tarball into the old SRPM and .spec file.
Admittedly F19 comes with Xen 4.2.3, rawhide comes with 4.3.1, though, and can probably be directly rebuilt for EL7 without any fuss.
But with all that said: why are you bothering with Xen when RHEL and thus CentOS have KVM support built right in? Is there some feature you require that isn't available in the built-in KVM support?
Some people like Xen, people like a choice, and it's not all that difficult to add Xen to EL7 anyways. There's no reason to exclude it just because upstream made a political decision.
Sure. But don't make a choice just to make a different choice, and I' didn't suggest excluding it. I was just asking why someone who was unfamilar with RPM building was burning their cycles building from scratch. I do it myself, but don't recommend it when there are tools already availble. And you hd a *very* good point about working with the Fedora tools!
On 12/22/2013 08:32 PM, Nico Kadel-Garcia wrote:
On Sun, Dec 22, 2013 at 1:30 AM, Peter peter@pajamian.dhs.org wrote:
gcc is considered to be part of the standard build toolset and as such is not required to be listed as a dependency in any spec file.
Part of a standard build toolset or not, it needs to be mentioned. The dev86 SRPM was pretty old, admittedly. But Fedora, and EPEL, and RHEL, all build their RPM's with "mock" and "koji" these days, and gcc is *not* part of the basic build environment. There are reasons, having to do with cross-compilation and alternative compiler toolchains. So RHEL, Fedora, and EPEL RPM's all specify "cc" or "gcc" as needed,
Do take a good look at those Fedora SRPM's if you think I'm kidding..
I did check before I made the comment in the first place (this is for el6 from epel buildsys-build is the standard install for mock epel-6): $ yum groupinfo buildsys-build
...
Group: Buildsystem building group Mandatory Packages:
...
gcc gcc-c++
...
Peter
Peter wrote:
On 12/22/2013 08:32 PM, Nico Kadel-Garcia wrote:
On Sun, Dec 22, 2013 at 1:30 AM, Peter peter@pajamian.dhs.org wrote:
gcc is considered to be part of the standard build toolset and as such is not required to be listed as a dependency in any spec file.
Part of a standard build toolset or not, it needs to be mentioned. The dev86 SRPM was pretty old, admittedly. But Fedora, and EPEL, and RHEL, all build their RPM's with "mock" and "koji" these days, and gcc is *not* part of the basic build environment. There are reasons, having to do with cross-compilation and alternative compiler toolchains. So RHEL, Fedora, and EPEL RPM's all specify "cc" or "gcc" as needed,
Do take a good look at those Fedora SRPM's if you think I'm kidding..
I did check before I made the comment in the first place (this is for el6 from epel buildsys-build is the standard install for mock epel-6): $ yum groupinfo buildsys-build
...
Group: Buildsystem building group Mandatory Packages:
...
gcc gcc-c++
...
Additionally, the Fedora Packaging Guidlines list these as exceptions which are not to be added as BuildRequires:
https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2
On Dec 22, 2013, at 2:32 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:
But with all that said: why are you bothering with Xen when RHEL and thus CentOS have KVM support built right in? Is there some feature you require that isn't available in the built-in KVM support?
Some people like Xen, people like a choice, and it's not all that difficult to add Xen to EL7 anyways. There's no reason to exclude it just because upstream made a political decision.
Sure. But don't make a choice just to make a different choice, and I' didn't suggest excluding it. I was just asking why someone who was unfamilar with RPM building was burning their cycles building from scratch. I do it myself, but don't recommend it when there are tools already availble. And you hd a *very* good point about working with the Fedora tools!
Hi Nico,
Wei, the OP, is a member of the Xen core dev team, and was just providing an experience report on building Xen from source on RHEL 7 to assist anyone who was interested in packaging it for RHEL/CentOS 7. I’m replying for him because since KB forwarded the original message to the list himself, I assume that Wei isn’t subscribed.
Thanks to both of you for your reports on building Xen from F19 and Rawhide!
Mike
-
Karanbir Singh -
Mike McClurg -
Nico Kadel-Garcia -
Peter -
Todd Zullinger