KVM Forum 2018

Recently a new speculative execution side channel was unvealed, which
could potentially result in leakage of arbitrary memory contents into
unprivileged virtual machines on most recent Intel CPUs. This
presentation will give insights as to what the L1 Terminal Fault (L1TF)
Spectre vulnerability is. It will show how it can be exploited and based
on that knowledge it will take a look at how KVM mitigates those
issues. It will also show performance penalties these mitigations incur.

On top of that, the presentation will present an alternative work in
progress approach to mitigate L1TF that may recover some of the
performance penalties by leveraging unrelated CPU features.

Is it safe to use QEMU to do X? This talk explains the security model and use cases that QEMU is designed for.

Understanding the security model is critical for deploying virtual machines as well as contributing code to QEMU. This talk gives an overview of the attack surfaces, including emulated devices, the monitor, remote desktop, disk images, and the CPU accelerators.

Virtual machines offer isolation from each other and the host if QEMU is configured properly. Most of these best practices are encapsulated in libvirt, but not all users choose to use it, so it is worth understanding them.

Finally, no discussion of security in QEMU would be complete without reviewing CVEs and the lessons learnt from them.

KVM is a hypervisor offering strong hardware isolation of a guest from it's hosts.

Containers are now a new software based isolation mechanism for workloads, and it might be a small surprise to see that KVM is surfacing in this context quite often.

In this talk we'll look at how KVM is used on the containers and Kubernetes context.
Specifically we'll be looking at the projects KubeVirt, Katacontainers, gVisor, and virtlet, to understand how KVM is used by them to support certain use-cases.

So you came for the glory of being listed as a maintainer, only to discover that work is continuing to pile up, random people are bothering you on mailing lists, and users are asking for help to actually use your code?

Fear not, this talk is here to help. It will explore some strategies for handling contributions and discussions that leave you breathing space while still encouraging people to do more good work. After all, a burned out maintainer is bad news for everyone.

Overcommitting memory is a useful tool for increasing VM density but typically comes with a increased administration cost as either a) "safe" memory limits need to configured for each VM; or b) unexpected performance problems need to be identified and addressed.

An automatic and lightweight method for determining a VMs working set is described with suggestions on how this could be used in clustered and non-clustered environments to increase VM density with less of an administrative burden.

The presentation also includes a look at the simple model of Linux's paging subsystem that was used to rapidly prototype and evaluate the method's behaviour with different workloads.

With huge servers like IBM z there are many resources available so it was quite obvious to test the limits of libvirt. For example, one of the questions was how fast and how many minimal guests could be started in a short time period. How high is the system load for that? In times of CI and TDD this is especially interesting since thousands of guests are started and destroyed for regression tests.

This presentation will give an overview of bottlenecks in libvirt, what the reasons are and what problems came up during these tests.