XenServer 7.3: and now, what's next?

  • 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.

  • Will the Phase 1 install from ISO option allow for upgrading existing installations of XS7?

  • The "long term" goal is obviously to be 100% independent and keep a public "how to" build it process documented. That's the main trick in the Open Source world today: you can find almost everything you need, but the pain point is in the glue/QA/integration (this is how we do our living in Xen Orchestra open source business for example).

    But before getting there, we must learn "how it works". I have a general knowledge on the pieces, but nobody outside Citrix get enough knowledge to do the whole thing.

    Luckily, we have the help (with compensation, we'll pay him because we must get his talent now) of an ex-XAPI developer that could assist in the right direction for removing the feature check thing in short term. This is the first step, which will be started next week.

    The major issue would be to manage the "whole picture": what's needed inside a XS, what are the "pinned" dependencies, what is our room for innovation/using extra libs etc.

    That's why, IMHO, the best path is to go from the XenServer ISO, extracting the RPMs (done here: https://cloud.vates.fr/index.php/s/L01f4oWE2qajs3Q ) and try 2 things in parallel:

    • modify the ISO to make it "XCP-ng" like (as soon we got the XAPI package modified) -> remove XenServer name and Citrix proprietary things
    • start from CentOS and use the XS packages to be able to make CentOS -> XCP-ng

    Those 2 routes must be correctly documented to help everyone to understand how XS works, and to use this to be able to be independent in the future.

Log in to reply