XenServer 7.3: and now, what's next?

    1. KVM: it will require to make almost entirely our own stack to get something close to XAPI
    2. XAPI with Xen = XCP/XenServer.

    edit: I'm not closing any possibility, just taking a look/digging around

  • you know I'm onboard 🙂

  • I had a public discussion with XS PM (David), maybe it will change a bit the XAPI situation. It seems (need to confirm) all the other tools are more easy to build. So the first task would be like to gather what's needed to transfor a CentOS to a XenServer host.

  • Hi Olivier,

    The transformation is a long story, you can compile and build the xapi but you will be stucked to the specific versions of the RPM's means that you need to be somehow connected with the development team to find which versions of software to build and also there is a huge problem with the license tool, by default the xapi will need license configuration, either you fake it or not.

    I have a huge respect to you and your team, you are doing a great job, I would humbly advise you for an alternative hypervisor, you will be more free and the things that you build with your team will not be affected by some strange copmany decisions. You seem to be locked in to Xapi but Believe me there is always a good thing in such kind of bad decisions,

    From my perspective opensource Xen and KVM are the only two hypervisors that can be used and without xapi Xen has no meaning, would be better to use libvirt, you need to check how bound your code is to xapi and is is simple to use libvirt instead of that..



  • Hi @senol and thanks for your contribution.

    In fact, XAPI is tagged with specific release version that we could use for each "stable build". Regarding licenses check, it's pretty easy to get rid of that on a parallel fork. In fact, the easiest thing to do, is not to change the edition of XS, but stay in free and just change the features flag (eg change to "Positive" instead of "Negative").

    This way, you are still in Free edition (no license check) but enjoying the features.

    Obviously, the big problem right now is how to build those RPMs.

    Anyway, if this leads to nowhere, we'll should adapt to something else. But right now, adapting to another toolstack (regardless the hypervisor) would cost far more than making XAPI build from the sources.

  • Hi Olivier,

    yesterday I tried to compile the xenserver-core from the stable branch with no success, xcp-sm is not compiled, I manage to create 114MB of RPM. As I mention in my previous comment, we can make it run,

    github xen-api page tells that we should use xenserver-core to build the RPM packages, most of them compiled without any problem via xenserver-core build process. is there any info that you can share, I think I can manage to compile all the packages, and afterwards I can create an installation repo for that.

  • From which repo you tried to do it exactly? I was working on XAPI repo directly. But I failed to build it (tried xenserver-buildroot and their Docker thing to create the right build env). But some hardcoded URLs are internal to Citrix.

    Ideally, we should be able to build all the dependencies, put them in a RPM repo, and go from a CentOS with Xen to a "XCP"-like.

  • Hi @olivierlambert

    I am also talking about the same place, as they suggest I used xenserver-core, but I did not use docker, I think since they have many other dependencies they are also not using docker environment to build their stuff. the problem is their dependency versions, I did not have time to check but I will check this evening and let you know what package is the one that causes the problem..
    0_1513856644731_Screen Shot 2017-12-21 at 12.42.54.png

  • xenserver-core repository is no more on GitHub. I think they replaced it by buildroot repository (this one).

    The issue with buildroot repo is that's not maintained anymore since a while (last commit is from 2 years ago!).

  • Citrix should come forth with a statement about ether their willingness to make XS really open or not. This halfway situation isn't beneficial for anyone. As it stands, it's a nightmare to try to build a full XS instance from scratch. All it would take is some careful documentation as to all the specific steps and perhaps some additional work to automate this. After all, Citrix does internal automated daily builds and testing of XenServer so they obviously have the know-how!

  • Yes, it can't be black magic. Especially with the great tools we got today. Let's see if they answer this request and how 🙂

  • Okay with xenserver-build-env (here), it seems I'm able to build XAPI (ie: to make executable, not the RPMs yet, this is another process):

    git clone git://github.com/xenserver/xenserver-build-env
    cd xenserver-build-env
    ./run.py -p xapi --rm
    # --- you are now inside the docker container ---
    git clone git://github.com/xapi-project/xen-api
    cd xen-api

    To build xcp-networkd, same principle:

    ./run.py -p xcp-networkd --rm
    # --- you are now inside the docker container ---
    git clone https://github.com/xapi-project/xcp-networkd.git
    cd xcp-networkd

    And you got the binaries.

  • Works without the project portion -- https://github.com/xcp-ng

  • Maybe the project thing is hidden? IDK why. I'll check permissions.

  • @dustinb3403 Amazon is now using KVM, Nutanix is using KVM, allot of companies that have virtualized products is using KVM. But Xen-Orchestra uses XAPI, not libvirt. Would it not be good to have XAPI & Libvirt, plus others so that your product can control other hypervisors?

  • @olivierlambert Don't you need other GitHub project to use the build-env?
    like: https://github.com/xenserver/planex and https://github.com/xenserver/upload-scripts

Log in to reply