OSv presentation from Linux Foundation Collaboration Summit

1. OSV Avi Kivity, Don Marti Cloudius Systems @CloudiusSystems

2. Typical Cloud Stack Hardware Hypervisor OS JVM App Server Your App OS JVM App Server Your App OS JVM App Server Your App

3. Our software stack congealed into existence.

4. Too Many Layers, Too Little Value Property/Component Hardware abstraction Isolation Resource virtualization Backward compatibility Security Memory management I/O stack Configuration VMM OS runtime Duplication

5. Transformed the enterprise from physical2virtual Virtualization Virtualization 1.0 Virtualization 2.0 Compute node virtual server Virtualization 2.0, Massive Scale Scalability

6. Virtualization 2.0 vServer OS 1.0Architecture ● No Hardware ● No Users ● One app/guest ● Yes Complexity

7. The new Cloud Stack - OSv Hardware Hypervisor Core App Server Your App Single Process Kernel space only Linked to existing JVMs App sees no change Core Your App

8. The new Cloud Stack - OSv Memory Huge pages, Heap vs Sys I/O Zero copy, full aio, batching Scheduling Lock free, low latency Tuning Out of the box, auto CPU Low cost ctx, Direct signals,..

9. Alpha Release 3/2014 Optimized ZFS cache Dirty page writeback JVM page table HV support: GCE, VMW, VBox Milestones Git init osv, 12/2012 Java hello world, 01/2013 support for 64 vcpu 02/2013 UDP, 03/2013 ZFS support > 1Gbps netperf, 6/2013 Cassandra outperforms Linux, 8/2013 Native REST API Memcached gain > 70% 1/2014 Cli and web interface 9/2013 Tomcat, HAProxy modules 10/2013 Net channels JVM ballooning >47Gbps netperf 2/2014 Image Repository JVM Read barrier elimination DPDK support More ...

10. Memcached benchmark Requests/s (higher is better)

11. Integrating the JVM into the kernel Core JVM Application Server Your AppDynamic Heap Memory TCP in the JVM + App context Fast inter thread wakeup

12. JVM Garbage Collection and the kernel Application thread (“mutator”) Garbage collection thread JVM Object JVM Object ref

13. JVM Garbage Collection Application thread (“mutator”) Garbage collection thread JVM Object JVM Object JVM Object ref change

14. JVM Garbage Collection Application thread (“mutator”) Garbage collection thread JVM Object JVM Object JVM Object ref scan change

15. JVM Garbage Collection Application thread (“mutator”) Garbage collection thread JVM Object JVM Object JVM Object ref scan write change card table read

16. JVM Garbage Collection Application thread (“mutator”) Garbage collection thread JVM Object JVM Object JVM Object ref scan change page table read hardware update

17. Van Jacobson == TCP/IP Common kernel network stack Leads to servo-loop:

18. Van Jacobson == TCP/IP Net Channel design:

19. Dynamic heap, sharing is good JVM Memory System memory Lend memory

20. OS that doesn’t get in the way 4 VMs per sys admin ratio http://www.computerworld.com.au/article/352635/there_best_practice_server_system_administrator_ratio_/ NO Tuning NO State NO Patching

21. Virtualization 2.0: Stateless servers

22. REST API definition use Swagger REST api for *any* action

23. Performance and tracing

24. Porting a JVM application to OSV 1. Done* * well, unless the application fork()s

25. Porting a C application to OSV 1. Must be a single-process application 2. May not fork() or exec() 3. Rebuild as a shared object (.so) 4. Other API limitations apply* * Post to the list, and missing items are usually added quickly.

26. ● JVM-based application ○ No effort ● Traditional C/C++ application ○ More effort ● Virtio-app ○ NFV - highest gain Different customization levels

27. ● First OS to be written in C++11 ● Interrupt handler using lambda function: _msi.easy_register({ { 0, [&] { _rxq.vqueue->disable_interrupts(); }, poll_task}, { 1, [&] { _txq.vqueue->disable_interrupts(); }, nullptr } }); OSv == Cool

28. So what about containers?

29. Capstan demo

30. ● Docker is awesome! Low overhead! ○ Small artifacts ○ Fast deployment ○ Fast startup (container start, not OS boot) ● Docker is awesome! Easy builds! ○ Simple configuration file ○ Minimal additional work on top of application build Docker is awesome

31. Containers under the hood ● Hypervisors are awesome too! ○ Live migration (load balance, hardware maint) ○ Multiple kernel versions available ● Running VMs everywhere is awesome! ○ Public cloud, private cloud, existing hypervisor... ● Security is awesome! ○ Container attack surface is full kernel interface. ○ Hypervisor attack surface is small. ● Sometimes a hypervisor is already there (private and public clouds) Hypervisors are awesome

32. Everything is awesome What if we could have advantages of Docker without limitations of containers? ● Fast boot, fast provisioning ● High performance ● Tiny footprint ● Virtualized ○ Live migration ○ Elasticity ○ MMU access

33. Capstan ● Check out a base image ● Build application ● Create complete run-anywhere VM ○ No Capstan needed in production ● 12-20MB and 3 seconds of overhead ● All driven by one simple config file ● Low overhead of containers with deployment flexibility of a VM image.

34. Let’s Collaborate

35. http://osv.io https://github.com/cloudius-systems/osv @CloudiusSystems osv-dev@googlegroups.com OSv @Cloudius

36. Backup slides

37. Virtualization 2.0, Dev/Ops

38. Virtualization 2.0, agility! Rolling upgrade within seconds and a fall back option

39. Cloudius Systems, OS Comparison Feature/Property Good for: Typical workload kernel vs app API, compatibility # Config files Tuning Upgrade/state OSv Machete: Cloud/Virtualization Single app * VMs Cooperation JVM, POSIX 0 Auto Stateless, just boots JVM support Lines of code License Tailored GC/STW solution Fewer BSD Traditional OS Swiss knife: anything goes Multiple apps/users, utilities, anything distrust Any, but versions/releases.. 1000 Manual, requires certifications Complex, needs snapshots, hope.. Yet another app Gazillion GPL / proprietary

40. Be the best OS powering virtual machines in the cloud Mission statement Hardware Hypervisor OSv Your App Hardware Hypervisor OSv + Jazz JVM Your App Hardware Hypervisor OSv + Jazz JVM Hardware Hypervisor OSv Hardware Hypervisor OSv + Jazz JVM Your App

41. Application upload

42. ● Going idle is much more expensive on virtual machines ● So are inter-processor interrupts - IPIs ● Combine the two: ○ Before going idle, announce it via shared memory ○ Delay going idle ○ In the meanwhile, poll for wakeup requests from other processors ● Result: wakeups are faster, both for the processor waking, and for the wakee Idle-time polling

43. OSv applicable for Virtualization Application server Virtual appliance PaaS Cloud Vendors

44. Plan 1. Open Source Launch - Done 2. Harden Virtual Appliances - Doing 3. Q4 2014 GA by Cloud vendors - Doing 4. OEM (cloud/appliance), Enterprise