Containers vs Others Xen, VMware, etc. ● Emulation/paravirtualization ● Can run different OSs on the same box ● Lower density/scalability ● OS sprawl problem ● Lower performance ● Single OS per box ● Higher density ● Dynamic resource management, best scalability ● No performance overhead

OpenVZ vs. Xen from HP labs ● For all the configuration and workloads we have tested, Xen incurs higher virtualization overhead than OpenVZ does ● For all the cases tested, the virtualization overhead observed in OpenVZ is limited, and can be neglected in many scenarios ● Xen systems becomes overloaded when hosting four instances of RUBiS, while the OpenVZ system should be able to host at least six without being overloaded

3 Usage Scenarios ● Server Consolidation ● High Availability ● Dynamic Load Balancing in a Cluster ● Hosting ● Development and Testing ● Security ● Educational

Mainstream kernel integration ● Collaborative community effort: – OpenVZ, IBM (Metacluster, live migration), Google (Paul Menage, containers), Eric Biederman (namespaces, high availability), Oren Laadan (Zap, live migration), etc... ● Current progress (as of linux ): – IPC namespace – utsname() virtualization – PID namespace – user namespace – cgroups (control groups) – Memory controllers (RSS, page cache) – Networking namespace ● More to come soon!

5 CT #1 Migration at a Glance Physical Server #1Physical Server #2 CT Private Data CT Memory CT#1 Container's file system transfer Save full container's state to a file Container is running on Server #1 Full State Dump Restart container on Server #2 CT #1 CT Memory CT Private Data

To sum it up ● Platform-independent – as long as Linux support it, we support it ● No problems with scalability or disk I/O – lots of memory, lots of CPUs no prob – native I/O speed ● Best possible performance ● Plays well with others (Xen, KVM, VMware)