XPDS16: Scope and Performance of Credit-2 Scheduler. - Anshul Makkar, Ctirix Systems UK Ltd.

•Télécharger en tant que PPTX, PDF•

0 j'aime•1,029 vues

Credit 2 Scheduler was designed with the following goals in mind: to be functionally complete, have algorithmic improvements, be scalable, and have improved performance compared to Credit 1 Scheduler. Various tests were performed measuring boot times, login times, network throughput, and storage performance on systems with varying numbers of VMs, CPUs, RAM, and storage configurations. Credit 2 Scheduler demonstrated improvements over Credit 1 Scheduler across most of the metrics tested.

Technologie

 Credit 2 designed for following goals in mind:
 Functionally Complete
 Algorithmic improvement
 Scalable
 Improved Performance

BootStorm: Total duration from invoking 1st VM start until nth VM finishes logging in
Credit1 : Yellow, credit2 : Blue
System: 4 socket, 64 core, 64 logical processor.126 VMs with 1 GB RAM each Guest : Win7_64

Bootstorm: Longest-gap-between-consecutive-invocations-of-VM-start
credit1 : Yellow, Credit2 : Blue
System:126 VMs with 1 GB RAM each Guest: Win7_64

Bootstorm : Duration of nth VM cloned.
credit1 : Blue , credit2 : Yellow .
System: 4 Hosts, each with 4 socket 64 cores 64 logical processor. 100 VMs cloned per host with 1 vcpu each.

LogVSI: Time taken by each session to finish in each VM.
credit1 : Yellow, Credit2: Blue
System: 4 socket, 60 cores, 120 logical processor. 600 VMs with 1 vcpu each.
Credit1
Credit2

Vm-vm intrahost nw throughput sum of threads over time.
Credit1: Blue, Credit2: Yellow
System: 2 socket , 12 cores, 24 logical Processor. 20 Debian 6b VMs with 1 vcpu each, 1 vif.

Vm-vm intrahost nw throughput individual threads over time.
Credit1: Blue, Credit2: Yellow
System: 2 socket , 12 cores, 24 logical Processor. 20 Debiaan 6 VM with 1 vcpu and 1 vif.

vm-vm nvif interhost network throughput sum of threads in all vifs (Jumbo)
credit1 : Blue, credit2 : Yellow
System: 8 cores, 16 logical processors. 20 Debian 6 VMs with 1 VIF each and 1 vcpu
Credit1

vm-vm nvif interhost nw throughput for each thread per vf pair. (Jumbo)
credit1 : Blue, Credit2 : Yellow
System: System: 8 cores, 16 logical processors. 20 Debian 6 VMs with 1 VIF each and 1 vcpu
Credit1
Credit2

vm-vm nvif interhost nw throughput for each thread over time.. (Jumbo)
credit1 : Blue, credit2 : Yellow.
System: 2 socket , 2 cores, 1 Guest Debian6, 1 vcpus, 512 MB RAM
Credit1

vm-vm nvif interhost network throughput sum of threads in all vifs
credit1 : Blue, credit2 : Yellow
System: 8 cores, 16 logical processors. 20 Debian 6 VMs with 1 VIF each and 1 vcpu

vm-vm nvif interhost nw throughput for each thread per vf pair.
credit1 : Blue, Credit2 : Yellow
System: System: 8 cores, 16 logical processors. 20 Debian 6 VMs with 1 VIF each and 1 vcpu

vm-vm nvif interhost nw throughput for each thread over time..
credit1 : Blue, credit2 : Yellow.
System: 2 socket , 2 cores, 1 Guest Debian6, 1 vcpus, 512 MB RAM

Aggregate disk throughput (in bytes per second)
Credit1: 1480864 : Blue
Credit2: 1480954 : Yellow
System: 4 socket, 64 core, 64 logical processor. 1 VM with 1 vcpu.
Credit1

Aggregate disk throughput (in bytes per second)
Credit1: Blue
Credit2: Yellow
System: 4 socket, 64 core, 64 logical processor. 20 VM per SE with 1 vcpu.

Aggregate disk throughput (in bytes per second) 512 bytes block size.
Credit1: Blue
Credit2: Yellow
System: 4 socket, 64 core, 64 logical processor. 20 VM per SE with 1 vcpu.

Aggregate disk throughput (in bytes per second) block size 2048 bytes
Credit1: Blue
Credit2: Yellow
System: 4 socket, 64 core, 64 logical processor. 20 VM per SE with 1 vcpu.

