KVM - The Linux Kernel-Based Virtual Machine

Proxmox VE 2.0 rc1 is out

Haydn Solomon — Wed, 22 Feb 2012 18:04:11 +0000

The first release candidate of Proxmox VE 2.0 which adds high availability to its list of features is out. The main feature included with this release candidate is role based user and permissions management for all objects. The official announcement includes the following list of features with this release.

Role based user- and permission management for all objects (VM´s, storages, nodes, etc.)
Support for multiple authentication sources
Microsoft Active Directory
- LDAP
- Linux PAM
- Proxmox VE internal authentication
New Kernel, based on vzkernel-2.6.32-042stab049.6.src.rpm
vzdump uses now LZO compression by default (faster)
Countless bug fixes

You can find out more by checking out the official announcement.

How to Maximize virtio-net performance with vhost-net

Haydn Solomon — Fri, 03 Feb 2012 14:08:19 +0000

Virtio-net paravirtual drivers provide you with better network performance than emulated drivers for your guests. However you may not be taking full advantage of virtio-net if you're not making use of the linux vhost-net driver. In this post, we'll go over some configurations to ensure that you're getting maximum network performance using virtio-net and vhost-net.

The vhost architecture has been developed by Red Hat since around 2010 so it's been around for a while. The vhost-net provides much improved network performance for your guest is running virtio-net by totally bypassing qemu as a fast path for interrupting your guest. The alternative of involving qemu is very expensive due to context switches to userspace and multiple system calls. The vhost-net however runs in kernel as a kernel thread and interrups your guest with much less overhead providing near native performance.

If you're are using a management tool based on libvirt then libvirt will take care of a lot of the configuration tasks in setting up and running your guest. In order to get the best network performance for a guest running virtio-net the following conditions must be met.

virtio-net paravirtual drivers installed in the guest and the virtio nic model type selected
Your version of qemu supports vhost-net ie -netdev command option.
the vhost-net kernel module is loaded and available

So you installed the paravirtual network drivers in your guest and use virt-manager to setup your virtio nic. You've installed the most recent package of qemu-kvm. Now have you checked that vhost-net is loaded? The one common mistake I've seen many people make is assuming that vhost-net module is loaded. It's understandable too because even on a distribution like fedora, the most recent version at this time , 16, has vhost-net built into the kernel as a module so it's not loaded by default. Most people will go ahead and let virt-manager do it's magic and never bother to check that vhost-net is running.

To ensure that vhost-net is running run the following command as root in a terminal on your kvm host

modprobe vhost-net

Next verify that it's running with the following command

lsmod | grep vhost_net

You should then see output similar to the following showing that the module is loaded.

vhost_net              33675  1
macvtap                18183  3 vhost_net
tun                    22768  2 vhost_net

Now when you start your guest with virt-manager your command line generated by libvirt will contain vhost parameters. Below shows an example.

qemu     11678     1 21 Jan29 ?        1-02:11:05 /usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 2048 -smp 1,sockets=1,cores=1,threads=1 -name Hitachi-XP -uuid 848b0584-7601-efe2-72b4-f3da80187e75 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Hitachi-XP.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=c,menu=on -drive file=/home/hsolomon/images/xp-office.img,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/home/hsolomon/isos/virtio-win-1.4.0.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=19,id=hostnet0,vhost=on,vhostfd=20 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:40:4a:67,bus=pci.0,addr=0x3 -chardev tty,id=charserial0,path=/dev/ttyS0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:1,password -vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

If you need to ensure that vhost-net is loaded because you use kvm guests with virtio-net one thing you can do is add the modprobe command above to your rc.local file on your linux distribution which will run whenever your machine boots. On Red Hat based distros this file is usually located at /etc/rc.d/rc.local. Below is an example of what your file will look like.

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
modprobe vhost-net

If you have been overlooking the vhost-net module, give it a try and feel free to post comments.

First release of oVirt scheduled for Jan 31

Haydn Solomon — Thu, 26 Jan 2012 13:48:00 +0000

The first release of the RHEV-M upstream project, oVirt, is scheduled for the end of January in a few days time. This release schedule comes shortly after the recent release of RHEV 3.0. Since the project kickoff workshop was held last November, installing the ovirt-engine is a whole lot easier at least on Fedora 16. There are now instructions on the ovirt wiki page for Debian and Gentoo although the Debian link is currently broken.

