A Small-Scale Testbed for Large-Scale Reliable Computing Jason R

Total Page:16

File Type:pdf, Size:1020Kb

A Small-Scale Testbed for Large-Scale Reliable Computing Jason R Purdue University Purdue e-Pubs Open Access Theses Theses and Dissertations 12-2016 A small-scale testbed for large-scale reliable computing Jason R. St. John Purdue University Follow this and additional works at: https://docs.lib.purdue.edu/open_access_theses Part of the Computer Sciences Commons Recommended Citation St. John, Jason R., "A small-scale testbed for large-scale reliable computing" (2016). Open Access Theses. 899. https://docs.lib.purdue.edu/open_access_theses/899 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. Graduate School Form 30 Updated PURDUE UNIVERSITY GRADUATE SCHOOL Thesis/Dissertation Acceptance This is to certify that the thesis/dissertation prepared By Jason R. St. John Entitled A SMALL-SCALE TESTBED FOR LARGE-SCALE RELIABLE COMPUTING For the degree of Master of Science Is approved by the final examining committee: Thomas Hacker Chair Eric Matson John Springer To the best of my knowledge and as understood by the student in the Thesis/Dissertation Agreement, Publication Delay, and Certification Disclaimer (Graduate School Form 32), this thesis/dissertation adheres to the provisions of Purdue University’s “Policy of Integrity in Research” and the use of copyright material. Approved by Major Professor(s): Thomas Hacker Approved by: Jeffrey Whitten 11/29/2016 Head of the Departmental Graduate Program Date A SMALL-SCALE TESTBED FOR LARGE-SCALE RELIABLE COMPUTING A Thesis Submitted to the Faculty of Purdue University by Jason R. St. John In Partial Fulfillment of the Requirements for the Degree of Master of Science December 2016 Purdue University West Lafayette, Indiana ii ACKNOWLEDGMENTS I wish to gratefully acknowledge my thesis committee, my family, and my fellow graduate students for their help and support, encouragement, and insight. iii TABLE OF CONTENTS Page LIST OF TABLES :::::::::::::::::::::::::::::::: v LIST OF FIGURES ::::::::::::::::::::::::::::::: vi ABBREVIATIONS :::::::::::::::::::::::::::::::: vii ABSTRACT ::::::::::::::::::::::::::::::::::: ix CHAPTER 1. INTRODUCTION :::::::::::::::::::::::: 1 1.1 Scope :::::::::::::::::::::::::::::::::: 1 1.2 Significance ::::::::::::::::::::::::::::::: 1 1.3 Research Question ::::::::::::::::::::::::::: 2 1.4 Assumptions ::::::::::::::::::::::::::::::: 2 1.5 Limitations ::::::::::::::::::::::::::::::: 3 1.6 Delimitations :::::::::::::::::::::::::::::: 3 1.7 Definitions :::::::::::::::::::::::::::::::: 4 1.8 Summary :::::::::::::::::::::::::::::::: 5 CHAPTER 2. REVIEW OF RELEVANT LITERATURE :::::::::: 6 2.1 HPC System Reliability :::::::::::::::::::::::: 6 2.2 HPC, Cloud Computing, and Virtualization ::::::::::::: 8 2.3 Error Injection ::::::::::::::::::::::::::::: 9 2.4 Summary :::::::::::::::::::::::::::::::: 11 CHAPTER 3. FRAMEWORK AND METHODOLOGY ::::::::::: 12 3.1 Study Design :::::::::::::::::::::::::::::: 12 3.1.1 Data Sets :::::::::::::::::::::::::::: 12 3.1.2 Overview of Statistical Model Creation :::::::::::: 13 3.1.3 System Log Analysis :::::::::::::::::::::: 14 3.1.3.1 Coates: Log Processing and Sorting ::::::::: 14 3.1.3.2 Coates: Timestamp Standardization :::::::: 15 3.1.3.3 Coates: Node ID Standardization :::::::::: 15 3.1.3.4 Coates: Scatter Plots of Memory Failure Events :: 16 3.1.3.5 Coates: Declustering of Failure Events ::::::: 16 3.1.3.6 Carter: Scatter Plots of Hard Disk Failure Events : 16 3.1.3.7 Carter: Declustering of Failure Events ::::::: 16 3.1.3.8 Distribution Fitting ::::::::::::::::: 21 3.1.4 Fault Injection ::::::::::::::::::::::::: 21 iv Page 3.1.4.1 Memory Error Injection Procedure ::::::::: 22 3.1.4.2 Machine Check Registers ::::::::::::::: 22 3.1.4.3 Memory Error Injection Strings ::::::::::: 23 3.1.4.4 QEMU Modifications and Hard Disk Error Simulation Procedure ::::::::::::::::::::::: 23 3.1.4.5 Hard Disk Errors ::::::::::::::::::: 24 3.1.4.6 Tunable Fault Injection Frequency ::::::::: 25 3.1.4.7 Tuning the Three-Parameter Weibull Distribution : 25 3.1.4.8 Tuning the Lomax Distribution ::::::::::: 25 3.1.4.9 Experimental Setup ::::::::::::::::: 26 3.2 Unit & Sampling :::::::::::::::::::::::::::: 27 3.2.1 Hypothesis :::::::::::::::::::::::::::: 27 3.2.2 Population :::::::::::::::::::::::::::: 27 3.2.3 Sample :::::::::::::::::::::::::::::: 31 3.2.4 Variables ::::::::::::::::::::::::::::: 31 3.2.5 Measure for Success ::::::::::::::::::::::: 31 3.3 Summary :::::::::::::::::::::::::::::::: 31 CHAPTER 4. PRESENTATION OF DATA :::::::::::::::::: 32 4.1 Statistical Models :::::::::::::::::::::::::::: 32 4.1.1 Coates: Memory Errors :::::::::::::::::::: 32 4.1.2 Carter: Hard Disk Errors :::::::::::::::::::: 33 4.2 Experiments ::::::::::::::::::::::::::::::: 33 4.2.1 System Log Samples :::::::::::::::::::::: 33 4.2.2 Quantitative Results :::::::::::::::::::::: 33 CHAPTER 5. CONCLUSIONS, DISCUSSION, AND RECOMMENDATIONS 36 5.1 Conclusions and Discussion :::::::::::::::::::::: 36 5.2 Recommendations :::::::::::::::::::::::::::: 37 APPENDIX A. FAULT INJECTION SCRIPT ::::::::::::::::: 38 APPENDIX B. QEMU SOURCE CODE MODIFICATIONS ::::::::: 51 LIST OF REFERENCES :::::::::::::::::::::::::::: 65 v LIST OF TABLES Table Page 3.1 Comparison of various timestamp formats :::::::::::::::: 15 3.2 Polynomial coefficients ::::::::::::::::::::::::::: 19 3.3 Polynomial roots :::::::::::::::::::::::::::::: 20 3.4 Number of centers vs. WSSE ::::::::::::::::::::::: 21 3.5 Supported memory errors and MCi STATUS register values :::::: 23 3.6 Supported hard disk errors and their descriptions :::::::::::: 24 4.1 Parameters of the three-parameter Weibull distribution for integrated memory controller errors on the Coates system :::::::::::::::::: 32 4.2 Parameters of the Lomax distribution for hard disk errors on the Carter system :::::::::::::::::::::::::::::::::::: 33 4.3 Number of attempted and successful fault injections ::::::::::: 35 vi LIST OF FIGURES Figure Page 3.1 Time of Memory Error Events vs. Node ID ::::::::::::::: 17 3.2 Time of Hard Disk Error Events vs. Node ID :::::::::::::: 18 3.3 WSSE vs. Number of Clusters ::::::::::::::::::::::: 20 3.4 Configuration file for fio :::::::::::::::::::::::::: 28 3.5 systemd service file for fio, installed on the VMs ::::::::::::: 29 3.6 systemd service file for changing the default polling interval for machine checks :::::::::::::::::::::::::::::::::::: 29 3.7 Bash script that changes the default polling frequency for machine checks 30 4.1 System log screenshot of VM \centos4" experiencing an ENOMEDIUM error injection :::::::::::::::::::::::::::::::: 34 vii ABBREVIATIONS ADDR memory address BSD Berkeley Software Distribution CPU central processing unit EC2 Amazon's Elastic Compute Cloud ECC error-correcting code DRAM dynamic random-access memory fio Flexible I/O Tester GART Graphics Address Relocation Table GUI graphical user interface HMP QEMU's Human Monitor Protocol HPC high performance computing IaaS infrastructure as a service I/O input/output IP Internet Protocol ISO International Organization for Standardization IT information technology MAC media access control MC machine check MCA machine check architecture MCE machine check exception MTBF mean time between failures MTTF mean time to failure RAM random-access memory RCAC Rosen Center for Advanced Computing viii RFC Request For Comments RHEL Red Hat Enterprise Linux TLB Translation Lookaside Buffer UTC Coordinated Universal Time VM virtual machine VMM virtual machine monitor WSSE within groups sum of squared error ix ABSTRACT St. John, Jason R. M.S., Purdue University, December 2016. A Small-Scale Testbed For Large-Scale Reliable Computing. Major Professor: Thomas J. Hacker. High performance computing (HPC) systems frequently suffer errors and failures from hardware components that negatively impact the performance of jobs run on these systems. We analyzed system logs from two HPC systems at Purdue University and created statistical models for memory and hard disk errors. We created a small-scale error injection testbed|using a customized QEMU build, libvirt, and Python|for HPC application programmers to test and debug their programs in a faulty environment so that programmers can write more robust and resilient programs before deploying them on an actual HPC system. The deliverables for this project are the fault injection program, the modified QEMU source code, and the statistical models used for driving the injection. 1 CHAPTER 1. INTRODUCTION High performance computing (HPC) systems are a major component of academic and industrial scientific research, and the reliability of these systems is one of the foremost areas of research in the HPC community. The HPC community is continually trying to make larger, more powerful HPC systems, and the poor reliability of commodity HPC clusters is one of the biggest hindrances to the adoption of petascale and exascale computing systems. This chapter provides the scope, significance, research question, and other background information on the thesis. 1.1 Scope This study examined the system logs of large-scale HPC systems operated by the Rosen Center for Advanced Computing (RCAC) at Purdue University. The systems studied are all commodity-based computing clusters running Red Hat Enterprise Linux (RHEL) 5, which is a GNU/Linux distribution based on version 2.6.18 of the Linux kernel. This study determined the frequency at which component failures occurred and produced statistical models of the recorded failure events. The statistical models were used as the driving input to a synthetic fault generator
Recommended publications
  • Effective Virtual CPU Configuration with QEMU and Libvirt
    Effective Virtual CPU Configuration with QEMU and libvirt Kashyap Chamarthy <[email protected]> Open Source Summit Edinburgh, 2018 1 / 38 Timeline of recent CPU flaws, 2018 (a) Jan 03 • Spectre v1: Bounds Check Bypass Jan 03 • Spectre v2: Branch Target Injection Jan 03 • Meltdown: Rogue Data Cache Load May 21 • Spectre-NG: Speculative Store Bypass Jun 21 • TLBleed: Side-channel attack over shared TLBs 2 / 38 Timeline of recent CPU flaws, 2018 (b) Jun 29 • NetSpectre: Side-channel attack over local network Jul 10 • Spectre-NG: Bounds Check Bypass Store Aug 14 • L1TF: "L1 Terminal Fault" ... • ? 3 / 38 Related talks in the ‘References’ section Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications What this talk is not about 4 / 38 Related talks in the ‘References’ section What this talk is not about Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications 4 / 38 What this talk is not about Out of scope: Internals of various side-channel attacks How to exploit Meltdown & Spectre variants Details of performance implications Related talks in the ‘References’ section 4 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) libvirtd QMP QMP QEMU QEMU VM1 VM2 Custom Disk1 Disk2 Appliance ioctl() KVM-based virtualization components Linux with KVM 5 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) libvirtd QMP QMP Custom Appliance KVM-based virtualization components QEMU QEMU VM1 VM2 Disk1 Disk2 ioctl() Linux with KVM 5 / 38 OpenStack, et al. libguestfs Virt Driver (guestfish) Custom Appliance KVM-based virtualization components libvirtd QMP QMP QEMU QEMU VM1 VM2 Disk1 Disk2 ioctl() Linux with KVM 5 / 38 libguestfs (guestfish) Custom Appliance KVM-based virtualization components OpenStack, et al.
    [Show full text]
  • KVM Based Virtualization and Remote Management Srinath Reddy Pasunuru St
    St. Cloud State University theRepository at St. Cloud State Culminating Projects in Information Assurance Department of Information Systems 5-2018 KVM Based Virtualization and Remote Management Srinath Reddy Pasunuru St. Cloud State University, [email protected] Follow this and additional works at: https://repository.stcloudstate.edu/msia_etds Recommended Citation Pasunuru, Srinath Reddy, "KVM Based Virtualization and Remote Management" (2018). Culminating Projects in Information Assurance. 53. https://repository.stcloudstate.edu/msia_etds/53 This Starred Paper is brought to you for free and open access by the Department of Information Systems at theRepository at St. Cloud State. It has been accepted for inclusion in Culminating Projects in Information Assurance by an authorized administrator of theRepository at St. Cloud State. For more information, please contact [email protected]. 1 KVM Based Virtualization and Remote Management by Srinath Reddy Pasunuru A Starred Paper Submitted to the Graduate Faculty of St. Cloud State University in Partial Fulfillment of the Requirements for the Degree Master of Science in Information Assurance May, 2018 Starred Paper Committee Susantha Herath, Chairperson Ezzat Kirmani Sneh Kalia 2 Abstract In the recent past, cloud computing is the most significant shifts and Kernel Virtual Machine (KVM) is the most commonly deployed hypervisor which are used in the IaaS layer of the cloud computing systems. The Hypervisor is the one which provides the complete virtualization environment which will intend to virtualize as much as hardware and systems which will include the CPUs, Memory, network interfaces and so on. Because of the virtualization technologies such as the KVM and others such as ESXi, there has been a significant decrease in the usage if the resources and decrease in the costs involved.
    [Show full text]
  • Ovirt Architecture
    oVirt Architecture Itamar Heim Presented here by Dan Kenigsberg [email protected] oVirt Overview 1 Agenda ● oVirt Components ● Engine ● Clients ● Host ● Engine Agent - VDSM ● Guest ● Storage Concepts ● Data Warehouse & Reports ● User flows oVirt Overview 2 Architecture From 30,000 Feet Servers Engine Client oVirt Overview 3 The Real World Web Clients Python SDK DB Python CLI Engine R LDAP E Server S T Guest agent Spice Guest client Shared Storage VDSM Host Local Storage oVirt Overview 4 oVirt Engine VM & Template Life Cycle Load HA create, schedule, snapshot Balancing Storage Configuration & Monitoring Network Configuration & Monitoring Host Host Host Host Register/Install Monitoring Maintenance Fencing Authentication, Authorization Inventory Audit oVirt Overview 5 oVirt Engine Postgres DB Active Directory Engine RHDS R E S IDM T oVirt Overview 6 The Real World Web Clients Python SDK DB Python CLI Engine R LDAP E Server S T Guest agent Spice Guest client Shared Storage VDSM Host Local Storage oVirt Overview 7 The Clients Admin Portal User Portal R Python SDK Engine E S T Python CLI oVirt Overview 8 Admin Portal oVirt Overview 9 User Portal oVirt Overview 10 Power User Portal oVirt Overview 11 REST API oVirt Overview 12 SDK oVirt Overview 13 CLI oVirt Overview 14 The Real World Web Clients Python SDK DB Python CLI Engine R LDAP E Server S T Guest agent Spice Guest client Shared Storage VDSM Host Local Storage oVirt Overview 15 The Host QEMU/KVM Fedora Engine MOM libvirt oVirt Node VDSM KSM Configuration Monitoring : Network, Storage, Host,
    [Show full text]
  • Vnfs in a CNF Environment
    VNFs in a CNF environment Monika Antoniak, Piotr Skamruk CodiLime Agenda ● Who are we? ● Business use case - use existing VNFs in a containerized set-up ● Technical solution to the problem ● Q&A Who we are? Who we are ● CodiLime has been providing networking engineering services since 2011 ● As part of our R&D efforts and based on our expertise with CNFs and VNFs, we have decided to explore this topic further ● Today we are presenting the working example Business use case Business case What if… ● You love the lightness of containers and use them on a daily basis ● You value the flexibility and resilience of the overall solution ● You want a simple way to deploy things ● You enjoy using kubernetes to manage your resources ● ...and you use a business critical network function as a blackbox VM What can you do to get all of that? A step back: VNFs and CNFs VNF (Virtual Network Function): a well- CNF (Containerized Network Function): a known way to realize network functions in new way of providing required network virtualized or cloud environments functionality with the help of containers Software is provided as a VM image that Software is distributed as a container cannot be changed into a container image, image and can be managed using or is based on an operating system other container-management tools (like docker than Linux images in kubernetes env) VNF examples: vFW, vBNG, vEPC CNF examples: vCPE/cCPE, LDAP, DHCP Back to business Goal: a converged setup for running containerized and VM-based network functions ● using a single user interface
    [Show full text]
  • The Evolution of Linux Containers and Integration of Docker with SLES® 12
    The Evolution of Linux Containers and Integration of Docker with SLES® 12 Michal Svec Flavio Castelli Senior Product Manager Senior Software Engineer [email protected] [email protected] Agenda • Linux Containers • Docker • Demo 2 Linux Containers Traditional virtualization App App App App A A' B B' Bins/Libs Bins/Libs Bins/Libs Bins/Libs Virtual Machine Virtual Guest OS Guest OS Guest OS Guest OS Hypervisor (Type 2) Host OS Server 4 Linux Containers App App App App A A' B B' Bins/Libs Bins/Libs Bins/Libs Bins/Libs Guest OS Guest OS System container Application container Guest OS Guest OS Kernel Kernel Hypervisor (Type 2) Host OS Server 5 What is a Linux Container? Apps Kernel Server 6 Why Use Linux Containers? • Lightweight virtualization solution ‒ Isolated from the other processes ‒ 1 kernel to rule them all ‒ Normal I/O ‒ Dynamic changes possible without reboot ‒ Nested virtualization is not a problem ‒ No boot time or very short one • Isolate services (e.g. web server, ftp, ...) • Provide root read-only access ‒ Mount host / as read-only ‒ Add only needed resources read-write 7 Linux Containers Use Cases • Deploy everywhere quickly ‒ Deploy application and their dependencies together. • Enterprise Data Center ‒ Limit applications which have a tendency to grab all resources on a system: ‒ Memory (databases) ‒ CPU cycles/scheduling (compute intensive applications) • Outsourcing business ‒ Guarantee a specific amount of resources (SLAs!) to a set of applications for a specific customer without more heavy virtualization technologies 8 Linux
    [Show full text]
  • Xen to KVM Migration Guide
    SUSE Linux Enterprise Server 12 SP4 Xen to KVM Migration Guide SUSE Linux Enterprise Server 12 SP4 As the KVM virtualization solution is becoming more and more popular among server administrators, many of them need a path to migrate their existing Xen based environments to KVM. As of now, there are no mature tools to automatically convert Xen VMs to KVM. There is, however, a technical solution that helps convert Xen virtual machines to KVM. The following information and procedures help you to perform such a migration. Publication Date: September 24, 2021 Contents 1 Migration to KVM Using virt-v2v 2 2 Xen to KVM Manual Migration 9 3 For More Information 18 4 Documentation Updates 18 5 Legal Notice 18 6 GNU Free Documentation License 18 1 SLES 12 SP4 Important: Migration Procedure Not Supported The migration procedure described in this document is not fully supported by SUSE. We provide it as a guidance only. 1 Migration to KVM Using virt-v2v This section contains information to help you import virtual machines from foreign hypervisors (such as Xen) to KVM managed by libvirt . Tip: Microsoft Windows Guests This section is focused on converting Linux guests. Converting Microsoft Windows guests using virt-v2v is the same as converting Linux guests, except in regards to handling the Virtual Machine Driver Pack (VMDP). Additional details on converting Windows guests with the VMDP can be found in the separate Virtual Machine Driver Pack documentation at https://www.suse.com/documentation/sle-vmdp-22/ . 1.1 Introduction to virt-v2v virt-v2v is a command line tool to convert VM Guests from a foreign hypervisor to run on KVM managed by libvirt .
    [Show full text]
  • Debugging the Virtualization Layer (Libvirt and QEMU) in Openstack
    Debugging the Virtualization layer (libvirt and QEMU) in OpenStack Kashyap Chamarthy <[email protected]> OpenStack Summit Tokyo 2015 Part I Problem background and overview Problem background – Lots of moving parts: OpenStack services, Virt drivers, System components, etc – Tracking interactions between multiple components is challenging – Finding relevant log patterns in complex systems can become cumbersome Effective root cause analysis with right tooling What kind of bugs? – Unexpected guest crashes – Heisenbugs! (e.g. Nova bug: #1334398) – Bugs introduced by load (e.g. OpenStack CI infra: ~800 test jobs/hr[*]) – Subtle issues in complex features (e.g. live migration), perf. degradation [*] http://status.openstack.org/zuul/ OpenStack Nova – Compute workloads – Pluggable Virtualization drivers [libvirt] virt_type=kvm|qemu|xen|[...] ... – nova-compute: faciliates interactions between hypervisors (libvirt/KVM) & VMs, via the virt driver interface KVM Virtualization building blocks KVM – Linux hardware virt (vmx|svm) QEMU – Emulator: Devices (disk, networks, display, sound, PCI, etc); CPU $ qemu-system-x86_64 -device \? $ qemu-system-x86_64 -cpu \? – Interactions with libvirt: QMP JSON RPC interface, command-line libvirt – Hypervisor agnostic virtualization library Default virtualization drivers in OpenStack OpenStack KVM Virtualization building blocks .------------------. .------------. | OpenStack | | libguestfs | | (`nova-compute`) | .-------------------. '------------------' | guestfish; virt-* | | | '-------------------' | | | | |
    [Show full text]
  • Building Vmnetx with Qemu and Libvirt
    Building VMNetX with qemu and libvirt github.com/cmusatyalab/vmnetx Benjamin Gilbert [email protected] June 3, 2013 What is VMNetX? ● Virtual Machine Network Execution ● Tool for executing remote VMs locally with low startup overhead ○ Disk chunks demand-paged from server ● Designed for preservation and execution of old software ○ Collaboration with University Libraries ● GPLv2 ● Part of the Olive project, olivearchive.org Demo Building VMNetX ● System architecture ● libvirt & qemu in practice ● Unsolved problems Virtual Machine Lifecycle ● Archive curator builds and uploads a VM ○ Using virt-manager for now ● Many users run it ○ We do not save their changes VM VM VM VM VM VM VM Curator Users What is a VM? Domain XML Disk Image Memory Image What is a VM? <domain type="kvm"> <name>machine</name> <uuid>a7434757-631b-496d-a1ba-638014c74cc4</uuid> <memory>65536</memory> <currentMemory>65536</currentMemory> <vcpu>1</vcpu> <os> <type arch="i686" machine="pc">hvm</type> <boot dev="hd"/> </os> <features> <pae/> Domain XML </features> Disk Image Memory Image <clock offset="utc"/> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type="file" device="disk"> <driver name="qemu" type="raw"/> <source file="/disk.img"/> <target dev="hda" bus="ide"/> <address type="drive" controller="0" bus="0" unit="0"/> </disk> <controller type="ide" index="0"> <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x1"/> </controller> <interface type="user"> <mac address="52:54:00:03:a0:11"/> <address type="pci" domain="0x0000" bus="0x00"
    [Show full text]
  • TESTING in QEMU and LIBVIRT Beyond Make and Make Check
    TESTING IN QEMU AND LIBVIRT Beyond make and make check YASH MANKAD RED HAT INC. 26th October 2018 AGENDA What Why How Where 1 KVM Forum 2018 AGENDA What is the state of testing in QEMU and libvirt ? Why How Where 2 KVM Forum 2018 AGENDA What is the state of testing in QEMU and libvirt ? Why should we change ? How Where 3 KVM Forum 2018 AGENDA What is the state of testing in QEMU and libvirt ? Why should we change ? How will it work ? Where 4 KVM Forum 2018 AGENDA What is the state of testing in QEMU and libvirt ? Why should we change ? How will it work ? Where will it run ? 5 KVM Forum 2018 STATE OF VIRT TESTING QEMU libvirt Tests included in qemu source test suite present in source are unit tests code runs unit tests CI environments build QEMU CI environment uses the from source using 'make' and autogen.sh script to build and run 'make check' runs gmake Sub-system tests such as 'check' ensures XML can run iotests, coverity, and dynamic qemu code analysis 6 KVM Forum 2018 STATE OF QEMU TESTING Runs for every patch Ubuntu 12/14.04 x86_64 Runs Debian, Ubuntu sent to qemu-devel hosts, MAC OS X amd-64 ubuntu, fedora, centos Runs make Runs make on docker No functional tests No functional tests checkpatch.pl Runs make check 7 KVM Forum 2018 STATE OF LIBVIRT TESTING on Runs Ubuntu in docker Runs CentOS, Debian, Fedora, rawhide and make syntax-check freebsd make install make and make install make dist 8 KVM Forum 2018 WHY SHOULD WE CHANGE ? 9 KVM Forum 2018 WHY SHOULD WE CHANGE ? Why look beyond make, make check, make install, etc ? Run more functional
    [Show full text]
  • Hands on Virtualization Using XEN
    VirtualizationWorkshop09 < GridkaSchool09 < TWiki http://www-ekp.physik.uni-karlsruhe.de/~twiki/bin/view/GridkaSchool... Hands On Virtualization using XEN Hands On Virtualization using XEN General Setup The Machine Hardware Host Preparation (Standard UBUNTU XEN Host) Installation of the XEN Packages Modification of the Bootloader GRUB Reboot the Host System Explore Your New XEN dom0 Hardware Host Virtual Machine Preparation Start Your Virtual Machine Working with the Virtual Machines Network Setup on the Host System Start/Stop the Virtual Machines Change the Memory Allocated to the VM High Availability Shared Network Storage Solution Host Preparation Phase Configure the DRBD Device Startup the DRBD Device Setup the Filesystem on the Device Test the DRBD Raid Device Migration of the VMs Advanced tutorial (if you have time left): libvirt usage with XEN Installation of libvirt and tools VM libvirt configuration virsh usage libvirt GUI example "virt-manager" Additional Information General Setup The Machine Hardware The host systems are running Ubuntu 9.04 (Jaunty Jackalope). The following procedures will be possible on most common linux distributions with specific changes to the software installation steps. For Ubuntu we will use the Advanced Packaging Tool ( apt ) similar to Debian . RedHat or SuSE are using rpm or some GUI (Graphical User Interface) installation tool. Each workshop group has access to two hardware hosts: hostname gks- <1/2>-X .fzk.de gks- <1/2>-Y .fzk.de Replace <1/2> and X and Y with the numbers given on the workshop handout. Host Preparation (Standard UBUNTU XEN Host) 1 von 15 16.12.2009 15:13 VirtualizationWorkshop09 < GridkaSchool09 < TWiki http://www-ekp.physik.uni-karlsruhe.de/~twiki/bin/view/GridkaSchool..
    [Show full text]
  • An Initial Evaluation of Docker at the RACF
    An Initial Evaluation of Docker at the RACF Chris Hollowell <[email protected]> RHIC/ATLAS Computing Facility Brookhaven National Laboratory What is Docker? Docker is an opensource software project that helps automate, and simplify the deployment, management, and instantiation of applications in OS containers Uses containerization features built into the modern Linux kernel (2.6.26+) Cgroups Mount namespaces PID namespaces Network namespaces Red Hat only officially supports docker on RHEL7+ Available for Windows 7.1/8 – runs Docker daemon in a Linux VM Windows Server 2016 support announced using Hyper-V containers Oracle recently announced they will be integrating Docker into Solaris, utilizing Zones Initial release in March 2013, and has quickly become popular Currently the basis for Amazon's EC2 Container Service 2 Containers vs Virtualization Virtualization: Hardware virtualization Hypervisor presents fully abstracted guest instances of the host hardware platform (x86_64, etc.) Containers: OS-level virtualization OS kernel presents multiple guest instances of itself Guest OS userland may be different than the host's, assuming ABI compatibility with the running kernel Linux kernel notoriously strict about maintaining ABI compatibility For instance, allows one to run: An SL6 container on SL7 A Debian 7 container on SL7 etc. Can reduce overhead associated with starting/stopping VMs Eliminates performance penalties associated with virtualizing hardware 3 Containers vs Virtualization (Cont.) Layers of Hardware vs OS Virtualization More than
    [Show full text]
  • Ovirt Architecture
    oVirt Architecture Itamar Heim Director, RHEV-M Engineering, Red Hat oVirt Engine Architecture 1 oVirt Engine Large scale, centralized management for server and desktop virtualization Based on leading performance, scalability and security infrastructure technologies oVirt Engine Architecture 2 Kenrel-based Virtual Machine (KVM) ● Included in Linux kernel since 2006 ● Runs Linux, Windows and other operating system guests ● Advanced features ● Live migration ● Memory page sharing ● Thin provisioning ● PCI Pass-through ● KVM architecture provides high “feature-velocity” – leverages the power of Linux oVirt Engine Architecture 3 Linux as a Hypervisor? ● What makes up a hypervisor ? ● Hardware management ● Device drivers ● I/O Stack ● Resource Management ● Scheduling ● Access Control ● Power Management ● Memory Manager ● Device Model (emulation) ● Virtual Machine Monitor oVirt Engine Architecture 4 Linux as a Hypervisor? ● What makes up a hypervisor ? ● Hardware management ● Device drivers ● I/O Stack ● Resource Management Operating System Kernel ● Scheduling ● Access Control ● Power Management ● } Memory Manager ● Device Model (emulation) ● Virtual Machine Monitor oVirt Engine Architecture 5 Linux as a Hypervisor? How well does Linux perform as a hypervisor? Isn't Linux a general purpose operating system? Linux is architected to scale from the smallest embedded systems through to the largest multi-socket servers ● From cell phones through to mainframes KVM benefits from mature, time tested infrastructure ● Powerful, scalable memory manager
    [Show full text]