Since its inception, the Xen Orchestra project which uses AGPLv3, always had a philosophy to listen and engage the community. User feedback shaped our initial concept, which first targeted system administrators. Eventually, our users drove us to support cloud-scale deployments supporting up to 2000 VM's. Retaining simplicity in usage and installation, while evolving Xen Orchestra to cloud scale posed many challenges. This led us to build many new features such ACLs, self-service, live charts, config drive management, and more, forced us to constantly evolve our architecture. First we will show how user needs changed our architecture, and how we implemented challenging problems such as user permissions, ACLs, Containers in a virtualized infrastructure and self service. We will conclude with a short demo, what is next and a lessons learned.

1. Xen Orchestra
Building a Cloudon top ofXen
1 / 27

2. Introduction
At first
an easy to use administration tool (10s of VMs)
Today
still an administration tool (100s to 1000s of VMs) ;)
self service portal
backup solution
basic load balancer
Tomorrow
more and more a simple cloud solution
easy-to-use API to manage Xen Servers
advanced load balancer
2 / 27

3. 3 / 27

4. History
2009
Initially created by Olivier as a student for personal use
Based on xend
Static pages generated by PHP
2013
Still no nice and easy Web UIs for XenServer
Restarted in 2013 for internal use
Still generating much interest from the community
Initial server written in PHP
4 / 27

5. History (2)
Mid 2013
Server rewritten using Node
Initial single-page web application (based on Backbone.js then Angular.js)
2014
Not as much things as we wanted because not much time dedicated to the
project!
→ Need to focus!
5 / 27

6. History (3)
2015
We are working exclusively on XO!
2016
UI entirely rewritten for performance and ease of use for big infrastructures
(2000+ VMs)
6 / 27

7. 7 / 27

8. 8 / 27

9. 9 / 27

10. 10 / 27

11. Architecture
Above pools
11 / 27

12. Architecture (2)
Centralized server
less connections
cached data
shared authentication
no Xen Servers directly exposed
12 / 27

13. 13 / 27

14. 14 / 27

15. You saidCloud?
Bring people a way to enjoy cloud-like features with their own hardware,
without complexity:
no complicated stuff to install on hosts (stay agent-less)
leverage our current XO architecture (no need to rewrite everything)
bottom to top approach, ie start small and add features step by step
(opposite of OpenStack)
Features
ACLs (users/groups permissions)
Self Service
CloudInit
15 / 27

16. ACLs
First step toward the cloud: permissions!
Let users/devs make actions on their VMs:
can only see VM state (viewer)
power cycle (operator)
remove (admin)
avoid devs to ask for things they can do themselves
sell your ressources to your customers
16 / 27

17. 17 / 27

18. Selfservice: going further
Create a set of resources (max CPUs, RAM, disks, etc.)
Assign this set to a group/user
Let them play with it
18 / 27

19. 19 / 27

20. Cloud-Init (1)
Cloud-init is the defacto multi-distribution package that handles early
initialization of a cloud instance.
https://cloudinit.readthedocs.io/en/latest/
How to?
1. Create a template where you install Cloud-init software
(apt/yum/whatever)
2. Remove all root/user password
3. Transform your VM into a template
20 / 27

21. Cloud-Init (2)
VM creation for Cloud-init templates
During next boot, Cloud-init will:
read the configuration passed by XOA
apply it
21 / 27

22. Cloud-Init (3)
Possibities
deploy SSH keys and host name
install software on boot (Apache, MySQL...)
inject software configuration
add extra repo, certificates, execute commands on boot, phone home
when ready...
mount points
extend root partition size (if disk bigger than current FS)
XO + Cloud-Init allows you to deploy generic but versatile templates in
less than 20 secs
22 / 27

23. Quick recap (1)
Before
As an admin, everytime:
1. Install a VM (OS install, VM settings)
2. SSH into it with root/sudoer
3. Create basic configuration (automated or not)
4. Give your developer an IP address to SSH on
As a developer:
1. Break your VM
2. Call your sysadmin
3. Wait for a manual operation (reboot/reinstall/whatever)
4. Go back to 1
23 / 27

24. Quick recap (2)
Now
As an admin, after creating a set of ressource and the right templates:
1. Nothing
As a developer:
1. Break your VM
2. Remove it and recreate it in 20 secs
24 / 27

25. Future possibilities
IP (manual) management with VIF locking (almost done)
expose CloudInit templates directly in XO (with a public registry?)
DHCP/DNS connectors (network automation)
integrate XO with CI services (eg Jenkins) or Vagrant for devs
25 / 27

26. Conclusion
XO architecture and Xen + XAPI allows powerful features
combining XO Cloud features turns your own Xen hardware into a private
cloud
still some improvements possible
In real life:
Current usage for XO in a "local Cloud":
VPS vendors (selling resources)
companies with various devs teams (especially when Docker
involved)
26 / 27

27. Thank you!
Questions?
Twitter: @xenorchestra
IRC: #xen-orchestra (FreeNode)
27 / 27