Aggregate disk throughput (in bytes per second) block size 32768
Credit1: Blue
Credit2: Yellow
System: 4 socket, 64 core, 64 logical processor. 20 VM per SE with 1 vcpu.

Aggregate disk throughput (in bytes per second) block size: 131072 bytes
Credit1: Blue
Credit2: Yellow
System: 4 socket, 64 core, 64 logical processor. 20 VM per SE with 1 vcpu.

Credit 1 Credit 2
Audio Comparison
1 socket 4 core, 8 logical processor
4 Centos 6 VMs with 2 VCPU each running Linux kernel compilation.
1 Windows VM with 1 VCPU running Windows Player.

Contenu connexe

Tendances

了解网络

Feng Yu

KCC_Final.pdf

Oleg Sehelin

Cassandra Day SV 2014: Basic Operations with Apache Cassandra

Log

Project1

NetApp mailbox disk

Tendances (6)

了解网络

KCC_Final.pdf

Cassandra Day SV 2014: Basic Operations with Apache Cassandra

Log

Project1

NetApp mailbox disk

En vedette

Migration of virtual machines without guest downtime is a key feature for hypervisors. Sadly, not all hardware is the same, and keeping guests running in a heterogeneous environment takes a lot of care. Normally, features are advertised via the CPUID instruction, but life is never as simple as we would like. Andrew will discuss what information needs to be controlled, what information can and can't be controlled, and how it applies to Xen guests.

XPDS16: CPUID handling for guests - Andrew Cooper, Citrix

The Linux Foundation

Since its inception, the Xen Orchestra project which uses AGPLv3, always had a philosophy to listen and engage the community. User feedback shaped our initial concept, which first targeted system administrators. Eventually, our users drove us to support cloud-scale deployments supporting up to 2000 VM's. Retaining simplicity in usage and installation, while evolving Xen Orchestra to cloud scale posed many challenges. This led us to build many new features such ACLs, self-service, live charts, config drive management, and more, forced us to constantly evolve our architecture. First we will show how user needs changed our architecture, and how we implemented challenging problems such as user permissions, ACLs, Containers in a virtualized infrastructure and self service. We will conclude with a short demo, what is next and a lessons learned.

XPDS16: Xen Orchestra: building a Cloud on top of Xen - Olivier Lambert & Jul...

The Linux Foundation

Subtitle: Reducing the OS burden while taking advantage of new hardware features Xen is a hypervisor using a microkernel design that allows running multiple concurrent operating systems on the same hardware. One of the key features of Xen is that it is OS agnostic, meaning that any OS (with proper support) can be used as a host. Xen has a long history going back to the 90s when it was designed and the early 2000s when it was released. As a consequence of this, many of the assumptions and virtualization techniques backed into it are now superseeded by new hardware features, that make virtualization more transparent from an OS point of view. This talk provides an overview on the different kind of guests supported by Xen and how these new hardware features are used in order to improve and evolve them. It also describes the design and implementation of a new guest type, called PVHv2, and how it can be used as a control domain (Dom0). Also see: https://fosdem.org/2017/schedule/event/iaas_towahvm/

Fosdem 17 - Towards a HVM-like Dom0 for Xen

The Linux Foundation

As the number of contributions grow, reviewer bandwidth becomes a bottleneck; and maintainers are always asking for more help. However, ultimately maintainers must at least Ack every patch that goes in; so if you're not a maintainer, how can you contribute? Why should anyone care about your opinion? This talk will try to lay out some advice and guidelines for non-maintainers, for how they can do code review in a way which will effectively reduce the load on maintainers when they do come to review a patch.

XPDS16: Patch review for non-maintainers - George Dunlap, Citrix Systems R&D...

The Linux Foundation

The ARM architecture strongly recommends to use a break-before-make when changing translation table entries whenever certain conditions are met. Failing to do so may result in getting TLB conflicts or breaking the coherency. During this session, we will introduce break-before-make and when the code handling page tables should use it. We will also discuss the modifications required in Xen to avoid breaking the coherency.

XPDS16: Keeping coherency on ARM - Julien Grall, ARM

The Linux Foundation

We have been working to get Xen up and running on self-boot Intel® Xeon Phi processors to build HPC clouds. We see several challenges because of the unique (but not unusual for HPC) hardware technologies and performance requirements. For example, such hardware technologies include 1) >256 CPUs, 2) MCDRAM (high-bandwidth memory), 3) integrated fabric (i.e. Intel® Omni-Path). Unlike the “coprocessor“ model, supporting self-boot with >256 CPUs has various implications to Xen, including scheduling and scalability. We need to allow user applications to use MCDRAM directly to perform optimally. Also, we need to enable the integrated HPC fabric for the VM to use by direct I/O assignment. In addition, we have only a single VM on each node to meet the high-performance requirements of HPC clouds. This (i.e. non-shared) model allowed us to optimize Xen more. In this talk, we share our design and lessons, and discuss the options we considered to achieve high-performance virtualization for HPC.

