XenServer 7.3: and now, what's next?

  • 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

  • @olivierlambert How many of this stuff you have to build using the xenserver-build-env? eg: xen-xapi, xcp-networkd, etc...
    before you have yourself a full XenServer?

  • Is it possible to just take the XenServer source CD and rebuild XenServer as-is, with no modification?

  • I created a page with the multiple phases required: https://xcp-ng.github.io/

    It's a rough estimation, but still giving you an idea.

  • Can I inject a few other thoughts into the organization process?

    It seems like at this point, we're doing a lot of thinking around what exactly we have to start with, and where we want to go with it. I'm glad you put together the rough roadmap, @olivierlambert , I think it makes sense given what I've seen so far.

    Can we put in that roadmap a few organizational milestones? I think to give this project a chance at long term success, we'll have to put some effort into thinking about who would be using this new distro, and how we can target the project deliverables to meet our needs as well as a larger community. Since we're in the early days here, I know we don't want to spend too much time thinking about that as YAGNI, but I want to make sure that if you're trying to build an organization around a community that we have the appropriate goals specified at the level we need them to continue to make it attractive to contributors and have something in place to help guide the direction of these critical early efforts.

    Case in point -- I believe we're relying a lot on what a for-profit company, Citrix, is putting out. How dependent do we want to stay on them? Look at OpenSolaris -- something built mostly on open bits but never reaching the point of 100% openness before Oracle bought it and immediately killed it. To my mind, we should probably consider and discuss the ramifications of the ownership of source before too long as you/we continue to attract talent and efforts.

    One other question while I'm at it -- I'm fine with organizing all of the effort and work around Github, and accepting you, @olivierlambert as the lead with majority control for now on technical decisions as you are the one doing the lions share of the work. That's the model I'll share with others going forward until such a point that we collectively decide on what kind of model should replace that, if any. I believe the Linux Kernel organizational model is what I'm suggesting I see for the interim until we reach the first or second of your milestones. Does that make sense?

    Last question -- I'm a total Java/C++ application and enterprise architecture guy. I'm comfortable with functional programming (Kotlin/Scala/Erlang), but OCaml is new to me. So is RPM building, although I understand most of the concepts involved. Where can I best help? I don't mind doing some grunt work here and there, and I'm just as happy doing non-coding tasks if that is most helpful in the beginning.

Log in to reply