Network Virtualization and Lightning Talks
1. VFIO - Are We There Yet?
2. KVM Network performance and scalability
3. Enabling overlays for Network Scaling
4. Marrying live migration and device assignment
5. Lightning Talks
- QEMU disaggregation - Stefano Stabellini [Slides](http://
- Xenner- Alexander Graf
- From Server to Mobile: Different Requirements/
=== VFIO - Are We There Yet? ===
VFIO is new userspace driver interface intended to generically enable assignment of devices into qemu virtual machines. VFIO has had a bumpy road upstream and is currently into it's second redesign. In this talk we'll look at the new design, the status of the code, how to make use of it, and where it's going. We'll also look back at some of the previous designs to show how we got here. This talk is intended for developers and users interested in the evolution of device assignment in qemu and kvm as well as those interested in userspace drivers.
Topic Lead: Alex Williamson
Alex has been working on virtualization for over 5 years and concentrates on the I/O side of virtualization, especially assignment of physical devices to virtual machines. He is a member of the Red Hat Virtualization team.
=== KVM Network performance and scalability ===
In this presentation we will discuss ongoing work to improve KVM networking I/O performance and scalability. We will share performance numbers taken using both vertical (multiple interfaces) and horizontal (many VMs) to highlight existing bottleneck's in the KVM stack as well as improvements observed with pending changes. These experiments have shown impressive gains can be obtained by using per-cpu vhost threads and leveraging hardware offloads. These offloads include flow steering and interrupt affinity.
This presentation intends to highlight ongoing research from various groups working on the Linux kernel, KVM, and upper layer stack. Finally we will propose a path to include these changes in the upstream projects. This should be of interest to KVM developers, kernel developers, and anyone using a virtualized environment.
Topic Lead: John Fastabend <email address hidden>
Required attendees: Vivek Kashyap, Shyam Iyer
=== Enabling overlays for Network Scaling ===
Server virtualization in the data-center has increased the density of networking endpoints in a network. Together with the need to migrate VMs anywhere in the data-center this has surfaced network scalability limitations (layer 2, cross IP subnet migrations, network renumbering).
The industry has turned its attention towards overlay networks to solve the network scalability problems. The overlay network concept defines a domain connecting virtual machines belonging to a single tenant or organization. This virtual network may be built across the server hypervisors which are connected over an arbitrary topology. This talk will give an overview of the problems sought to be solved through the use of overlay networks, and discusses the active proposals such as VxLAN, NVGRE, and DOVE Network. We further will delve into options for implementing the solutions on Linux.
Topic Lead: Vivek Kashyap <email address hidden>
Vivek works in IBM's Linux Technology Center. Vivek has worked on Linux resource management, delay-accounting, Energy & hardware management, and authored InfiniBand and IPoIB networking protocols, and worked on standardizing and implementing the IEEE 802.1Qbg protocol on network switching.
=== Marrying live migration and device assignment ===
Device assignment has been around for quite some time now in virtualization. It's a nice technique to squeeze as much performance out of your hardware as possible and with the advent of SR-IOV it's even possible to pass a "virtualized" fraction of your real hardware to a VM, not the whole card.
The problem however is that you lose a pretty substantial piece of functionality: live migration.
The most commonly approach used to counterfight this for networking is to pass 2 NICs to the VM. One that's emulated in software and one that's the actually assigned device. It's the guest's responsibility to treat the two as a union and the host needs to be configured in a way that allows packets to float the same way through both paths. When migrating, the assigned device gets hot unplugged and a new one goes back in on the new host. However, that means that we're exposing crucial implementation details of the VM to the guest: it knows when it gets migrated.
Another approach is to do the above, but combine everything in a single guest driver, so it ends up invisible to the guest OS. That quickly becomes a nightmare too, because you need to reimplement network drivers for your specific guest driver infrastructure, at which point you're most likely violating the GPL anyway.
So what if we restrict ourselves to a single NIC type? We could pass in an emulated version of that NIC into our guest, or pass through an assigned device. They would behave the same. That also means that during live migration, we could switch between emulated and assigned modes without the guest even realizing it.
But maybe others have more ideas on how to improve the situation? The less guest intrusive it is, the better the solution usually becomes. And if it extends to storage, it's even better
Topic Lead: Alexander Graf <email address hidden>
Alexander has been a steady and long time contributor to the QEMU and KVM projects. He maintains the PowerPC and s390x parts of QEMU as well as the PowerPC port of KVM. He tends to become active, whenever areas seem weird enough for nobody else to touch them, such as nested virtualization, mac os virtualization or ahci. Recently, he has also been involved in kicking off openSUSE for ARM. His motto is なんとかなる.