XPDS16: High-Performance Virtualization for HPC Cloud on Xen - Jun Nakajima &...

The Linux Foundation

This presentation is based on the technical hurdles we overcame when building a commercial product on the introspection capabilities of the Xen hypervisor. Mihai Dontu will relate the importance of the x86 emulator, the need for a more focused effort on its completeness and correctness, the problems encountered, and the solutions adopted. He will also approach the subject of performance, for which hypervisor features that were not meant to be in the hot path had to be punctually reworked to solve a key requirement for making a theoretical product a commercial reality.

XPDS16: Hypervisor-based Security: Vicarious Learning via Introspektioneerin...

The Linux Foundation

Adding support for you new shiny board in Xen on ARM is a simple task once you get a kernel running on bare metal. This session will cover the different steps to port Xen on ARM from the firmware to the shell prompt in DOM0. We will give you tips on the common pitfalls when you have your hypervisor, or your DOM0 kernel crashing. We will also provide suggestion on how to debug when the console is not working.

XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARM

The Linux Foundation

XPDS16: Xen Scalability Analysis - Weidong Han, Zhichao Huang & Wei Yang, Huawei

The Linux Foundation

GPU virtualization is hot in cloud usages including VDI, media processing, etc. While Intel GVT-g (a.k.a XenGT) helps unleash those compelling usages on Intel Processor Graphics, new requirements are emerging such as VM live migration with vGPU. In this session we will introduce the challenges of supporting vGPU live migration on current migration framework, then elaborate techniques to bring vGPU live migration into XenGT.

XPDS16: Live Migration of vGPU - Xiao Zheng, Intel Asia-Pacific Research & De...

The Linux Foundation

Live virtual machine migration is a crucial operation in the day-to-day management of modern cloud environments. For systems with the highest security requirements, standard migration protocols must be ammended to protect against a number of failure or cyberattack scenarios. In this presentation, we explore these scenarios and discuss extensions to various Xen toolstacks to protect against potential vulnerabilities.

XPDS16: Making Migration More Secure - John Shackleton, Adventium Labs

The Linux Foundation

A year has passed since the last Xen Developer Summit and it is time to announce the quiet progress made on the libvirt libxl driver and related tooling. New features include memory, cpu, block device, and network interface statistics reporting, support for pvUSB, support for migration stream V2, peer-to-peer migration, UEFI for HVM guests via OVMF, and domain capabilities reporting to name a few. There are also many noteworthy improvements such as better conversion of xl.cfg to/from libvirt domXML, allowing users to easily switch between the xl+libxl and libvirt+libxl toolstacks. The summit also provides an opportunity to discuss new proposals such as better control of domain placement on NUMA systems, exposing Xen's cpu pool feature in libvirt, supporting non-volatile memory for UEFI variables, and improved capabilities reporting. Much of libvirt's value for Xen is in the tools built upon it: virt-manager, virt-viewer, virt-install, virt-builder, kimchi, OpenStack nova, etc. These tools also deserve a quick status update as they relate to Xen. The audience is encouraged to participate, e.g. by requesting a sorely missing feature, warning of an upcoming Xen change that may affect libvirt, or simply suggesting a change that makes virtualization management life a bit easier.

XPDS16: libvirt and Tools: What's New and What's Next - James Fehlig, SUSE

The Linux Foundation

Many projects start out with the intention of staying single license FOSS projects. As your project grows, reality hits: some components or files may need to use different licenses than originally anticipated. There are many reasons why this can happen: you may need to interface with projects of another license, you may want to import code from other projects or your developers may not understand the subtleties of the licenses in use. Besides the obvious challenges of managing mixed license FOSS projects, such as license compatibility and tracking what licenses you use, you are running the risk of exposing your project to unintended consequences. This talk will explore unintended consequences, risks and best practices using some examples from the recent history of the Xen Project. In particular we will cover: 1. Refactoring can lead to licensing changes: best practices and unintended consequences when importing code from elsewhere. Making code archeology easy from a licensing perspective and why it is important. 2. A worked example of a license change of a key component: process, pain points, their causes and how they could have been avoided 3. The perils of LGPL/GPL vX (or Later): the unintended consequences of not providing pre-defined copyright headers in your source base We will conclude with a summary of lessons and best practices.

