XCP-ng: Current Project State
Turnkey Community Powered Hypervisor based on Xen
Originally a XenServer fork, now more than that!
1 / 12
CEO/founder of Vates (2012)
Linux/FreeBSD guy (former sysadmin)
Xen Orchestra and XCP-ng founder
XCP-ng website: https://xcp-ng.org
2 / 12
2018: 1 year of XCP-ng
: Kickstarter, funded at 700%
: First release (7.4)
: 7.5 with new exclusive features (eg: initial ZFS support)
: Pro support available (https://xcp-ng.com)
: 7.6, all repo/RPMs GPG signed, soft RAID support
3 / 12
Still easy to upgrade from XenServer (keeping all VMs, settings etc.), 100% API compatible.
No license, no feature restrictions, only support-based business model.
Fully /RPM based for updates.
1k+ forum contributors (6k+ posts!)
18k unique downloads
member of Xen Security pre-disclosure list
working on being a Linux Foundation Project (nothing official yet!)
getting closer to the upstream (Xen, Linux, CentOS)
4 / 12
10+ upstream bug fixed (including security issues) ✔
"testing" repo available (more recent kernel, extra drivers…) ✔
signed Windows PV drivers ✔
CloudStack compatibility ✔
compression support (almost ready)
5 / 12
2019: what's next
growing the "on-site" (Vates) dedicated team (up to 6 people)
already working with 3 major academic labs (Paris, Grenoble & Nice universities)
all of those labs already published a lot on Xen
searching actively for other EU universities/labs with Xen knowledge
total team size: (researchers/engineers/contractors)
joint effort with multiple companies (in various fields: hosting, finance, research…)
new companies are always welcome!
6 / 12
Research and development
general perfs improvements
new FS with new storage stack: ZFS, Ceph…
better backup perfs and architecture
VLAN across pools (replacing closed source and Citrix DCVS)
better Xen scheduler
general perfs improvements
All of this backed by academic publications (rigorous benchmarks, data available).
7 / 12
Example: NVMe/Optane near bare-metal perfs
Current issue: NVMe drive IOPS limited by CPU due to "legacy" storage design.
Objective: going from 10% to 90% of bare-metal IOPS!
Solution: removing layers. How?
"emulate" NVMe drives inside the guest
"slice" the real drive
polling model (less interrupts: not CPU bound anymore)
"General" architecture validated with Xen devs. Next phase: proof of concept + benchmark
8 / 12
automated build/CI platform
Koji (automated RPM build)
advanced mirror management
mirrors all around the world
everything GPG signed (secure)
advanced Ceph/ZFS support
improved compression for all operations
9 / 12
In the meantime, on XO side
Reminder: Xen Orchestra is the "management" stack for XCP-ng (even XenServer). It's like
both "vSphere client" and "vCenter server" (XCP-ng would be ESXi)
basic admin tasks (migrating, patching hosts…)
backup (forward incremental delta, replication…)
resource delegation (but far less cloud oriented than CloudStack obviously)
VM cloud backup (off-site)
backup proxies (optimized to backup from various locations)
new UI to be ultra fast even on large infrastructures (4000+ VMs)
10 / 12
How to help XCP-ng project?
contribution via the community (forum/IRC)
joining as a partner in an European research project (https://www.eurostars-
eureka.eu/): public funding!
helping on QA with hardware and/or DC space
getting pro support ;)
Contact us: firstname.lastname@example.org
11 / 12