Presentation on theme: "VIRTUALIZATION Xen and the Art of Virtualization"— Presentation transcript:
1 VIRTUALIZATION Xen and the Art of Virtualization Are Virtual Machine Monitors Microkernels Done Right?Presented by Brett Fernandes
2 Problems with Other Architectures MicrokernelsPoor Performanceoverhead from IPCChange the ABIMust forfeit all available software for the systemMonolithic kernel in disguise?Failure conditions of external pagersExokernelsNo application multiplexingNo place for the untrustworthy!
3 Virtual Machines to the rescue? Excellent PerformanceAchieved through ParavirtualizationRetain the same ABIsAll required architectural features are virtualizedInternal Paging by each VMApplication multiplexing is everythingEach guest OS can multiplex applications securelyThe untrustworthy are welcomeStrong resource isolation between VMs
4 VMs - The resurgence rather than the emergence An old idea - IBM 370 in 1972.A Virtual Machine Time-Sharing System (Meyer and Seawright) described the CP-67/CMS – the first virtual machine.Newer ventures:Vmware ESX Server (2001) - successor of DiscoThe Denali project (2001) - coined the term paravirtualizationSun’s VirtualBox (2008)Microsoft released Hyper-V (2008)Xen is the most widely used by far – available as open source but now owned by Citrix Inc.
5 Xen and the Art of Virtualization Paul BarhamMicrosoft Research, UKNemesis OS (QoS for I/O and virtual memory)Rolf NeugebauerIntel Research, Cambridge, UKBoris DragovicXenoServer Team (Cambridge 2002), LinSec – Linux Security SystemKeir Fraser, Steven Hand, Tim Harris, Alex Ho, Ian PrattCambridge University, UKAndrew WarfieldUniversity of British Columbia
6 Introduction Challenges to build virtual machines Performance isolationScheduling priorityMemory demandNetwork trafficDisk accessesSupport for various OS platformsSmall performance overhead
7 Xen Principles Unmodified Application Binaries No change to applications requiredFull multi-application OS supportSupport for XenoLinux and ongoing work on Windows XP and BSDParavirtualizationHigh performanceResource IsolationAllows malicious users without harming other VMsPartial view of physical resources provided
8 Xen: Approach and Overview Multiplexes resources at the granularity of an entire OSAs opposed to process-level multiplexingPrice: higher overheadTarget: 100 virtual OSs per machineDenali supported over a thousand
9 Xen: Approach and Overview Conventional approach - Full virtualizationVirtual hardware is functionally identical to underlying machineVirtualizing the entire instruction setNo view of physical resourcesProblematic for certain privileged instructionsFailed silently rather than trappingShadow structuresVmware traps every update page table eventNo real time availableHosted OS not modified
10 Xen: Approach and Overview New approach - paravirtualizationVirtual hardware is similar, not identical to the underlying hardwarePartial view of the underlying hardwareNo modification of applicationsVMs handle pagingNo shadow tables requiredReal, virtual and clock time providedNeed modifications to the OSporting to Xen for every version of every OS
11 System Control Mechanism Separation of policy and mechanismDomain0 hosts the application-level management softwareCreation and deletionof virtual networkinterfaces and blockdevices
12 System Control Mechanism Control Transfer: Hypercalls and EventsHypercall: synchronous calls from a domain to XenAnalogous to system callsEvents: asynchronous notifications from Xen to domainsReplace device interrupts
13 CPU Design X86 supports 4 levels of privileges 0 for OS, and 3 for applicationsXen downgrades the privilege of OSesSystem-call and page-fault handlers registered to Xen“fast handlers” for most exceptions, Xen isn’t involved
14 CPU Implementation Borrowed virtual time scheduling Allows temporary violations of fair sharing to favor recently-woken domainsGoal: reduce wake-up latency
15 Time and Timers Xen provides each guest OS with Real time (since machine boot)Virtual time (time spent for execution)Wall-clock timeEach guest OS can program a pair of alarm timersReal timeVirtual time
16 Memory Design The conventional easier approach: Software managed TLB Associate address space IDs with TLB tagsAllow coexistence of OSesAvoid TLB flushing across OS boundaries
17 Memory Design X86 does not have software managed TLB Xen exists at the top 64MB of every address spaceAvoid TLB flushing when an guest OS enters/exits XenEach OS can only map to memory it ownsWrites are validated by Xen
18 Physical Memory Implementation Reserved at domain creation timesMemory statically partitioned among domainsXenoLinux’s balloon driverDoes not guarantee contiguous allocation of memory
19 Virtual Address Translation No shadow pages (VMWare)Xen provides constrained but direct MMU updatesAll guest OSes have read-only accesses to page tablesUpdates are batched into a single hypercall
20 Device I/O Design Xen exposes a set of simple device abstractions Allows an efficient interface which provides protection and isolationI/O data transfer between domains via Xen
22 Disk Access Implementation Only Domain0 has direct access to disksOther domains need to use virtual block devicesUse the I/O ringReorder requests prior to enqueuing them on the ringIf permitted, Xen will also reorder requests to improve performanceUse DMA (zero copy)
23 Network Virtual firewall-router attached to all domains Round-robin packet schedulerTo send a packet, enqueue a buffer descriptor into the transmit ringUse scatter-gather DMA (no packet copying)A domain needs to exchange page frame to avoid copyingPage-aligned buffering
24 The Cost of Porting an OS to Xen Architecture Independent (78 lines)Virtual Block Device driver (1070 lines)Virtual Network driver (484 lines)Xen specific (1363 lines)< 2% of code-base
25 Evaluation Against other virtualization techniques Vmware, User Mode Linux(UML)Single Native OS vs Virtual MachineRunning multiple applications on a native OS vs a guest OSPerformance Isolation between Guest OSsOverhead of running large number of OSs
26 Relative Performance SPEC INT2000 score SPEC WEB99 CPU Intensive Little I/O and OS interactionSPEC WEB99180Mb/s TCP trafficDisk read-write on 2GB dataset
27 O.S BenchmarksContext switching times – extra overhead due to hypercall required to change the page table base.
28 Concurrent Virtual Machines Multiple Apache processes in Linuxvs.One Apache process in each guest OS
29 Performance Isolation 4 Domains2 running benchmarks1 running dd1 running a fork bomb in the background2 antisocial domains contributed only 4% performance degradation
31 IssuesExtra effort is required to port every version of every OS to XenDemonstrated by the ‘ongoing effort’ to port Windows XP and BSDRunning a full OS is more taxing in terms of resource consumptionThe requirement of every privileged instruction being validated by Xen results in performance overheadDifficult to implement on an architecture with only 2 privilege levels
32 Discussion/Takeaways Main achievement – performance.Completely outperformed Vmware in almost all benchmarksIdentified potential problems and took steps to minimize themEg Fast exception handler for system callsOS level multiplexingSolved the problem of performance isolation that plagued traditional OS techniquesInnovative approach to TLBAllocation of top 64MB to Xen avoids TLB flushes
33 Are Virtual Machine Monitor Microkernels Done Right? Steven Hand, Keir Fraser, Evangelos KotsovinosCambridge University, UKAndrew WarfieldUniversity of British ColumbiaDan MagenheimerHP labs, Fort CollinsWrote the first PA-RISC simulatorDeveloped Vblades, the first Itanium VMM
34 Sparking the Debate Mendel Rosenblum’s claim VMMs are microkernels done rightCommon system goalsMicrokernels – Academia vs VMMs - Industry
35 Microkernels – Noble Idealism Communication orientedA smaller OS core is easier to maintain, validate and portArchitecturally better than monolithic kernels
36 VMMs – Rough Pragmatism Strong resource isolationMain concern is reducing overhead due to extra layerSupport execution of out-of-the-box applicationsWhere do Exokernels stand?
37 Architectural Lessons Liability inversionExternal pagers in microkernels vs Parallax using VMs for storageIPC PerformanceMinimum communication between VMsDecoupling of control and data path operationsOS as a ComponentMicrokernels forfeit the software availableVMMs appeal to developers because of a familiar environment
38 Discussion Very biased view of the debate Possibly due to several of the authors working on XenFocused on microkernel flaws and how VMMs were the answer(almost certainly) Knowingly chose to refer to certain aspects of VMMs ambiguouslyMicrokernels and VMMs appear to be more related rather than significantly different.