Fosdem17 - Mixed License FOSS Projects

The Linux Foundation

XPDS16: Xen Development Update

The Linux Foundation

With increasing GPU-intensive workloads deployed on Cloud, the Cloud service providers are seeking for practical and efficient GPU virtualization solutions. vGPU scalability can significantly reduce the TCO (Total Cost of Ownership) and improve the ROI (Return on Investment) for Cloud providers. One of the technical challenges to scale up vGPU is due to the graphic memory resource limitation, which constrains the total number of guest virtual GPU instances. In this talk, Intel's GVT team will introduces a scalable GPU virtualization solution (code name: gScale) to break the hardware limitation of global graphics memory space. The evaluation shows that gScale can have 5x vGPU scalability in guest Linux and 4x vGPU scalability in guest Windows.

XPDS16: Live scalability for vGPU using gScale - Xiao Zheng, Intel

The Linux Foundation

Xen is a mature enterprise-grade virtual machine with many advanced security features which are unique to Xen. For this reason it's the hypervisor of choice for the NSA, the DoD, and the new QubesOS Secure Desktop project. While much of the security of Xen is inherent in its design, many of the advanced security features, such as stub domains, driver domains, XSM, and so on are not enabled by default. This session will describe all of the advanced security features of Xen, and the best way to configure them for the Cloud environment. When the audience leaves, they should have a general framework to evaluate the security of their system, know the key security features of Xen, and have a basic framework of knowledge to help them make sense of the documentation. This talk will *not* go into mind-numbing detail about specific commands to type or configuration options.

LCEU13: Securing your cloud with Xen's advanced security features - George Du...

The Linux Foundation

Xen summit amd_2010v3

The Linux Foundation

While datacenters are increasingly adopting VMs to provide elastic cloud services, they still rely on traditional TCP for congestion control. In this talk, I will first show that VM scheduling delays can heavily contaminate RTTs sensed by VM senders, preventing TCP from correctly learning the physical network condition. Focusing on the incast problem, which is commonly seen in large-scale distributed data processing such as MapReduce and web search, I find that the solutions that have been developed for *physical* clusters fall short in a Xen *virtual* cluster. Second, I will provide a concrete understanding of the problem, and reveal that the situations that when the sending VM is preempted versus when the receiving VM is preempted, are different. Third, I will introduce my recent attempts on paravirtualizing TCP to overcome the negative effect caused by VM scheduling delays.

XPDS13: On Paravirualizing TCP - Congestion Control on Xen VMs - Luwei Cheng,...

The Linux Foundation

AMD recently disclosed new security technologies which leverage hardware-based memory encryption to provide additional security protections. This talk will focus primarily on technology which supports encrypted virtual machines for extra isolation and protection from the hypervisor itself. The presentation will discuss the technical details of this technology with a focus on how it can be integrated within the Xen infrastructure.

XPDS16: AMD's virtualization memory encryption technology - Brijesh Singh, A...

The Linux Foundation

Cobbler Summit - Automated Xen VM Deployment

Abhishek Singh

En vedette (20)

XPDS16: CPUID handling for guests - Andrew Cooper, Citrix

XPDS16: Xen Orchestra: building a Cloud on top of Xen - Olivier Lambert & Jul...

Fosdem 17 - Towards a HVM-like Dom0 for Xen

XPDS16: Patch review for non-maintainers - George Dunlap, Citrix Systems R&D...

XPDS16: Keeping coherency on ARM - Julien Grall, ARM

XPDS16: High-Performance Virtualization for HPC Cloud on Xen - Jun Nakajima &...

XPDS16: Hypervisor-based Security: Vicarious Learning via Introspektioneerin...

XPDS16: Porting Xen on ARM to a new SOC - Julien Grall, ARM

XPDS16: Xen Scalability Analysis - Weidong Han, Zhichao Huang & Wei Yang, Huawei

XPDS16: Live Migration of vGPU - Xiao Zheng, Intel Asia-Pacific Research & De...

XPDS16: Making Migration More Secure - John Shackleton, Adventium Labs

XPDS16: libvirt and Tools: What's New and What's Next - James Fehlig, SUSE

Fosdem17 - Mixed License FOSS Projects

XPDS16: Xen Development Update

XPDS16: Live scalability for vGPU using gScale - Xiao Zheng, Intel

LCEU13: Securing your cloud with Xen's advanced security features - George Du...

Xen summit amd_2010v3

XPDS13: On Paravirualizing TCP - Congestion Control on Xen VMs - Luwei Cheng,...