There are currently nightly builds of the ovirt-node ( the managed node hypervisor ) available for you to start using. For installing the ovirt-engine ( management tool ) on Fedora 16, yum packages are available. Installation requires you to download a yum repo file, install the required packages with yum and run a handful of commands. This is a lot easier than the previous method of installation.

For more information see the oVirt wiki page.

GSoC helps improve VMDK support in KVM

Haydn Solomon — Wed, 18 Jan 2012 11:14:17 +0000

If you've ever struggled with converting a vmdk disk format to qemu's qcow format you might have better luck now. One of the projects in last years Google Summer of Code program was to improve support for vmdk within qemu. The outcome of the Summer of Code project has already been merged with upstream qemu so it's available if you pull from git.

The qemu-img binary is responsible for disk management so if you would like to try the latest (unstable) vmdk support you can run the following commands to get it.

$ git clone git://git.qemu.org/qemu.git
$ cd qemu
$ ./configure
$ make qemu-img

You can then use the qemu-img tool for managing your vmdk disk files.

So if you've given up on converting some old vmdk files, give it another try and please post feedback, comments or questions on your successes or failures.

Proxmox VE 2.0 Beta adds High Availability and KVM 1.0 packages

Haydn Solomon — Mon, 02 Jan 2012 10:52:03 +0000

Proxmox Virtual Environment (VE), the linux Debian based distribution for managing KVM and Openvz, just released it's 2.0 Beta version adding High Availability support and packages based on qemu 1.0. Along with the new high availability features comes an updated GUI for managing your HA settings and a new Datacenter summary page.

Proxmox VE has always provided good community support by way of an active forum, wiki and community bug reporting. The proxmox team have now added a youtube channel where you can find the latest tutorials and howtos on installing and configuring your virtual environment with Proxmox.

The official announcement includes links to wiki pages on Clustering, Fencing and support for Intel Modular server.

You can download this latest release at the Proxmox Download Center.

qemu 1.0 is here

Haydn Solomon — Thu, 01 Dec 2011 21:39:45 +0000

qemu 1.0 was released today right on schedule. One of the biggest changes visible to end users is added support for scsi block devices including block device passthrough through a new scsi block device. This means it will support /dev/sda devices which will help in some physical to virtual migrations scenarios. Another interesting feature is the TCI ( Tiny Code Interpreter ) for running qemu on architectures where there's no native code generated for it by qemu as explained in this post. The official list of changes that comes with qemu 1.0 can be found at the qemu 1.0 changelog page. Here's a list from the official changelog page of some of the more interesting features.

QEMU now uses a separate thread for VCPU execution similar to qemu-kvm
All image formats now support asynchronous operations
Many bugfixes around CD media changes
QEMU now supports I/O latency accounting in the monitor command "info blockstats"
The accuracy of error handling for SCSI emulation has been greatly improved
SCSI devices can now be addressed by channel, target (id) and LUN. Not all emulated HBAs will support this feature (in particular, the LSI controller will not)
SCSI CD-ROMs now report media changed events
Block device pass through is now supported through a new scsi-block device. The scsi-block device works with block devices (like /dev/sda or /dev/sr0) rather than /dev/sgN devices, and is more efficient because it does not consume arbitrary amounts of memory when the guest does large data transfers
SCSI CD-ROMs now support DVD images
SLIRP can process ARP replies and gratuitous ARP requests from the guest
Now supports discarded blocks in dynamically-sized images
QEMU now supports the new Cortex-A15 (ARM) instructions in linux-user mode (via "-cpu any")
QEMU now supports DC232b and FSF xtensa CPU cores
QEMU now supports sim (similar to Tensilica ISS) and LX60/LX110/LX200 machines
QEMU now supports live migration using image files like QCOW2 on shared storage

For the full changelog list see the 1.0 changelog page. You can expect to see these changes coming soon to downstream qemu-kvm in your favourite linux distro.

To get started you can download qemu 1.0 at the qemu download page.

qemu 1.x on the horizon

Haydn Solomon — Mon, 14 Nov 2011 14:02:50 +0000

The next release of upstream qemu is scheduled for December 1, 2011 and will be tagged as version 1.0. Some release candidates have already been published so you can start playing with them if you're interested. Below is a list of the main targeted features with a short description of each.

