Beta CentOS 7 Xen Packages Available

Home » CentOS-Virt » Beta CentOS 7 Xen Packages Available
CentOS-Virt 25 Comments

At long last, I’d like to announce beta packages for CentOS 7, available from the community build system.

Start by installing the CentOS-release-xen:

rpm -ivh

This will set up yum repositories for both the eventual release repositories (enabled by default), and the community build system repositories (disabled by default).

At the moment, all packages will be stored in the virt-xen-44-testing repository. You can either enable this by default by editing
/etc/yum.repos.d/VirtSIG-Xen.repo, or by adding

If you want, you can edit defaults /etc/sysconfig/xen-kernel

Next, run ‘yum update’ to get the new kernel:

yum –enablerepo=virt-xen-44-testing update kernel

Now install xen:

yum –enablerepo=virt-xen-44-testing install xen

This should grab both xen and the updated kernel package. It should also automatically:
* Add default commandline parameters for Xen and Linux when booting under Xen
* Arrange for xen to come up first in the grub
* Set the default boot entry to Xen.

That’s it! Reboot and you should be good to go.

Libvirt packages aren’t available yet but should be on the way soon
(I’ll announce them here.)

Please report any problems or feedback to this list.


25 thoughts on - Beta CentOS 7 Xen Packages Available

  • Great to see Xen coming to CentOS 7 !

    I gave the virtx7-44-testing packages a spin on a fresh CentOS 7 install
    (legacy boot, no efi, as there is no xen.efi). However, I was not able to start any HVM or PVHVM guests. Upon create, the DomU was setup but did not do anything, but instead entered a reboot-loop (Dom ID was increased, but no boot output. No bootloader output on the console, despite everything in the guest setup to display on serial console). The exact same guests worked fine with Xen4CentOS xen+kernel packages for CentOS6. Note, that PV DomUs run fine (tested with CentOS5).

    I did not invest too much time into debugging, but from xl’s logs, the DomU was apparently shutdown upon creation:

    Waiting for domain xencen7 (domid 1) to die [pid 3162]
    Domain 1 has shut down, reason code 1 0x1
    Action for shutdown reason code 1 is restart Domain 1 needs to be cleaned up: destroying the domain Done. Rebooting now Waiting for domain xencen7 (domid 2) to die [pid 3162]
    Domain 2 has shut down, reason code 1 0x1
    Action for shutdown reason code 1 is restart Domain 2 needs to be cleaned up: destroying the domain Done. Rebooting now

    The interesting part is, that the pid of the xl create job (3162)
    remains the same, thus xl create never exits but instead attempt the re-create the DomU in a loop, only to be stopped by killing the xl process.

    At the moment, I run my own self-build CentOS 7 xen packages. But if desired, I can switch back to the virt7-xen-44-testing packages to assist any debugging.

    Regards, Thomas

  • Hi Thomas,

    This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried “virtx7-44-candidate”, in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.

    I am now looking for a libvirt-daemon-xen package for CentOS 7. Any ideas on where that lives?

    Thanks, Chuck

  • Thanks Jason, I had accidentally left off the “–enablerepo=virt-xen-44-candidate” from the yum install command.


  • Hi Chuck Thanks for letting me know. I actually found the “candiate” packages to work too, when tried those some days after my email. However, nowadays I build my own Xen rpm’s, based on the Fedora 21
    source package. I modified the spec-file to properly build for CentOS 7
    and adapted some of the patches of the Fedora source package.

    To me, the advantage is proper systemd intergration. It has systemd unit files for all xen-related services. Likewise, I keep the version up to date to my taste, like running 4.4.3. My xen-packages work well for me and if anybody is interested, I can polish things up a bit, setup a repo and make them accessible. That question has already been answered in this thread. Regards, Thomas

  • What we really need is to make the REAL xen RPMs .. the ones produced in this SIG .. work with systemd. These RPMs are produced by Citrix, so we need to get the right.

    So, what works and what does not work (ie, no systemd integration problem) needs to be addressed.

    We don’t want to create forked repos, IMHO.

  • First of all, I fully agree, that forked repos are undesirable. However, to the casual observer (like me), there are hardly any ressources for Xen on CentOS 7. There are some beta packages, as announced in the start if this thread, with the latest update being 4.4.2 on 4th of august. I
    have not yet found any git repo to check out the current Xen 4 CentOS 7
    development effort – only the source rpms to the above packages could be used. Likewise, the response on the list on the announcements of the Xen on CentOS 7 beta packages was kind of mute and no further updates were given. This led me to the – apparently false – assumption, that the project kind of fell asleep. I’d be more than happy to at least test development packages and give feedback.

    Your statement “These RPMs are produced by Citrix, so we need to get the right” irritates me, as I was completely unaware of any “rights” from Citrix to be waited for.

    Anyway, I will wait for the official Xen4CentOS packages for CentOS 7
    and keep my stuff out of the public to avoid useless forks.

  • So actually, the SIGs are supposed to be community efforts — and my long term hope was that once the SIG was “jump-started”, that community members would step up to take over — or at least step up to help significantly.

    A number of reasons C7 has “stalled”:

    * Lack of time on my part. I only work 4 days a week for Citrix, and I
    have significant other duties. Normally I can only spend a day or so a week on CentOS stuff; and in particular, the review load relating to the 4.6 feature freeze (beginning of July) was very high. Then I got married and went on holiday for 3 weeks in August, which also didn’t help. :-)

    * Apparent lack of testing by the community. About a month after the C7 “beta”, I was about to announce an actual release, when I happened to discover that HVM guests wouldn’t boot — not under any configuration. This is really basic core functionality that nobody at all had tested (or if they had they hadn’t complained). This convinced me that I couldn’t rely on community testing, and prompted me to spend some time writing an automated test suite that would at least do a basic smoke-test for a number of configurations. I’ve got this working for the core xen package, but I was planning on extending it to libvirt before declaring CentOS 7 “ready”.

    I’m sorry I haven’t been very pro-active about pushing to the xen package repository — I didn’t know anyone was looking. (If you asked about it, then I must have missed it.)

    I would be happy to have help improving the packages. I would be
    *very* happy to have help maintaining the Xen4CentOS packages, and I
    would be *delighted* if someone wanted to take over maintainership of the packages entirely.

    FYI I have just finished rebasing things to 4.6-rc2 (there are packages in virt7-xen-46-candidate now), and am in the process of switching things over to systemd.

    The Virt SIG has IRC meetings on freenode channel #CentOS-devel every two weeks — the next one is today (8 September) at 2pm BST (3pm UTC). If anyone wants to help contribute / see what the status of Xen4CentOS
    is, feel free to pop in.


  • Oh — you know, not sure how I completely missed this. Anyway, yes, the issue was that the original Xen packages were using the CentOS
    core version of seabios, which includes a patch which breaks Xen HVM. In -candidate I’ve built a new version of seabios, which (as you’ve seen) now works.


  • Congratulations. Its nicer cuddling a real person rather than a computer.

    BST = British Summer Time = GMT/UTC + 1:00. Thus 14:00 BST = 13:00 UTC.

  • A lot of it is market forces. A lot of people who used to run their own VM’s have basically given up, and allow AWS or similar services to do it for them. Learning a few command line tools is often a *lot*
    faster, and cheaper, than running your own virtualization infrastructure. Heck, I *published* the first public RPM’s for Xen, way back in 1997 before it was bought by Citrix, and I don’t have the time and hardware in hand to do it anymore!

    I’m also afraid a lot of us have basically given up on CentOS 7, while the developer community deals with all the multiple OS issues of the systemd reworking of network and init configuration, the-arranged
    “/bin” versus “/usr/bin” overlap of component locations, and the profound lack of EPEL for CentOS 6 or Fedora published perl and python modules ported to CentOS 7. That’s not a CentOS team issue, that’s a RHEL issue, but it’s profoundly lowering interest in both hypervisors and VM’s that are CentOS 7 based.

    And that is one of the parts that is sucking away testing time on a lot of open source or freeware projects. The systemd integration of init scripts, networking tools, and the /bin symlink to /usr/bin have been breaking a *lot* of previously stable components. A lot of us are basically giving CentOS 7 a miss until and unless the rest of the stable server community can catch up with the environment changes.

  • Just to be clear — RPMs are produced by the CentOS Virt SIG, which is meant to be an open, community-developed project. At the moment the xen maintainer happens to work for Citrix, but that’s neither here nor there.

    If there are people who feel like they want to contribute but can’t, please speak up. It takes an effort to do things “in the open”, as it were, and if I don’t know anybody’s “listening” it’s a lot easier just to do things on my own.


  • Right … I said ‘produced by’ in relation to Citrix, but I clearly meant to say ‘lead by’ instead.

    The point I am trying to make is that we (the SIG, as a community) want to produce RPMs here (in the SIG) that are of use to the community and not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.

    If we can produce the RPMs instead on the community build system where we (the SIG .. with representation from both the CentOS Project and Citrix) can sign and release the packages then users can be much more sure everything works, etc.

    For that to happen, we have to work as a group.

    Thanks, Johnny Hughes

  • what you’re doing its a complete crap, what you said is different from what you did, why you’ (CentOS virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?

  • I don’t know if you noticed, but Fedora and CentOS aren’t the same distribution. The users target different things.

    That said, it would actually be nice to be able to share a lot of the packaging effort with Fedora, if they’re willing and if it’s possible. It’s been something I’ve thought about for quite a while.

    If you have any concrete suggestions, feel free to share them.


  • Because we want to have source code that works on both CentOS-6 (based on RHEL 6 Source, which was based on Fedora 12) and CentOS-7 (based on RHEL 7 Sources, which was based on Fedora 18/19).

    So, the source code for Fedora 22 will not work with both of those. We DID start with the Fedora 12 version of the RPMs, that worked with CentOS-6 and we have rolled in kernels from the LTS tree for stability, etc.

    We have been producing a CentOS-6 version for several year now. We now need to make that work with CentOS-7. It is not just as simple as taking Fedora code, that is always latest and greatest and recompiling it. If it was, RHEL (and therefore CentOS) would have no need to exist at all. Everyone could just use Fedora for everything.

  • FIrstly CentOS is primarily a RHEL clone. This means that the primary design decisions are to be as RHEL like as possible. After that there are additions and upgrades.

    Secondly Fedora does not actively support Xen. As a long time Xen and RH/Fedora user I have spent lots of time building/rebuilding broken/missing packages in Fedora. Quite frankly Xen under Fedora is somewhat broken. Libvirt support for KVM is very good because RH pays people to support KVM. Xen under the old config format has reasonable support(possibly 60% of features) but under libxl the support is much worse (possibly 30% of features).

    Thirdly RedHat has been active at times to remove Xen support in favour of KVM(Their own virtualization technology). Xen has been driven to some extents by the needs of Citrix and although they have helped others build packages for Fedora and libvirt its a good will effort and its hard to expect Citrix to spend effort on work that may not be in their best corporate interests.

  • Nonsense. Have you done ‘yum install xen’ ?

    It is? Please open bugs and CC me on them (

    Please file bugs so we can figure out which ones are missing.

    Not sure I follow as Fedora does not make this distinction.

  • Sorry. I mis-spoke there. I should have said RedHad does not actively support Xen.

    CPU features/flags are just outright is not there. I tend to run into the problems as I am trying to use Xen for my development environment. I have posted fixes and bugs in the past and will in the future. But Xen/CentOS does not have a big dedicated development or a small one for that matter. So Xen development will lag a bit. This is not a criticism but just a fact of life.

    When I fight my way through my current provisioning environment I will be likely posting more bugs. I have to admit that I am not the best contributor because often I just fix the bugs. Partly because being outside the community learning all the nuances of posting fixes is way more effort than just fixing them.

    As of the last time I checked you could not build a RedHat 7 kernel with Xen enabled. The point to be made is that Fedora is not RHEL and CentOS is more like RHEL.

    So comparing CentOS to Fedora is like complaining that RHEL should support all the current Fedora packages/features. There is a relationship between all of them but they are not the same.

  • See my comments inline as appropriate Cool. Good to know. Well, while I have been using CentOS for several years now in both private and professional setups, I have to admit, that so far I did not delve into the community itself and make myself familiar with its processes and procedures. It might be time to change that :)
    Well, first of all congrats to your recent marriage! I know what your were up to lately, as I did the same some 6+ years ago. And much like you, I have to dedicate my personal free-time to any effort. On the plus side, I am a sysadmin actually using Xen4CentOS on top of CentOS 6 in a professional production environment, spanning 50
    virtualisation hosts and running over 600 VMs (over 1,500 pCPUs over
    10Tbytes RAM). So I get pretty much of an impression, what it means to actually use Xen4CentOS. You already found out in another post, that I actually did test the CentOS 7 packages early in july and reported to the list. That lack of any response on my report triggered me to do Xen 4 on CentOS7 packages myself. See above. Well, I’d be happy to help. I can easily test things out on my private setup, which is all geared towards Xen and virtualisation anyway, so I
    am all setup. To actually contribute, I would ideally like some git-repo to checkout, to prep patches against. Those patches, I could send to you for review. If there is some process aligned to “the CentOS way of doing things”, I would need a pointer to some docs to make myself familiar with. As I have not the faintest clue about what it takes to actually maintain a package, i am – at least now – the inappropriate person. Yeah, saw that yesterday in the repo. Ok then, I will fetch it soon and start testing it in one of my CentOS-7 Xen guests (I run nested-Xen). If that test succeeds, I could update the host. That way, these packages would get some real-world test, running my zoo of guests. Oviously, I’ll report my findings. I would propose to see, if that yields anything useful to the development of the Xen4CentOS 7 packages. To actually look into code, I’ll fetch the source-packages of that repo. I popped in late, close to closure of the meeting. I resorted to readonly, as I wanted to grasp the “style” and scope of the things communicated. Unfortunately, being located in Germany means, that this time collides with my work-hours and if I can allocate some time to attend remains to be seen. Regards, Thomas

  • Excellent!

    Please open bugs for these issues. The CPU features/flags is an important feature that needs to be properly addressed in libxl toolstack. Right now it is a bit of a trainwreck.


    I would say that is the best contributor!

    Oh, .. I must be missing something here. Posting fixes seems like an excellent way of removing the issues you had found by them not reappearing in the future?

    Odd. I thought you could. The only one missing was the PV framebuffer +
    intial domain support but the rest were enabled. And that initial domain support was due to them mucking with Kconfig to outright disable it.