XPDS16: AMD's virtualization memory encryption technology - Brijesh Singh, A...

Cobbler Summit - Automated Xen VM Deployment

Similaire à XPDS16: Scope and Performance of Credit-2 Scheduler. - Anshul Makkar, Ctirix Systems UK Ltd.

Ceph Day New York 2014: Ceph, a physical perspective

Ceph Community

Unikernels have been demonstrated to deliver excellent performance in terms of throughput and latency, while providing high isolation. However they have also been shown to underperform in some types of workloads when compared to a generic OS like Linux. In this presentation, we demonstrate that certain types of workloads - web servers, microservices, and other stateless and/or serverless apps - can greatly benefit from OSv optimized networking stack and other features. We describe number of experiments where OSv outperforms Linux guest: most notably we note 1.6 throughput (req/s) and 0.6 latency improvement (at p99 percentile) when running nginx and 1.7 throughput (req/s) and 0.6 latency improvement (at p99 percentile) when running simple microservice implemented in Golang. We also show that OSv' small kernel, low boot time and memory consumption allow for very high density when running server-less workloads. The experiment described in this presentation shows we can boot 1,800 OSv microVMs per second on AWS c5n.metal machine with 72 CPUs (25 boots/sec on single CPU) with guest boot time recorded as low as 8.98ms at p50 and 31.49ms at p99 percentile respectively. Lastly we also demonstrate how to automate the build process of the OSv kernel tailored exactly to the specific app and/or VMM so that only the code and symbols needed are part of the kernel and nothing more. OSv is an open source project and can be found at https://github.com/cloudius-systems/osv.

OSv Unikernel — Optimizing Guest OS to Run Stateless and Serverless Apps in t...

ScyllaDB

In this deck from the DDN User Group at SC14, Tommy Minyard from TACC presents: Site-wide Storage Use Case and Early User Experience with Infinite Memory Engine. "IME unleashes a new I/O provisioning paradigm. This breakthrough, software defined storage application introduces a whole new new tier of transparent, extendable, non-volatile memory (NVM), that provides game-changing latency reduction and greater bandwidth and IOPS performance for the next generation of performance hungry scientific, analytic and big data applications – all while offering significantly greater economic and operational efficiency than today’s traditional disk-based and all flash array storage approaches that are currently used to scale performance." Watch the video presentation: http://insidehpc.com/2014/12/site-wide-storage-use-case-early-user-experience-infinite-memory-engine/

Tacc Infinite Memory Engine

inside-BigData.com

QEMU Disk IO Which performs Better: Native or threads?

Pradeep Kumar

Kvm performance optimization for ubuntu

Sim Janghoon

Advanced performance troubleshooting using esxtop

Alan Renouf

Mes conteneurs JVM sont en prod, oups ils se font oomkill, oups le démarrage traîne en longueur, oups ils sont lent en permanence. Nous avons vécu ces situations. Ces problèmes émergent parce qu’un conteneur est par nature un milieu restreint. Sa configuration a un impact sur le process Java, cependant ce process a lui aussi des besoins pour fonctionner. Il y a un espace entre la heap Java et le RSS : c’est la mémoire off-heap et elle se décompose en plusieurs zones. À quoi servent-elles ? Comment les prendre en compte ? La configuration du CPU impacte la JVM sur divers aspects : Quelles sont les influences entre le GC et le CPU ? Que choisir entre la rapidité ou la consommation CPU au démarrage ? Au cours de cette université nous verrons comment diagnostiquer, comprendre et remédier à ces problèmes.

Devoxx Fr 2022 - Remèdes aux oomkill, warm-ups, et lenteurs pour des conteneu...

Jean-Philippe BEMPEL

了解Cpu

Feng Yu

z/VM 6.3 - Mudanças de Comportamento do hypervisor para suporte de partições ...

Joao Galdino Mello de Souza

Wp intelli cache_reduction_iops_xd5.6_fp1_xs6.1

Nuno Alves

Detailed technical overview of a IBM's System x3850 x5 Intel processor-based server. The x3850 X5 server allows freedom of choice with extremely flexible configurations plus memory expansion capabilities. A modular building block design lets you customize your system for current needs while providing the ability to react to changing workloads. Expand your 4-socket, 64-DIMM x3850 X5 to 4 sockets and 96 DIMMs or up to 8 sockets and 128 DIMMs. Reallocate resources as your environment changes. The x3850 X5 meets your needs today, while providing an easy, cost-effective upgrade path to change your environment when you’re ready.

IBM System x3850 X5 Technical Presentation

