XenServer 7.3: and now, what's next?
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 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.
Storycrafter last edited by Storycrafter
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.
Danp last edited by
Will the Phase 1 install from ISO option allow for upgrading existing installations of XS7?
olivierlambert last edited by olivierlambert
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.
Also we need people to work on XenServer DDKs to be able to create our own. This is really important to be able to build our kernel modules (eg: ZFS).
Stril last edited by
What I do not really understand is how the "periphery" things about Xenserver could be working in XCP-ng:
- XenTools: Do we need to have XCP-ng-tools, or how can we have drivers for different OSs?
- XenCenter: Do you think, there will be a compatibility between XCP-ng and Xencenter, or will XOA be the one and only frontend?
- Migration XCP-ng <-> Xenserver: How about the compatibility here? Will it be possible to migrate VMs from Xenserver 7.x to XCP-ng without downtime as "Live Storage Migration?
Thank you and best wishes
- Xentools should be quite identical. We'll packages them without any modifications I think
- We'll keep the exact same API. So if Citrix doesn't block it (ie do nothing special about it), XenCenter will stay compatible too.
- I think this could work because modification will be minor. But I can't be certain until first release.
kudzu_kdk last edited by kudzu_kdk
@olivierlambert AD2. Maybe you can take a look at OpenXenManager (python version of XenCenter on linux) ? I think it's frozen project (sources are available on github) but it works - I know because I've used it for awhile. That will make a good alternative for someone who wants a non-web client, not only for one platform as it is with XenCenter and it will be compatible with XCP-ng
You can imagine I won't spend time developing/improving another client
Yes, if you want, use OpenXenManager, it will likely work with XCP-ng, (I don't see why it wouldn't).
kudzu_kdk last edited by
@olivierlambert I can imagine you're busy atm I just wanted to mention that there is a client based on XenCenter if Citrix'd decide to do something with their product I'm satisfied with XO but there is a problem with it (or maybe I'm blind :)) There's no option to add a Hardware HBA (iSCSI only) as it is in XenCenter. But other than that XO is enough well done
Please post there to keep pressure on us We don't have HBA hardware in the lab, so it's harder to build the feature out of thin air
Stril last edited by
I am looking forward to see features that will outperform "original" Xenserver.
The biggest day-by-day-limitations for me are:
- Snapshots on LVM doubles the needed space
-> Thin-Provisioned-LVM would be great!
-> alternatively: NFS 4.1 with multipathing
nicols last edited by
Citrix Xencenter 7.4 show message "unlicensed" when connected to free (citrix) xenserver 7.x
Will this change with XCP-ng?
olivierlambert last edited by olivierlambert
Again, I can't tell for XenCenter behavior. Note we don't touch XenCenter, but XenServer.
If Citrix decide to lock features from their UI, then switch to Xen Orchestra or something else.
edit: let me do a quick test right now
It seems to be OK (not displaying license issues). But expect a reaction from Citrix to change that in the future