CentOS virt - Dec 2013 - Fwd: Building Xen on RHEL7

-------- Original Message --------
Subject: Building Xen on RHEL7
Date: Thu, 19 Dec 2013 18:57:22 +0000
From: Wei Liu <wei.liu2 at citrix.com>
To: <centos-virt at 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?