Cliff Kinard

Amd accelerated computing -ufrj

Roberto Brandao

How Ceph performs on ARM Microserver Cluster

Aaron Joue

SUSE Expert Days Paris 2018 - SUSE HA Cluster Multi-Device

SUSE

Jugal Parikh, Microsoft Holly Stewart, Microsoft Humans are susceptible to social engineering. Machines are susceptible to tampering. Machine learning is vulnerable to adversarial attacks. Singular machine learning models can be “gamed” leading to unexpected outcomes. In this talk, we’ll compare the difficulty of tampering with cloud-based models and client-based models. We then discuss how we developed stacked ensemble models to make our machine learning defenses less susceptible to tampering and significantly improve overall protection for our customers. We talk about the diversity of our base ML models and technical details on how they are optimized to handle different threat scenarios. Lastly, we’ll describe suspected tampering activity we’ve witnessed using protection telemetry from over half a billion computers, and whether our mitigation worked.

BlueHat v18 || Hardening hyper-v through offensive security research

BlueHat Security Conference

By Alberto García. qcow2 is QEMU's native file format for storing disk images. One of its features is that it grows dynamically, so disk space is only allocated when the virtual machine needs to store data. This makes the format efficient in terms of space requirements, but has an impact on its I/O performance. This presentation will describe some of those performance problems and will discuss possible ways to address them. Some of them can be solved by simply adjusting configuration parameters, others require improving the qcow2 driver in QEMU, and others need extending the file format itself. (c) KVM Forum 2017 October 25 - 27, 2017 Hilton Prague, Prague, Czech Republic http://events.linuxfoundation.org/events/archive/2017/kvm-forum

Improving the Performance of the qcow2 Format (KVM Forum 2017)

Igalia

WAN - trends and use cases

MarketingArrowECS_CZ

Intalio　Cloud Announcement Presentation

Tomoaki Sawada

Multi-core architectures

nextlib

200.1,2-Capacity Planning

behrad eslamifar

Similaire à XPDS16: Scope and Performance of Credit-2 Scheduler. - Anshul Makkar, Ctirix Systems UK Ltd. (20)

Ceph Day New York 2014: Ceph, a physical perspective

OSv Unikernel — Optimizing Guest OS to Run Stateless and Serverless Apps in t...

Tacc Infinite Memory Engine

QEMU Disk IO Which performs Better: Native or threads?

Kvm performance optimization for ubuntu

Advanced performance troubleshooting using esxtop

Devoxx Fr 2022 - Remèdes aux oomkill, warm-ups, et lenteurs pour des conteneu...

了解Cpu

z/VM 6.3 - Mudanças de Comportamento do hypervisor para suporte de partições ...

Wp intelli cache_reduction_iops_xd5.6_fp1_xs6.1

IBM System x3850 X5 Technical Presentation

Amd accelerated computing -ufrj

How Ceph performs on ARM Microserver Cluster

SUSE Expert Days Paris 2018 - SUSE HA Cluster Multi-Device

BlueHat v18 || Hardening hyper-v through offensive security research

Improving the Performance of the qcow2 Format (KVM Forum 2017)

WAN - trends and use cases

Intalio　Cloud Announcement Presentation

Multi-core architectures

200.1,2-Capacity Planning

Plus de The Linux Foundation

Static partitioning is used to split an embedded system into multiple domains, each of them having access only to a portion of the hardware on the SoC. It is key to enable mixed-criticality scenarios, where a critical application, often based on a small RTOS, runs alongside a larger non-critical app, typically based on Linux. The two domains cannot interfere with each other. This talk will explain how to use Xen for static partitioning. It will introduce dom0-less, a new Xen feature written for the purpose. Dom0-less allows multiple VMs to start at boot time directly from the Xen hypervisor, decreasing boot times drastically. It makes it very easy to partition the system without virtualization overhead. Dom0 becomes unnecessary. This presentation will go into details on how to setup a Xen dom0-less system. It will show configuration examples and explain device assignment. The talk will discuss its implications for latency-sensitive and safety-critical environments.

ELC2019: Static Partitioning Made Simple

The Linux Foundation

TrenchBoot is a cross-community OSS integration project for hardware-rooted, late launch integrity of open and proprietary systems. It provides a general purpose, open-source DRTM kernel for measured system launch and attestation of device integrity to trust-centric access infrastructure. TrenchBoot closes the UEFI Measurement Gap and reduces the need to trust system firmware. This talk will introduce TrenchBoot architecture and a recent collaboration with Oracle to launch the Linux kernel directly with Intel TXT or AMD SVM Secure Launch. It will propose mechanisms for integrating the Xen hypervisor into a TrenchBoot system launch. DRTM-enabled capabilities for client, server and embedded platforms will be presented for consideration by the Xen community.