Memory API

The new memory api will be based on new memory modelling which more closely reflects they way memory is implemented in real computer systems. This feature is targeted at developers more than users so this will be transparent if you're an end user. The new memory api is currently implemented on top of the old api which limits the capabilities of the new api but this is a first step until users of the old api has been migrated. There's still a long list of things todo before the new api is fully implemented.

Support for Tensilica Xtensa Processor

Emulation is being added for the Tensilica Xtensa processor family. Tensilica develops processor technology primary for use in embedded systems. Currently development allows you to run linux on sim and lx60 boards. You can find more information on this project at the qemu support for Xtensa wiki page.

SCSI Improvements

Due to some shortcomings with the current virtio-block implementation, the KVM development community has decided to implement a virtio-scsi storage stack. One of the major shortcomings of the virtio-blk design is it's limited feature set. Further to this, adding new features, even trivial ones, requires a change to the spec for virtio-block. Additionally, the virtio-block implementation has a limitation of one pci device per disk which is not very scalable.

The new virtio-scsi storage stack will keep the efficient design and performance of virtio-blk while providing a richer feature set. The feature set will depend on the target and not on virtio-scsi itself and there will be multiple target choices eg. qemu and lio. Scalability will be in the order of thousands of disks per pci device and devices will be true scsi devices providing good physical to virtual and virtual to virtual migration.

Version 1.0 of qemu will see improvements in the SCSI subsystem as a pre-requisite for the development of virtio-scsi. The list of improvements include the following

Improved modelling of scsi requests
Flexible scsi addressing
Improved consistency with the SCSI spec
Improved support for emulated SCSI cdrom
Migration support

These improvements have already been done to the SCSI subsystem and will be available in the upcoming qemu 1.0.

TCI ( Tiny Code Interpreter )

TCI is a new highly experimental feature that will improve the TCG code generator by running tcg generated code on any 32 or 64 bit host. Previous to TCI, the code generator, known as TCG, only allowed qemu to run on the most important host architectures such as x86, arm, mips, s390 and sparc. TCI will not create native code but rather bytecode which is interpreted so it will not depend on the host running qemu. The idea is that by adding a code generator for some virtual machine and using an interpreter for the generated bytecode, you can support almost any host. The only difference to running qemu with or without TCI will be speed.

The current version available for download is release candidate 1.

Get RHEV-M ( ovirt ) up and Running - oVirt Relaunch Day 1

Haydn Solomon — Wed, 02 Nov 2011 13:29:32 +0000

The most interesting session on Day 1 of the oVirt relaunch was about getting the recently open sourced RHEV-M ( now known as oVirt ) up and running on your Desktop. Right now this process is not very automated; it involves downloading and installing many packages, some from source and some using the Fedora yum package installer. Yum because currently the project is very Fedora centric but there was discussion about how to port it to other distros since SUSE and Canonical is also attending this workshop. Ironically the presenter who gave this talk demonstrated on a Gentoo distro so it is possible to run on another Linux distribution at this time.

If you're interested in getting it up and running right now, follow the instructions at the Building the Ovirt Engine page which gives step by step instructions.

For the list of talks scheduled during this workshop, see the ovirt Workshop wiki page .

KVM Forum 2011 videos available online

Haydn Solomon — Mon, 17 Oct 2011 19:08:02 +0000

Thanks to Redhat developer Richard Jones for his blog post pointing out this information. KVM Forum 2011 was recently held in Vancouver and videos of the talks are now available online.

You can find them at the following links

Even if you attended you may have missed some of these posted sessions. Enjoy.

oVirt relaunch on Nov 1-3 2011

Haydn Solomon — Thu, 22 Sep 2011 05:40:49 +0000

The ovirt project for managing open source virtualization will be getting a second wind thanks to the Open Virtualization Alliance. The project is scheduled for a relaunch in early November in San Jose California with a workshop at Cisco's main campus. The workshop will be held on November 1 - 3 and will include breakout sessions for learning and hacking.

This project will fill a serious gap in open virtualization management toos and provide an alternative for businesses interested in deploying KVM in production environments. oVirt will be the opensource project behind Red Hat's RHEV-M product. For more information here's the announcement and a website with more information.