Q: What changed in Xen 7.3 that made you want to do this?
A: This is a long story… First you need to understand a bit the context. Xen is just the hypervisor, a project hosted in the Linux Foundation (see https://www.xenproject.org/about/the-linux-foundation.html). Xen alone is pretty light, with a small API and almost stateless. Which is great if you are a big vendor able to build exactly what you need around it (think AWS in the Cloud, or Xen in the automotive industry for example). You can compare Xen and KVM. After installing KVM for example, you'll probably need to install another layer to administrate them (eg Libvirt+virsh, or other particular vendor toolstack on top, like ProxMox or whatever). Because both Xen and KVM are made to offer a small/lightweight "interface" by default. Again, which is good: an hypervisor just doing what we expect from it.
But in the everyday server virtualization world -as "on premise"-, it's normal to prefer more turnkey solutions. That's what XenServer is: a turnkey distribution with everything you need to use it as-is, and a powerful API (XAPI, also a Linux Foundation project by the way).
In other words, you are able to go from your physical hardware to a fully manageable and feature rich hypervisor in few minutes. That's because Xenserver and its API are able to handle everything for you (VLAN management, storage creation and more), always using the API which is the first class citizen! For example, all XenServer management tools, from the CLI with xe to XenCenter (Windows client) or Xen Orchestra (web client), even OpenStack!
So, let me rewrite the question:
Q. What changed in XenServer 7.3 that made you want to do this?
Citrix release XenServer as Open Source back in 2013 (see the original announcement here: https://www.citrix.com/blogs/2013/06/25/xenserver-6-2-is-now-fully-open-source/). Basically, you can download it for free, and pay for support to be backed. Plus some extra "turnkey" features only in the paid edition (eg "wizard" features in the Windows client, but no limitation on API level whatsoever). This is the "traditional" Open Source model, which is great!
Before it was open source, there was an Open Source equivalent of Xenserver, called "XCP", standing for "Xen Cloud Platform". You can see that as a kind of "CentOS" of RedHat if you like (ie: a unsupported distro, but a working build anyway).
Anyway, after XenServer was Open Source, XCP didn't had a point anymore: why still using something like this if XenServeer is free? Also, the project had a cost for Citrix devs. And because they didn't made enough momentum to get community involved, the project died when they decided to stop it. I would say this is pretty normal. But without really knowing it, XenServer users were now completely Citrix-dependent, because no developer community existed outside Citrix.
Let's fast-forward in December 2017: Citrix now announced XenServer 7.3, with some previous free features removed, like:
- Xen storage motion
- Dynamic memory control
- GPU passthrough
- Pool size limited to 3 hosts
- HA
- amongst other things, check my blog post for details: https://xen-orchestra.com/blog/xenserver-7-3/
Also, previous versions of XenServer won't receive patches anymore, except if you take a license (they made an exception for Meltdown/Spectre patches for XenServer 7.2! But all new patches, even security ones, won't be available: you'll "forced" to go to 7.3 and get less features).
From the start, I liked the idea of XCP, ie a "free" build, documented and not affiliated to one company. Sadly, the community wasn't really well developed, especially because of the announce of Open Source XenServer, happening too soon to build enough momentum.
So, it's all about the money? No. This announce just removed some obstacles to make people decide to get things done by themselves. If you get something free and turnkey without any effort, I think you can accept there is only one contributor (Citrix) which is not releasing any documentation to build it from the sources. But you take a risk, a bet on the future. If they decide to go in a specific direction which is not yours, then you'll have to take control back.
And that's exactly what happened: Citrix is big company, with their own agenda (we can't blame them for that!), which is mainly "virtual desktop" and even more "cloud oriented" recently. Indeed, XenServer is meant to work well with their flagship product (XenApp/XenDesktop). It means they have less interest in server virtualization.
Maybe it makes sense for them, but not for me, nor a large bunch of our users (we are the editor of xen-orchestra.com, a complete web solution for XenServer, ie management, backup and cloud features like VM delegation etc.). We have a nice base of customers AND community users. Since we announced the idea of making XCP-ng project back, we had a lot of support from them. To be fair, more than I even expected. Thousands of people are willing to help us, one way or another. But we want to do this correctly: we want to do it together.
Q: Why do you think XCP-ng is needed?
A: XCP-ng is needed for multiple reasons. First one is to -at least- create a dynamic community around it, with multiple partners, individual or companies. This is the best way to get a sane ecosystem, without fearing that your agenda is not the same of one player. This is how Open Source work. And that's needed, especially since the announce, I can clearly see it's not just me!
Then, a healthy community would be able to provide a lot of input regarding issues and even how to solve them. Because we want to document the entire build process,as the dev process, people will be able to test various settings easily, to pinpoint bottlenecks or add new features.
Next, the build will allow all XenServer features, even those restricted usually in Free edition. This will drive innovation for product sitting on top of it. Think about VM introspection (security), easy vGPU migration/management (AI computation) and many more. You can see XCP-ng as an innovation enabler: from your small lab to bigger infrastructures, you'll have the turnkey solution without any restrictions! I think this is still needed today.
Finally, it also demonstrates that not everyone want to go to the public cloud for various reasons, like avoiding unknown neighbors on the same hardware (Spectre is a good recent illustration) but not just because of that. I know it sounds weird to say this today, but I can tell that the support behind XCP-ng is a good proof of it. Hypervisors are still needed, and in a more turnkey way than ever.
Q: Would you say this is a fork of Xen?
No. Not even a "hard fork" of XenServer really. I mean, in the end, XenServer is a collection of different packages, from CentOS to XAPI (XenServer API) project. The initial goal would be to keep things pretty close to the original product. So, technically it's a fork of some components inside XenServer. Then, we'll iterate, maybe the fork will grow bigger or maybe our patches will be merged. This is hard to predict, but remember that the objective is to get something that "just works", without any limits on the way you use it. Most of the work will be XAPI related. Ideally, the XAPI "mainline" repository should be agnostic (not affiliated to any company, no license check etc.), and then companies should be able to add their own sauce to make the commercial thing. Like the Linux kernel for example. But we know it's not an easy job, and we aren't asking anything to Citrix.
Q: What do you hope will be the benefits of XCP-ng?
Somehow, I think I already answered on "why it's needed". In short, having a solution that's made for everyone who want to use server virtualization, with all the possible benefits, without the pain (turnkey) and all of this in a Open Source way, without only one company behind it.
But if you have questions on this part, please let me know :)
Q: Have you been able to raise any funds?
We will. And we want to do it transparently: we'll do a crowdfunding campaign in the next weeks (you can register your email here to be notified: https://mailchi.mp/3bc90e48d2f7/xcp-ng), and then manage this money publicly. We'll track all the expenses regarding the project on the GitHub organization/repositories, eg to pay the team we are gathering, mainly former XAPI/XenServer developers, to bootstrap the project. Like delivering the first testable release, write the build documentation and so on. More money will mean more potential and independence for XCP-ng. And a bright future.
So what now? Our fist goal is to federate other companies and individuals into the project (we just started and it goes well!). Because we want this project to be 100% community oriented, diversity is inherently welcome.
- @xcpng on Twitter
- #xcp-ng on Freenode
- https://xcp-ng.github.io/