XPDDS19: How TrenchBoot is Enabling Measured Launch for Open-Source Platform ...

The Linux Foundation

Artem will briefly cover what has been done since the first talk on Xen in Automotive domain back in 2013, what is going on now and what is still missing for broad adaptation of Xen in vehicles. The following topics will be covered: Embedded/automotive features of Xen Collaboration with AGL and GENIVI organizations for standardization Efforts on Functional Safety compliance Artem will also go over typical automotive use scenarios for Xen which may not be the same as generic computing use of hypervisor.

XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solu...

The Linux Foundation

XPDDS19 Keynote: Xen Project Weather Report 2019 - Lars Kurth, Director of Op...

The Linux Foundation

In recent years unikernels have shown immense performance potential (e.g., boot times of only a few ms, image sizes of only hundreds of KBs).The fundamental drawback of unikernels is that they require that applications be manually ported to the underlying minimalistic OS, needing both expert work and often considerable amount of time. The Unikraft project provides a unikernel code base and build system that significantly simplifies the building of unikernels. In addition to support for a number CPU architectures, languages and frameworks, Unikraft provides debugging and tracing features that are generally sorely missing from unikernel projects. In this talk we will talk about these features, show a set of preliminary performance numbers, and provide a roadmap for the project's future.

XPDDS19 Keynote: Unikraft Weather Report

The Linux Foundation

XPDDS19 Keynote: Secret-free Hypervisor: Now and Future - Wei Liu, Software E...

The Linux Foundation

This talk will introduce Dom0-less: a new way of using Xen to build mixed-criticality solutions. Dom0-less is a Xen feature that adds a novel approach to static partitioning based on virtualization. It allows multiple domains to start at boot time directly from the Xen hypervisor, decreasing boot times dramatically. Xen userspace tools, such as xl and libvirt, become optional. Dom0-less extends the existing device tree based Xen boot protocol to cover information required by additional domains. Binaries, such as kernels and ramdisks, are loaded by the bootloader (u-boot) and advertised to Xen via new device tree bindings. The audience will learn how to use Dom0-less to partition the system. Uboot and device tree configuration details will be explained to enable the audience to get the most out of this feature. The talk will include a status update and details on future plans.

XPDDS19 Keynote: Xen Dom0-less - Stefano Stabellini, Principal Engineer, Xilinx

The Linux Foundation

XPDDS19 Keynote: Patch Review for Non-maintainers - George Dunlap, Citrix Sys...

The Linux Foundation

This talk is a follow-up to our Summit 2017 presentation in which we covered our plans for Intel VMFUNC and #VE, as well as related use-cases. This year, we will provide a report on what we have accomplished in Xen 4.12, and what remains to be addressed. We will also give a brief status update of VMI on AMD hardware. The session will end with some real-world numbers of the Hypervisor Introspection solution running on Citrix Hypervisor 8.0 with #VE enabled.

XPDDS19: Memories of a VM Funk - Mihai Donțu, Bitdefender

The Linux Foundation

Safety certification is one of the essential requirements for software to be used in highly regulated industries. Besides technical and compliance issues (such as ISO 26262 vs IEC 611508) transitioning an existing project to become more easily safety certifiable requires significant changes to development practices within an open source project. In this session, we will lay out some challenges of making safety certification achievable in open source and the Xen Project. We will outline the process the Xen Project has followed thus far and highlight lessons learned along the way. The talk will primarily focus on necessary process, tooling changes and community challenges that can prevent progress. We will be offering an in-depth review of how Xen Project is approaching this challenging goal and try to derive lessons for other projects and contributors.

OSSJP/ALS19: The Road to Safety Certification: Overcoming Community Challeng...

The Linux Foundation

Safety certification is one of the essential requirements for software to be used in highly regulated industries. The Xen Project, a secure and stable hypervisor that is used in many different markets, has been exploring the feasibility of building safety certified products on top of Xen for a year, looking at key aspects of its code base and development practices. In this session, we will lay out the motivation and challenges of making safety certification achievable in open source and the Xen Project. We will outline the process the project has followed thus far and highlight lessons learned along the way. The talk will cover technical enablers, necessary process and tooling changes and community challenges offering an in-depth review of how Xen Project is approaching this exciting and and challenging goal.

OSSJP/ALS19: The Road to Safety Certification: How the Xen Project is Making...

The Linux Foundation

