Musings about virtualizaon and the future of OS research. Orran Krieger A bit of history 1990 1994 1997 2001 2007 Tornado Toronto Hurricane IBM K42 Rhype Xen Libra VMware VMware Hive Disco Stanford Outline • Virtualizaon will be pervasive • Why does a 1960s technology make sense? • New uses of virtualizaon: – Applicaon distribuon – Ulity compung – The OS of the future Outline • Virtualizaon will be pervasive • Why does a 1960s technology make sense? • New uses of virtualizaon: – Applicaon distribuon – Ulity compung – The OS of the future Virtual is beer than physical Suspend Log Resume Snapshot VMM VMM Clone Migrate Record Replay etc. Virtualizaon will be pervasive • As of this year IBM, HP, Dell, FSC, NEC support new embedded hypervisor on x86 systems, although not yet pervasive • IBM has shipped on z/p/I for years, Sun & HP shipping on non x86 HW. – Gives HW vendor place to deploy funcon – Gives much simpler out‐of‐the box experience – Long term… virtualizaon will be pervasive on all plaorms. • Requires fundamental changes. Its got to get on a diet 98% 2% Agent … Agent RPM RHEL3‐based Service Console Helpers VMM VMM VMM VMkernel Storage Networking Resource Management HAL and Device Drivers Disk Footprint: 2 GB Disk Footprint: 32 MB Percent of Patches >50% Its got to get on a diet 98% 2% Agent … Agent RPM RHEL3‐based Service Console Helpers VMM VMM VMM VMkernel Storage Networking Resource Management HAL and Device Drivers Disk Footprint: 2 GB Disk Footprint: 32 MB Percent of Patches >50% Other requirements • Support all requirements that HW might be used for: – Determinisc real me – High assurance – Embedded, Client & server • We will need to move to much more customizable design, where plaorm depends on the modules installed. Outline • Virtualizaon will be pervasive • Why does a 1960s technology make sense? • New uses of virtualizaon: – Applicaon distribuon – Ulity compung – The OS of the future How can virtualizaon be important? • Virtualizaon invented to allow OS development on massive mainframes. – Allowed HW and OS developers to work independently: everyone else had ght coupling, new OS for each HW plaorm – Allowed new stacks to be deployed & tested by customer. • Why is this technology important in a world of cheap scale‐out commodity computers? – Much of the original value for HW virtualizaon subsumed by virtualizaon levels in and above OS. Modern OS Evoluon • Commodity OSes had enormous pressure to add funcon to support new applicaons. APP APP APP APP APP APP APP APP APP APP APP • Security and reliability secondary APP APP APP APP APP APP APP concern in the broad market, ‐> APP APP APP feature creep… • The rich funcon of general purpose Applicaon Support OS became necessary for servers… Hardware Mgmt. • Problems — Too complex > Security > Reliability > Manageability > Performance > Innovaon The research community failed • Research community developed alternaves: – Microkernels – Exokernels – Customizable OSes … • No innovave technology could get sufficient funcon to build up massive user base: – User had to dedicate HW to the special purpose OS: new innovaon needs to be free to get community – Had to support large complex HW • Exisng OSes too complex to allow incremental innovaon What virtualizaon gives us • A stable interface that the rich funcon of commodity OSes runs above. • Allows new technology to be deployed alongside or underneath commodity OSes. – Zero cost to deploy innovaon, if it solves a problem, great! – HW complexity disappears, way easier to develop new OS. • “Any problem in computer science can be solved with another level of indirecon” (David Wheeler) • Virtualizaon, as the level of indirecon, allows us to have massive adopon and innovaon. Outline • Virtualizaon will be pervasive • Why does a 1960s technology make sense? • New uses of virtualizaon: – Applicaon distribuon – Ulity compung – The OS of the future Problems with SW distribuon model • Not so bad with MacOS, System Z… vendor controls it all, especially if applicaon specific to plaorm. • In the high volume MS and Linux space, lots of vendors, working at different schedules…: – ISV must support many operang systems from a correctness and performance opmizaon perspecve. – ISV must support for all patches (e.g., app, websphere, DB2, OS), applying patch may break any level, DLL hell... – Installaon: user must install full OS, administer all the levels. • 50% of support calls during install/configure cycle • Installaon different from what ISV expected, performance/funcon problems – Support hell: where does the problem come from – Backup, HA… tools different from what ISV tested – Patching hell: patch of any level may break others – Management and performance opmizaon complexity for user… – Mul‐ered applicaon has mulple components that need to be configured and integrated to operate together. – Huge barrier to entry for new SW: • SW must have compelling value, solving many problems • SW gets more complicated, and we are stuck in a vicious circle. Hardware Appliance‐Based Soluons: PROS • Comes “pre‐assembled” with all of the required components for the soluon (hardware, OS, applicaon bits) • Simple plug‐and‐play installaon • Consistent stack makes support easier for vendor • Underlying lower levels (OS) can be “hidden” from user Hardware Appliance‐Based Soluons: CONS • Proliferaon of non‐standard hardware • Hardware support provided by non‐standard vendor (possibly mulple vendors: one for hardware, one for overall soluon) • Operaons team has to learn how to support both the hardware and the soluon • Hardware used for a single purpose may be under ulized • Hardware takes up rack‐space, consumes addional power, and requires addional HVAC What is a Virtual Appliance • Pre‐built, pre‐configured and ready‐to‐run soware applicaon packaged with the OS inside a Virtual Machine. FIREWALLVirtualFirewall Appliance SW Linux • Or packaged inside mulple Virtual Machines Apache mySQL CRMVirtual Appliance Linux Tomcat Linux Linux VA distribuon model • ISV supports a single OS, and can full opmize • ISV controls the full environment, patches… • No installaon effort • No finger poinng • Backup, HA… either integrated in appliance, or at the VA level • Mul‐ered applicaon configured by ISV • New SW can be easily deployed, tested, discarded, does not need to solve all the worlds problems • Customer picks the HW Where we are going long term Ready‐to‐Go Music Ready‐to‐Go Apps “VAM” VMware Infrastructure iPod What is needed • Tools for developing virtual appliances • Tools to allow ISV ongoing role in administering soluon. • Standards in infancy: OVF • Meta data to describe expected role of components to VI • How do we make download cheap (streaming, de‐duplicaon…) • Evoluon of SW to separate installaon from customizaon. • VI that can introspect on appliance, what level of trust in ISV required? • Ulity infrastructure • New OS model Outline • Virtualizaon will be pervasive • Why does a 1960s technology make sense? • New uses of virtualizaon: – Applicaon distribuon – Ulity compung – The OS of the future Grid and grid‐like technologies are the future • Web applicaons being developed with scale‐out frameworks • MapReduce and related frameworks…, Data Intensive Supercompung • Ulies inside companies • Hosng companies like Rackspace • Shared ulies like Amazon’s EC2 • The rise of SAAS like salesforce.com • HPC capacity and capability systems Grid and Virtualization are complementary: •Are Grid: both motivated technologies by analogy really goingof power to be grid pervasive? • Virtualization: converts computation into a fungible commodity; hugely simplifies realization of grid Problems with grid • Security: grid job can compromise host • Isolaon: resource isolaon grid/host task • Service level guarantees: needed for enterprise • OS heterogeneity limits targets • Applicaon needs to be re‐wrien • Ulizaon of grid nodes • Management of hardware • Use of tradional OS: – Large aack surface, high overhead, management complexity… Virtualizaon and the grid • Isolaon: – VM’s can’t compromise other jobs or host – Resources VMs isolated • Service level guarantees • OS can be created on demand • Applicaon do not need to be re‐wrien • Grid node can be fully used • Management of hardware • Can write special purpose OS: – Reduce aack surface, increase reliability, simplicity… – Lets grid job get closer to the metal. Grid Compung Grid Job Grid Job Grid Job Grid Grid Job Middleware Grid Job Grid Job Jobs IN/OUT Virtualizaon based Grid Jobs IN/OUT Grid Middleware Grid Other job Job •Grid middleware can focus on “core” Grid issues. • Virtual infrastructure provides simplified abstracon used by Grid middleware and other applicaons. Automac load balancing across hosts Distributed Resource Dynamic Balancing Scheduling (DRS) Continuous Optimization Adding and removing hosts Add/remove capacity on demand Hot-plug machines Distributed power optimization Improve application availability DRS X Moving to Ulity model PHYSICAL VIRTUALIZED POOLED R R P P 1 2 HW HW HW HW HW HW HW HW HW HW HW HW HW HW HW HW HW HW Logical Resource Pooling (RP) Distributed Resource Scheduler (DRS) Research • Quality of service for different physical resources. • Detecng resource use and impact on applicaon. • Expressing applicaon requirements to infrastructure. – Scale up/down web applicaon? – Co‐scheduling of HPC applicaons. – What is the right abstracng between grid/cloud middleware… and virtual infrastructure. • Enabling very heterogeneous HW. Outline • Virtualizaon will be pervasive • Why does a 1960s technology make sense? •