DOCSLIB.ORG

Vms, Unikernels and Containers: Experiences on the Performance of VirtualizaOn Technologies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Vms, Unikernels and Containers: Experiences on the Performance of Virtualiza�On Technologies VMs, Unikernels and Containers: Experiences on the Performance of Virtualizaon Technologies Felipe Huici, Filipe Manco, Jose Mendes, Simon Kuenzer NEC Europe Ltd. (Heidelberg) In the Beginning… VM In the Beginning… “Tinyfied VMs” VM In the Beginning… “Tinyfied VMs” unikernels VM In the Beginning… “Tinyfied VMs” containers unikernels VM In the Beginning… “Tinyfied VMs” containers unikernels VM Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput ? higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput ? higher lower overhead overhead Virtualizaon Technology Benchmarking • Metrics: – VM image and memory consump=on: ls, top, xl – VM creaon =me: SYN flood + RST detec=on – Throughput: iperf, guest to host (TCP traffic) – RTT: ping flood • VM-based tests run on both Xen and KVM • Hardware: x86_64 server with an Intel Xeon E5-1630 v3 3.7GHz CPU (4 cores), 32GB RAM. Virtualizaon Technologies • “Standard” VM – Standard Debian-based Linux VM • “Tinyfied” VM – Tinyx, based on Linux kernel/busybox • Unikernel – On Xen: MiniOS + miniperf – On KVM: OSv + iperf • Containers – Docker Virtualizaon Technologies • “Standard” VM – Standard Debian-based Linux VM • “Tinyfied” VM – Tinyx, based on Linux kernel/busybox • Unikernel – On Xen: MiniOS + miniperf – On KVM: OSv + iperf • Containers – Docker Standard VM: Applicaon on Top of Distro User Applica5on 3rd Party Applica5ons Libraries Services Kernel Most of the VM not Used… Nginx User Applica5on memcached bash 3rd Party Applica5ons libssl Libraries libc ssh init Services ext4 netfront blkfront Kernel Tinyx: Keep Only What’s Needed Nginx User Applica5on memcached bash 3rd Party Applica5ons libssl Libraries libc ssh init Services ext4 netfront blkfront Kernel Tinyx: Taylor-made Distro Nginx User Applica5on memcached bash 3rd Party Applica5ons libssl Libraries libc ssh init Services netfront blkfront Kernel ext4 Tinyx: Taylor-made Distro Nginx User Applica5on memcached bash 3rd Party Applica5ons libssl Libraries libc ssh init Services netfront blkfront Kernel ext4 Tinyx: Taylor-made Distro Nginx User Applica5on memcached bash 3rd Party Applica5ons libssl Libraries libc ssh init Services netfront blkfront Kernel ext4 Tinyx: Taylor-made Distro Nginx User Applica5on memcached bash 3rd Party Applica5ons libssl Libraries libc ssh init Services netfront blkfront Kernel ext4 Tinyx: Taylor-made Distro ▌ Keep only the Nginx User Applica5on necessary bits memcached and pieces bash 3rd Party Applica5ons l Specialized kernel build containing only the necessary modules libssl Libraries l Root filesystem libc populated with only necessary ssh services, libraries and 3rd party init Services applications netfront blkfront Kernel ext4 Virtualizaon Technologies • “Standard” VM – Standard Debian-based Linux VM • “Tinyfied” VM – Tinyx, based on Linux kernel/busybox • Unikernel – On Xen: MiniOS + miniperf – On KVM: OSv + iperf • Containers – Docker Virtualizaon Technologies • “Standard” VM – Standard Debian-based Linux VM • “Tinyfied” VM – Tinyx, based on Linux kernel/busybox • Unikernel – On Xen: MiniOS + miniperf – On KVM: OSv + iperf • Containers – Docker What’s a Unikernel? • Specialized VM: single applicaon + minimalis=c OS • Single address space, co-operave scheduler so low overheads What’s a Unikernel? • Specialized VM: single applicaon + minimalis=c OS 1 pp a app N app 2 • Single address space, USER SPACE co-operave scheduler so low overheads KERNEL SPACE driverN driver1 driver2 GENERAL-PURPOSE OPERATING SYSTEM (e.G., Linux, FreeBSD) What’s a Unikernel? • Specialized VM: single applicaon + minimalis=c OS 1 pp a app N app 2 • Single address space, USER SPACE co-operave scheduler so low overheads app SINGLE ADDRESS SPACE KERNEL SPACE driverN driver1 driver2 vdriver2 Vdriver1 GENERAL-PURPOSE MINIMALISTIC OPERATING SYSTEM OPERATING SYSTEM (e.G., Linux, FreeBSD) (e.G., MiniOS, OSv) Unikernels for Benchmarking apps guest OS On Xen Xen Unikernels for Benchmarking apps iperf guest mini OS OS On Xen Xen Xen Unikernels for Benchmarking apps iperf guest mini OS OS On Xen Xen Xen apps guest OS On KVM KVM Unikernels for Benchmarking apps iperf guest mini OS OS On Xen Xen Xen apps iperf guest OSv OS On KVM KVM KVM Nota Bene… • Our unikernel numbers include op=mizaons to the underlying virtualizaon plaorms (Xen, KVM) – Toolstacks – Back-end stores – Hotplug scripts – Network drivers (on Xen Tx) • No =me to go over these… RESULTS Image Size, Memory Usage (log scale) 1000 913 913 img size mem usage 100 112 82 61 52 MB 31 30 10 12 8 3.8 3.7 3.5 2 1 Boot Times (log scale) 10000 6500 2988 ) 1000 1711 1081 ms 431 330 100 Boot Time ( 31 10 1 RTT 40 35 30 34 ) 25 ms 20 19 18 RTT ( 15 15 10 5 9 5 4 0 Throughput 60 Tx 50 Rx 40 30 Throughput (Gb/s) 20 10 0 Conclusions • Common lore: VMs provide good isolaon but are heavyweight – Results with standard VMs confirm this • Containers provide lighter-weight virtualizaon – But nyfied VMs and especially unikernels yield comparable performance Conclusions • Common lore: VMs provide good isolaon but are heavyweight – Results with standard VMs confirm this • Containers provide lighter-weight virtualizaon – But nyfied VMs and especially unikernels yield comparable performance Potenal Contribuons to dra-natarajan-nfvrG-containers-for-nfv-01 2.1.1 Challenges - VNF provisioning me - Run=me performance (throughput, scaling up/down) 3. Benefits of Containers - Service agility vs VMs - Containers have beoer run=me performance - Auto-scaling of VNFs - Cross-VNF compability: container unikernel/minimalis=c distro - Overall performance: VMs -25% throughput vs containers 5. Conclusion - Containers have significant advantages vs hypervisor-based solu=ons .
Load more

Recommended publications
  • The Next Generation Cloud: the Rise of the Unikernel
    The Next Generation Cloud: The Rise of the Unikernel A Xen Project publication April 2015 xenproject.org Docker and Linux container technologies dominate headlines today as a powerful, easy way to package applications, especially as cloud computing becomes more mainstream. While still a work-in-progress, they offer a simple, clean and lean way to distribute application workloads. With enthusiasm continuing to grow for container innovations, a related technology called unikernels is also beginning to attract attention. Known also for their ability to cleanly separate functionality at the component level, unikernels are developing a variety of new approaches to deploy cloud services. Traditional operating systems run multiple applications on a single machine, managing resources and isolating applications from one another. A unikernel runs a single application on a single virtual machine, relying instead on the hypervisor to isolate those virtual machines. Unikernels are constructed by using “library operating systems,” from which the developer selects only the minimal set of services required for an application to run. These sealed, fixed-purpose images run directly on a hypervisor without an intervening guest OS such as Linux. As well as improving upon container technologies, unikernels are also able to deliver impressive flexibility, speed and versatility for cross-platform environments, big data analytics and scale-out cloud computing. Like container-based solutions, this technology fulfills the promise of easy deployment, but unikernels also offer an extremely tiny, specialized runtime footprint that is much less vulnerable to attack. There are several up-and-coming open source projects to watch this year, including ClickOS, Clive, HaLVM, LING, MirageOS, Rump Kernels and OSv among others, with each of them placing emphasis on a different aspect of the unikernel approach.
    [Show full text]
  • A Linux in Unikernel Clothing Lupine
    A Linux in Unikernel Clothing Hsuan-Chi Kuo+, Dan Williams*, Ricardo Koller* and Sibin Mohan+ +University of Illinois at Urbana-Champaign *IBM Research Lupine Unikernels are great BUT: Unikernels lack full Linux Support App ● Hermitux: supports only 97 system calls Kernel LibOS + App ● OSv: ○ Fork() , execve() are not supported Hypervisor Hypervisor ○ Special files are not supported such as /proc ○ Signal mechanism is not complete ● Small kernel size ● Rumprun: only 37 curated applications ● Heavy ● Fast boot time ● Community is too small to keep it rolling ● Inefficient ● Improved performance ● Better security 2 Can Linux behave like a unikernel? 3 Lupine Linux 4 Lupine Linux ● Kernel mode Linux (KML) ○ Enables normal user process to run in kernel mode ○ Processes can still use system services such as paging and scheduling ○ App calls kernel routines directly without privilege transition costs ● Minimal patch to libc ○ Replace syscall instruction to call ○ The address of the called function is exported by the patched KML kernel using the vsyscall ○ No application changes/recompilation required 5 Boot time Evaluation Metrics Image size Based on: Unikernel benefits Memory footprint Application performance Syscall overhead 6 Configuration diversity ● 20 top apps on Docker hub (83% of all downloads) ● Only 19 configuration options required to run all 20 applications: lupine-general 7 Evaluation - Comparison configurations Lupine Cloud Operating Systems [Lupine-base + app-specific options] OSv general Linux-based Unikernels Kernel for 20 apps
    [Show full text]
  • Governance in Collaborative Open Source Software Development Organizations: a Comparative Analysis of Two Case Studies
    Governance in Collaborative Open Source Software Development Organizations: A Comparative Analysis of two Case Studies Master’s thesis Faculty of Business, Economics and Social Sciences University of Bern submitted to Dr. Matthias Stürmer Research Center for Digital Sustainability Institute of Information Systems by Winkelmann, Rahel from Siselen 11th semester Matriculation nr.: 09-127-788 Study address: Huberstrasse 22 3008 Bern (Tel. 078 758 58 96) (e-Mail: [email protected]) Bern, 20.01.2015 Abstract While loose cooperation among several actors is common in the open source sector, companies merging into a professionally governed collaborative open source software development organization across industries is an emerging phenomenon. The purpose of this thesis is to shed light on this new approach of software development by creating a framework for building a collaborative open source software development organization. A comparative analysis examines the governance models of two different collaborative open source software development organizations from the organizational, financial and legal perspective and reveals the autonomous and the affiliated organization type and their key characteristics. Based on these findings and by means of four expert interviews a framework consisting of eight criteria that need to be considered in order to build a collaborative open source software development organization is created. Zusammenfassung In der Open Source Branche ist es gängig, dass sich verschiedene Akteure zur Softwareentwicklung zu losen Konsortien zusammenschliessen. Unternehmen, welche sich im professionellen Rahmen zu einer Organisation zusammenschliessen um gemeinsam Open Source Software zu entwickeln, sind jedoch ein neues Phänomen. Der Zweck dieser Arbeit ist es Aufschluss über diesen neuen Ansatz von Softwareentwicklung zu geben.
    [Show full text]
  • Erlang on Physical Machine
    on $ whoami Name: Zvi Avraham E-mail: [email protected] /ˈkɒm. pɑː(ɹ)t. mɛntl̩. aɪˌzeɪ. ʃən/ Physicalization • The opposite of Virtualization • dedicated machines • no virtualization overhead • no noisy neighbors – nobody stealing your CPU cycles, IOPS or bandwidth – your EC2 instance may have a Netflix “roommate” ;) • Mostly used by ARM-based public clouds • also called Bare Metal or HPC clouds Sandbox – a virtual container in which untrusted code can be safely run Sandbox examples: ZeroVM & AWS Lambda based on Google Native Client: A Sandbox for Portable, Untrusted x86 Native Code Compartmentalization in terms of Virtualization Physicalization No Virtualization Virtualization HW-level Virtualization Containerization OS-level Virtualization Sandboxing Userspace-level Virtualization* Cloud runs on virtual HW HARDWARE Does the OS on your Cloud instance still supports floppy drive? $ ls /dev on Ubuntu 14.04 AWS EC2 instance • 64 teletype devices? • Sound? • 32 serial ports? • VGA? “It’s DUPLICATED on so many LAYERS” Application + Configuration process* OS Middleware (Spring/OTP) Container Managed Runtime (JVM/BEAM) VM Guest Container OS Container Guest OS Hypervisor Hardware We run Single App per VM APPS We run in Single User mode USERS Minimalistic Linux OSes • Embedded Linux versions • DamnSmall Linux • Linux with BusyBox Min. Linux OSes for Containers JeOS – “Just Enough OS” • CoreOS • RancherOS • RedHat Project Atomic • VMware Photon • Intel Clear Linux • Hyper # of Processes and Threads per OS OSv + CLI RancherOS processes CoreOS threads
    [Show full text]
  • A Comprehensive Overview Last Updated: January
    Project ACRN: A Comprehensive Overview Last updated: January 19, 2021 Content ❖ Introduction ❖ Architecture ❖ Value Proposition ❖ Key Capabilities ❖ Scenarios Introduction ACRN™ is a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform. - A Linux Foundation Project Launched in March 2018 - Version 1.0 released in May 2019 - Version 2.0 released in June 2020 Overallarchitecture ACRN is a registered trademark of the Linux Foundation. *Other names and brands may be claimed as the property of others. Value Proposition - ACRN Small Footprint • Optimized for resource-constrained devices • Small codebase: less than 40,000 vs. >156,000 lines of code for datacenter-centric hypervisors Functional Safety & Hard Real-time • Heterogeneous Workloads Consolidation • Supports also the most demanding workloads: safety-critical and real- time Open-source with Flexible License • Permissive BSD license enables proprietary Guest OS • Business-friendly to adopt, modify and integrate • True open source with a vibrant Community ACRN reduces system deployment complexity, enables heterogeneous architectures, and provide TCO advantages Key Capabilities Functional Safety Hard Real-time MISRA-C Compliance Support hard or soft RT VM FuSa certification targeted Optimized for RT, e.g. no VMExit*, cache isolation Security & Isolation Rich I/O Mediation Full isolation for mixed criticality workloads Graphics, Audio, USB… Intel VT backed isolation Industry
    [Show full text]
  • Design a System That “Just Works” the Arm Serverready Program and Beyond
    Design a System that “Just Works” The Arm ServerReady Program and Beyond November 2019 White Paper 1 Contents Page Topic 3 Executive Summary 3 1. Introduction 3 2. Arm ServerReady Program 3 2.1 Background and History 4 2.2 Arm Standards-Based Approach 6 3. Arm Server Advisory Committee (ServerAC) 6 3.1 ServerAC Development Process 8 4. Arm Server Standards 8 4.1 Server Base System Architecture (SBSA) 8 4.2 Server Base Boot Requirements (SBBR) 9 4.3 Server Base Security Guide (SBSG) 10 4.4 Server Base Manageability Requirements (SBMR) 11 5. Architectural Compliance Suites 12 5.1 Arm ServerReady Players and Responsibilities 15 6. Conclusion 16 7. Glossary 2 Executive Summary This whitepaper describes the ServerReady program, certification process, and Arm’s standards-based approach to system development. This approach is not limited to servers, it is suitable for other use cases, including edge and client devices, if standard operating systems are used. The intended audience is Arm-based processors and systems developers and integrators. By reading this paper, you will learn about Arm’s standards- based approach for development, and how to design and certify systems with the Arm ServerReady program. 1. Introduction In order to design a system that “just works” for the end user, with the ability to install and run standard operating systems (e.g. Windows, RHEL, VMWare, etc…) out-of-the-box, a set of minimum hardware and firmware requirements must be followed. For the Arm Ecosystem, such a need first surfaced in the server segment. The Arm ServerReady compliance program provides this “just works” solution for servers, enabling partners to deploy Arm servers with confidence.
    [Show full text]
  • Operator and Service Manual Standard 30 MF
    Standard 30 MF 110-700 Operator and Service Manual Raytheon Anschütz GmbH Postfach 11 66 D-24100 Kiel Germany Tel +49-4 31-30 19-0 Fax +49-4 31-30 19 464 Email [email protected] Edition: 01 www.raytheon-anschuetz.com 10000000756 Dieses Dokument sowie dessen Inhalt sind This document and its content are copyright urheberrechtlich geschützt. Die Weitergabe, protected. Distribution, reproduction and Vervielfältigung und Speicherung sowie die storage as well as translation and exploitation Übersetzung wie auch Verwendung dieses of this document and its content, in whole or Dokuments oder dessen Inhalts, als Ganzes in parts and regardless of what form, are oder in Teilen und egal in welcher Form, ist prohibited without prior express written ohne vorherige ausdrückliche schriftliche permission. Offenders will be held liable for Genehmigung nicht gestattet. the payment of damages. Zuwiderhandlungen verpflichten zu Schadenersatz. Änderungen dieses Dokuments und dessen Changes and modification to this document Inhalt bleiben vorbehalten. and its content reserved. Standard 30 MF 110-700 Operator and Service Manual This manual has been drawn up as a description and reference work. It will help answer questions and will solve problems in the quickest possible manner. Before operating the equipment read and follow the instructions and hints provided in this manual. For this purpose refer to the table of contents and read the corresponding chapters thoroughly. If you have any further questions, please contact us at the following address: RAYTHEON ANSCHÜTZ GMBH Tel. +49 431 / 3019 - 0 Zeyestr. 16 - 24 Fax +49 431 / 3019 - 291 D-24106 Kiel Germany All rights reserved.
    [Show full text]
  • User Manual Piezo Positioning Electronic ANC300
    Version: 3. 1 Modified: January 2014 Products: ANC300, ANM150, ANM200, ANM300 Firmware: 18 -04 -2012 User Manual Piezo Positioning Electronic ANC300 Open source software notice The ANC300 and its modules (ANM150, ANM200, and ANM300) include certain open source or other software originating from third parties that is subject to the GNU General Public License (GPL), GNU Library/Lesser General Public License (LGPL) and different and/or additional copyright licenses, disclaimers and notices. You may obtain a complete corresponding machine-readable copy of the source code of such software under the GPL or LGPL from attocube systems. attocube sys- tems offers to provide such source code to you on CD-ROM for a charge covering the cost of performing such distribution, such as the cost of media, shipping and handling, upon written request to: attocube systems AG Königinstrasse 11a RGB D-80539 München Germany This offer is valid for a period of three (3) years from the date of the distribution of this product by attocube. ATTOCUBE SYSTEMS AG MAKES NO REPRESENTATION ABOUT THE SUITABILITY OF THIS SOURCE CODE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND. ATTOCUBE SYSTEMS AG DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOURCE CODE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL ATTOCUBE SYSTEMS AG BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE, OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOURCE CODE.
    [Show full text]
  • Software Just Works on Arm-Based Devices
    Software Just Works on Arm-based Devices White paper - Version 2 Contents 1 Glossary 5 2 Executive Summary 7 3 Introduction 8 4 Arm System Architecture 10 4.1 Arm standards-based approach 10 4.2 Base System Architecture and its supplements 11 4.3 Base Boot Requirements 13 5 Architectural Compliance Suite 14 5.1 SBSA Architecture Compliance Suite 14 5.2 Enterprise Architecture Compliance Suite 14 6 Arm SystemReady Program 15 6.1 Arm SystemReady Program 15 6.2 Arm SystemReady Certification Process 17 7 Pre-Silicon Compliance Testing 18 8 Security Extension 19 9 SystemReady Compliance 20 9.1 BSA Compliance 20 9.2 BBR Compliance 20 10 Use Cases 22 11 Conclusion 23 1 Arm Non-Confidential Document Licence (“Licence”) This Licence is a legal agreement between you and Arm Limited (“Arm”) for the use of Arm’s intellectual property (including, without limitation, any copyright) embodied in the document accompanying this Licence (“Document”). Arm licenses its intellectual property in the Document to you on condition that you agree to the terms of this Licence. By using or copying the Document you indicate that you agree to be bound by the terms of this Licence. “Subsidiary” means any company the majority of whose voting shares is now or hereafter owner or controlled, directly or indirectly, by you. A company shall be a Subsidiary only for the period during which such control exists. This Document is NON-CONFIDENTIAL and any use by you and your Subsidiaries (“Licensee”) is subject to the terms of this Licence between you and Arm.
    [Show full text]
  • A Performance Benchmarking Analysis of Hypervisors, Containers and Unikernels on Armv8 and X86 Cpus Eucnc 2018, Ljubljana, Slovenia June 18-21
    A performance benchmarking analysis of Hypervisors, Containers and Unikernels on ARMv8 and x86 CPUs EuCNC 2018, Ljubljana, Slovenia June 18-21 [email protected] www.virtualopensystems.com Authorship and sponsorship Virtual Open Systems is a high-tech software company active in open source virtualization solutions and custom services for complex mixed-criticality automotive systems, NFV networking infrastructures, mobile devices and in general for embedded heterogeneous multicore systems around new generation processor architectures. This work is done in the context of the H2020 “Next Generation Platform as a Service” project (www.ngpaas.eu). 2 Virtual Open Systems Confidential & Proprietary Agenda Objectives Evaluated Solutions – Virtual Machines – Containers – Unikernels Benchmark configuration Benchmark results Conclusion 3 Virtual Open Systems Confidential & Proprietary Agenda Objectives Evaluated Solutions – Virtual Machines – Containers – Unikernels Benchmark configuration Benchmark results Conclusion 4 Virtual Open Systems Confidential & Proprietary Objectives Software Defined Network (SDN) and Network Function Virtualization (NFV) technologies are emerging in the Edge Computing Efficient virtualization technologies are becoming crucial New lightweight techniques (Containers, Unikernels) have emerged This work focuses on comparing the performance of open- source virtualization technologies on X86 and ARMv8 5 Virtual Open Systems Confidential & Proprietary Agenda Objectives Evaluated Solutions – Virtual
    [Show full text]
  • 55Hfl6014u 12 Dfu Swe.Pdf
    Användarhandbok 32HFL5014 43HFL5014 43HFL6014U 50HFL5014 50HFL6014U 55HFL6014U 65HFL6014U Innehåll 10.8 Mer 26 1 TV-pres. 3 10.9 Professionella inställningar 27 1.1 Professionellt läge 3 10.10 Google-konto 28 2 Installation 4 11 Android TV-hemskärm 29 2.1 Läs säkerhetsinstruktionerna 4 11.1 Om Android TV-hemskärmen 29 2.2 TV-stativ eller väggmontering 4 11.2 Öppna Android TV-hemskärmen 29 2.3 Tips om placering 4 11.3 Android TV-inställningar 29 2.4 Nätkabel 4 11.4 Anslut din Android TV 32 2.5 Antennkabel 5 11.5 Kanaler 35 11.6 Kanalinstallation 36 3 Fjärrkontroll 6 11.7 Internet 37 3.1 Knappöversikt 6 11.8 Smarttelefoner och surfplattor 38 3.2 IR-sensor 6 11.9 Programvara 38 3.3 Batterier 7 3.4 Rengöring 7 12 Programvara med öppen källkod 40 12.1 Öppen källkod-licens 40 4 Slå på och av 8 4.1 På eller standby 8 13 Hjälp och support 128 4.2 Knappar på TV:n 8 13.1 Felsökning 128 13.2 Onlinehjälp 129 5 Specifikationer 9 13.3 Support och reparation 130 5.1 Miljö 9 5.2 Effekt 10 14 Säkerhet och skötsel 131 5.3 Operativsystem 10 14.1 Säkerhet 131 5.4 Mottagning 10 14.2 Skötsel av bildskärmen 132 5.5 Visningstyp (6014U) 10 14.3 Radiation Exposure Statement 132 5.6 Visningstyp (5014) 10 5.7 Ingångsupplösning för skärm 10 15 Användningsvillkor 133 5.8 Ingångsupplösning för skärm (5014) 10 15.1 Användningsvillkor – TV 133 5.9 Anslutning (6014U) 11 5.10 Anslutning (5014) 11 16 Copyrights 134 5.11 Mått och vikt 11 16.1 MHL 134 5.12 Ljud 11 16.2 HDMI 134 16.3 Dolby-ljud 134 6 Ansluta enheter 13 16.4 DTS-HD Premium Sound ™ 134 6.1 Ansluta enheter 13
    [Show full text]
  • X-Containers: Breaking Down Barriers to Improve
    Session: Cloud II ASPLOS’19, April 13–17, 2019, Providence, RI, USA X-Containers: Breaking Down Barriers to Improve Performance and Isolation of Cloud-Native Containers Zhiming Shen Zhen Sun Gur-Eyal Sela∗ Cornell University Cornell University University of California, Berkeley Eugene Bagdasaryan Christina Delimitrou Robbert Van Renesse Cornell University Cornell University Cornell University Hakim Weatherspoon Cornell University Abstract CCS Concepts • Security and privacy → Virtualiza- “Cloud-native” container platforms, such as Kubernetes, have tion and security; • Software and its engineering → become an integral part of production cloud environments. Operating systems. One of the principles in designing cloud-native applica- Keywords Containers; X-Containers; Cloud-Native; Li- tions is called Single Concern Principle, which suggests that brary OS; exokernel each container should handle a single responsibility well. In this paper, we propose X-Containers as a new security ACM Reference Format: paradigm for isolating single-concerned cloud-native con- Zhiming Shen, Zhen Sun, Gur-Eyal Sela, Eugene Bagdasaryan, tainers. Each container is run with a Library OS (LibOS) Christina Delimitrou, Robbert Van Renesse, and Hakim Weath- that supports multi-processing for concurrency and compat- erspoon. 2019. X-Containers: Breaking Down Barriers to Improve Performance and Isolation of Cloud-Native Containers. In 2019 Ar- ibility. A minimal exokernel ensures strong isolation with chitectural Support for Programming Languages and Operating Sys- small kernel attack surface. We show an implementation tems (ASPLOS ’19), April 13–17, 2019, Providence, RI, USA. ACM, New of the X-Containers architecture that leverages Xen para- York, NY, USA, 15 pages. https://doi.org/10.1145/3297858.3304016 virtualization (PV) to turn Linux kernel into a LibOS.
    [Show full text]