2018 saw fundamental shifts in security boundaries which were previously taken for granted. A lot of work has been done in the past 2 years, and largely in secret under embargo, but there is plenty more work to be done to strengthen the existing mitigations and to try to recover some performance without reopening security holes. This talk will look at speculative execution sidechannels, the work which has already been done to mitigate the security holes, and future work which hopes to bring some improvements.

XPDDS19: Speculative Sidechannels and Mitigations - Andrew Cooper, Citrix

The Linux Foundation

The Arm architecture provides a set of guidelines that any software should abide by when accessing the memory with MMU off and update page-tables. Failing to do so may result in getting TLB conflicts or breaking coherency. In a previous talk ("Keeping coherency on Arm"), we focused on updating safely the stage-2 (aka P2M) page-tables. This talk will focus on the boot code and Xen memory management. During this session, we will introduce some of the guidelines and when they should be used. We will also discuss how Xen boot sequence needs to be reworked to avoid breaking the guidelines.

XPDDS19: Keeping Coherency on Arm: Reborn - Julien Grall, Arm ltd

The Linux Foundation

For many years the QEMU codebase has contained PV backends for Xen guests, giving them paravirtual access to storage, network, keyboard, mouse, etc. however these backends have not been configurable as QEMU devices as their implementation did not fully adhere to the QEMU Object Model (QOM). Particularly the PV storage backend not using proper QOM devices, or qdevs, meant that the QEMU block layer needed to maintain legacy code that was cluttering up the source. This was causing push-back from the maintainers who did not want to accept any patches relating to that Xen backend until it was 'qdevified'. In this talk, I'll explain the modifications I made to QEMU to achieve 'qdevification' of the PV storage backend, how compatibility with the libxl toolstack was maintained, and what the next steps in both QEMU and libxl development should be.

XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant...

The Linux Foundation

PCI is a local computer bus for attaching hardware devices in a computer, and is the main peripheral bus on modern x86 systems. As such, having a proper way to emulate it is crucial for Xen to be able to expose both fully emulated devices or passthrough devices to guests. This talk will focus on the current status of PCI emulation in Xen, how and where it is used, what are its main limitations and future plans to improve it in order to be more robust and modular.

XPDDS19: Status of PCI Emulation in Xen - Roger Pau Monné, Citrix Systems R&D

The Linux Foundation

XPDDS19: [ARM] OP-TEE Mediator in Xen - Volodymyr Babchuk, EPAM Systems

The Linux Foundation

Xen is a very powerful hypervisor with a talented and diverse developers community. Despite the fact it's almost everywhere (from the Cloud to the embedded world), it can be difficult to set up and manage as a system administrator. General purpose distros have Xen packages, but that's just a start in your Xen journey: you need some tooling and knowledge to have a working and scalable platform. XCP-ng was built to overcome those issues: by bringing Xen to the masses with a fully turnkey distro with Xen as its core. It's the logical sequel to the XCP project, with a community focus from the start. We'll see how it happened, what we did, and what's next. Finally, we'll see the impact of XCP-ng on the Xen Project.

XPDDS19: Bringing Xen to the Masses: The Story of Building a Community-driven...

The Linux Foundation

XPDDS19: Will Robots Automate Your Job Away? Streamlining Xen Project Contrib...

The Linux Foundation

High level toolstacks for server and cloud virtualization are very mature with large communities using and supporting them. Client virtualization is a much more niche community with unique requirements when compared to those found in the server space. In this talk, we’ll introduce a client virtualization toolstack for Xen (redctl) that we are using in Redfield, a new open-source client virtualization distribution that builds upon the work done by the greater virtualization and Linux communities. We will present a case for maturing libxl’s Go bindings and discuss what advantages Go has to offer for high level toolstacks, including in the server space.

XPDDS19: Client Virtualization Toolstack in Go - Nick Rosbrook & Brendan Kerr...

The Linux Foundation

Today Xen is scheduling guest virtual cpus on all available physical cpus independently from each other. Recent security issues on modern processors (e.g. L1TF) require to turn off hyperthreading for best security in order to avoid leaking information from one hyperthread to the other. One way to avoid having to turn off hyperthreading is to only ever schedule virtual cpus of the same guest on one physical core at the same time. This is called core scheduling. This presentation shows results from the effort to implement core scheduling in the Xen hypervisor. The basic modifications in Xen are presented and performance numbers with core scheduling active are shown.

XPDDS19: Core Scheduling in Xen - Jürgen Groß, SUSE

The Linux Foundation

Plus de The Linux Foundation (20)