Virtualization Food Fight. Rik van Riel

Transcription

1 Virtualization Food Fight Rik van Riel May 11, 2007

2 Virtualization Food Fight Upstream technologies are in flux Xen, KVM, paravirt_ops, VMI,... Technological differences, advantages and disadvantages What usually happens upstream What Red Hat is doing to keep the future compatible What you can do to stay compatible Use libvirt

3 How it began 2004: Enterprise Linux companies start looking for virtualization technology 2005: Xen is the best performing and most promising, gets adopted 2006: bugs get shaken out of Xen, all year long Other virt projects: I guess Xen isn't perfect, maybe we have a chance Other virt code gets submitted to linux kernel mailing list Xen, KVM, VMI, lguest, : KVM and common paravirt infrastructure merged upstream Several startups and a little trash talking involved

4 The technologies Xen KVM kvm xen Lguest (aka lhype aka rustyvisor) VMI paravirt_ops

5 The players XenSource Wants Xen to be the technology of choice Qumranet Wants KVM to be the technology of choice Vmware Wants Vmware with VMI to be the technology of choice Linux Kernel community Wary of maintaining many conflicting code bases Red Hat Wants a best of breed code base for virtualization Wants forward compatibility for current users

6 Upstream considerations One code base High performance Easy to maintain Leverages existing code (avoids code duplication) Compatible with the existing hypervisors Developers play well with the community Best of breed software takes the best bits from different projects

7 The technologies Xen KVM kvm xen Lguest (aka lhype aka rustyvisor) VMI paravirt_ops

8 Paravirt, full virt and more Paravirtualization Run a modified guest OS Extremely fast Binary rewriting / JIT Some x86 instructions are not virtualizable Scan all code and dynamically recompile it Reasonably fast, but very complex and could break with new instructions Hardware assisted virtualization Needs Intel VT or AMD V capable processor Coopvirt Based on a full virtualization base Some guest OS modifications for efficiency only

9 Paravirtualization benefits Performance Better timekeeping Steal time Timer interrupt Profiling SMP scalability Memory resizing CPU hotplug

10 Hypervisor vs Linux based Should we have a hypervisor? Small hypervisor Hardware compatibility Code duplication and complexity Ubiquity OS independance Maintenance issues

11 Upstream will win Maintaining a fork takes a lot of effort Distributions will use whatever is upstream And enhance it if necessary Upstream choses on technical merit Upstream requires cooperation Upstream makes inter distro compatibility the default The technologies that get merged upstream win Ubiquity Maintainability Quality control

12 Safe predictions... Insert grain of salt here. All the code will live in the upstream Linux kernel source tree Except the user space management code Little or no code duplication between Linux kernel and virtualization layer Xen guests are able to run Fully virtualized guests will run on Intel VT or AMD V CPUs Paravirt drivers for FV guests for extra performance Virtualization code is switched in at boot time through paravirt_ops Libvirt and libvirt based applications will just work

13 Out on a limb I don't know if this will happen. There will be no hypervisor on 64 bit architectures Linux itself is the basis The hypervisor layer for i686 will be truly small Linux will be the basis for most things The i686 hypervisor layer will be a Linux kernel module The only Xen code remaining will be drivers, xenbus and timer infrastructure The code will be different from any single project today Linus likes to pick and choose the best bits

14 Red Hat wishes and requirements Our future virtualization technology should: Run existing RHEL4 and RHEL5 Xen guests efficiently We want you to use RHEL5 virtualization The kvm xen kernel module could do this Reduce maintenance hassles Build from one source tree instead of keeping two trees in sync Little or no code duplication between kernel and hypervisor Fixing ACPI or IRQ routing in only one code base Manageable with the same system management tools Libvirt, virt manager, virt factory,... User created management tools

15 What Red Hat is doing Actively involved in all the virtualization projects upstream Xen, KVM, lguest paravirt_ops Libvirt Enable the various virtualization technologies in Fedora Fedora 7 has both Xen and KVM Both work through libvirt, virt manager, etc... Engaged with the developers of all the projects out there They know what we need and why

16 Red Hat virtualization management Libvirt the virtualization API Virsh a command line virtualization management tool Virt manager a graphical virtualization management tool Virtinst a python library and tool to simplify provisioning guest VMs Cobbler/koan PXE, kickstart and virt provisioning Puppet configuration management tools RHN software updates, provisioning, monitoring Virt factory web based virtualization management with an appliance focus

17 What you can do Future proof your data center Build your tools around libvirt They should just work if the underlying virtualization technology changes Why build your own tools? Get involved with the open source ones... We give you the source code, no need to start from scratch We welcome your input Code Feature requests Let us know your plans and wishes

18 Conclusions Virtualization technology will change upstream RHEL4 and RHEL5 guest VMs will be compatible with RHEL6 virtualization Use libvirt to future proof your data center tools More info on