QEMU 2.4.0 has just been released, and among many other things it comes with some of the stuff I have been working on lately. In this blog post I am going to talk about disk I/O limits and the new feature to group several disks together.
Disk I/O limits
Disk I/O limits allow us to control the amount of I/O that a guest can perform. This is useful for example if we have several VMs in the same host and we want to reduce the impact they have on each other if the disk usage is very high.
The I/O limits can be set using the QMP command block_set_io_throttle, or with the command line using the throttling.* options for the -drive parameter (in brackets in the examples below). Both the throughput and the number of I/O operations can be limited. For a more fine-grained control, the limits of each one of them can be set on read operations, write operations, or the combination of both:
- bps (throttling.bps-total): Total throughput limit (in bytes/second).
- bps_rd (throttling.bps-read): Read throughput limit.
- bps_wr (throttling.bps-write): Write throughput limit.
- iops (throttling.iops-total): Total I/O operations per second.
- iops_rd (throttling.iops-read): Read I/O operations per second.
- iops_wr (throttling.iops-write): Write I/O operations per second.
In addition to that, it is also possible to configure the maximum burst size, which defines a pool of I/O that the guest can perform without being limited:
- bps_max (throttling.bps-total-max): Total maximum (in bytes).
- bps_rd_max (throttling.bps-read-max): Read maximum.
- bps_wr_max (throttling.bps-write-max): Write maximum.
- iops_max (throttling.iops-total-max): Total maximum of I/O operations.
- iops_rd_max (throttling.iops-read-max): Read I/O operations.
- iops_wr_max (throttling.iops-write-max): Write I/O operations.
One additional parameter named iops_size allows us to deal with the case where big I/O operations can be used to bypass the limits we have set. In this case, if a particular I/O operation is bigger than iops_size then it is counted several times when it comes to calculating the I/O limits. So a 128KB request will be counted as 4 requests if iops_size is 32KB.
- iops_size (throttling.iops-size): Size of an I/O request (in bytes).
All of these parameters I’ve just described operate on individual disk drives and have been available for a while. Since QEMU 2.4 however, it is also possible to have several drives share the same limits. This is configured using the new group parameter.
The way it works is that each disk with I/O limits is member of a throttle group, and the limits apply to the combined I/O of all group members using a round-robin algorithm. The way to put several disks together is just to use the group parameter with all of them using the same group name. Once the group is set, there’s no need to pass the parameter to block_set_io_throttle anymore unless we want to move the drive to a different group. Since the I/O limits apply to all group members, it is enough to use block_set_io_throttle in just one of them.
Here’s an example of how to set groups using the command line:
-drive if=virtio,file=hd1.qcow2,throttling.iops-total=6000,throttling.group=foo -drive if=virtio,file=hd2.qcow2,throttling.iops-total=6000,throttling.group=foo -drive if=virtio,file=hd3.qcow2,throttling.iops-total=3000,throttling.group=bar -drive if=virtio,file=hd4.qcow2,throttling.iops-total=6000,throttling.group=foo -drive if=virtio,file=hd5.qcow2,throttling.iops-total=3000,throttling.group=bar -drive if=virtio,file=hd6.qcow2,throttling.iops-total=5000
In this example, hd1, hd2 and hd4 are all members of a group named foo with a combined IOPS limit of 6000, and hd3 and hd5 are members of bar. hd6 is left alone (technically it is part of a 1-member group).
I am currently working on providing more I/O statistics for disk drives, including latencies and average queue depth on a user-defined interval. The code is almost ready. Next week I will be in Seattle for the KVM Forum where I will hopefully be able to finish the remaining bits.
See you in Seattle!
Working with open hardware
Some weeks ago at LinuxCon EU in Barcelona I talked about how to use QEMU to improve the reliability of device drivers.
At Igalia we have been using this for some projects. One of them is the Linux IndustryPack driver. For this project I virtualized two boards: the TEWS TPCI200 PCI carrier and the GE IP-Octal 232 module. This work helped us find some bugs in the device driver and improve its quality.
Now, those two boards are examples of products available in the market. But fortunately we can use the same approach to develop for hardware that doesn’t exist yet, or is still in a prototype phase.
Such is the case of a project we are working on: adding Linux support for this FMC Time-to-digital converter.
The Open Hardware repository hosts a number of projects that have been published under this license.
Why we use QEMU
So we are developing the device driver for this hardware, as my colleague Samuel explains in his blog. I’m the responsible of virtualizing it using QEMU. There are two main reasons why we want to do this:
- Limited availability of the hardware: although the specification is pretty much ready, this is still a prototype. The board is not (yet) commercially available. With virtual hardware, the whole development team can have as many “boards” as it needs.
- Testing: we can test the software against the virtual driver, force all kinds of conditions and scenarios, including the ones that would probably require us to physically damage the board.
While the first point might be the most obvious one, testing the software is actually the one we’re more interested in.
My colleague Miguel wrote a detailed blog post on how we have been using QEMU to do testing.
Writing the virtual hardware
Writing a virtual version of a particular piece of hardware for this purpose is not as hard as it might look.
First, the point is not to reproduce accurately how the hardware works, but rather how it behaves from the operating system point of view: the hardware is a black box that the OS talks to.
Second, it’s not necessary to have a complete emulation of the hardware, there’s no need to support every single feature, particularly if your software is not going to use it. The emulation can start with the basic functionality and then grow as needed.
We need to emulate both cards in order to have a working system, but the emulation is, at the moment, treating both as if they were just one, which makes it a bit easier to have a prototype and from the device driver point of view doesn’t really make a difference. Later the emulation can be split in two as I did with with TPCI200 and IP-Octal 232. This would allow us to support more FMC hardware without having to rewrite the bridging code.
There’s also code in the emulation to force different kind of scenarios that we are using to test if the driver behaves as expected and handles errors correctly. Those tests include the simulation of input in the any of the lines, simulation of noise, DMA errors, etc.
And we have written a set of test cases and a continuous integration system, so the driver is automatically tested every time the code is updated. If you want details on this I recommend you again to read Miguel’s post.
We are sponsoring the event and we have a couple of presentations this year, one about QEMU, device drivers and industrial hardware (which I gave today, slides here) and the other about the Grilo multimedia framework (by Juan Suárez).
We’ll be around the whole week so you can come and talk to us anytime. You can find us at our booth on the ground floor, where you’ll also be able to see a few demos of our latest work and get some merchandising.
IndustryPack drivers for Linux
In the past months we have been working at Igalia to give Linux support to IndustryPack devices.
IndustryPack modules are small boards (“mezzanine”) that are attached to a carrier board, which serves as a bridge between them and the host bus (PCI, VME, …). We wrote the drivers for the TEWS TPCI200 PCI carrier and the GE IP-OCTAL-232 module.
The drivers are available in latest Linux release (3.6 as of this writing) but if you want the bleeding-edge version you can get it from here (make sure to use the staging-next branch).
IndustryPack emulation for QEMU
Along with Samuel’s work on the kernel driver, I have been working to add emulation of the aformentioned IndustryPack devices to QEMU.
The work consists on three parts:
- TPCI200, the bridge between PCI and IndustryPack.
- The IndustryPack bus.
- IPOCTAL-232, an IndustryPack module with eight RS-232 serial ports.
I decided to split the emulation like this to be as close as possible to how the hardware works and to make it easier to reuse the code to implement other IndustryPack devices.
The emulation is functional and can be used with the existing Linux driver. Just make sure to enable CONFIG_IPACK_BUS, CONFIG_BOARD_TPCI200 and CONFIG_SERIAL_IPOCTAL in the kernel configuration.
I submitted the code to QEMU, but it hasn’t been integrated yet, so if you want to test it you’ll need to patch it yourself: get the QEMU source code and apply the TPCI200 patch and the IP-Octal 232 patch. Those patches have been tested with QEMU 1.2.0.
And here’s how you run QEMU with support for these devices:
$ qemu -device tpci200 -device ipoctal
The IP-Octal board implements eight RS-232 serial ports. Each one of those can be redirected to a character device in the host using the functionality provided by QEMU. The ‘serial0‘ to ‘serial7‘ parameters can be used to specify each one of the redirections.
$ qemu -device tpci200 -device ipoctal,serial0=pty
With this, the first serial port of the IP-Octal board (‘/dev/ipoctal.0.0.0‘ on the guest) will be redirected to a newly-allocated pty on the host.
Having virtual hardware allows us to test and debug the Linux driver more easily.
In November I’ll be in Barcelona with the rest of the Igalia OS team for LinuxCon Europe and the KVM Forum. I will be talking about how to use QEMU to improve the robustness of device drivers and speed up their development..
See you in Barcelona!
Third day of GUADEC already. And in Coruña!
This is a very special city for me.
I came here in 1996 to study Computer Science. Here I discovered UNIX for the first time, and spent hours learning how to use it. It’s funny to see now those old UNIX servers being displayed in a small museum in the auditorium where the main track takes place.
It was also here where I learnt about free software, installed my first Debian system, helped creating the local LUG and met the awesome people that founded Igalia with me. Then we went international, but our headquarters and many of our people are still here so I guess we can still call this home.
So, needless to say, we are very happy to have GUADEC here this time.
I hope you all are enjoying the conference as much as we are. I’m quite satisfied with how it’s been going so far, the local team has done a good job organising everything and taking care of lots of details to make the life of all attendees easier. I especially want to stress all the effort put into the network infrastructure, one of the best that I remember in a GUADEC conference.
At Igalia we’ve been very busy lately. We’re putting lots of effort in making WebKit better, but our work is not limited to that. Our talks this year show some of the things we’ve been doing:
- A bright future for GNOME.
- WebKitGTK+: current status and roadmap.
- Web to the core.
- OCRFeeder – OCR made easy on GNOME.
- Grilo: present and future.
- GNOME 3 accessibility: State of the Union.
- Skeltrack: A Free Software library for skeleton tracking.
- Sketching interactions.
- Sandbox all the pipelines!.
- Web application stores in GNOME.
And we have a booth next to the info desk where you can get some merchandising and see our interactivity demos.
In case you missed the conference this year, all talks are being recorded and the videos are expected to be published really soon (before the end of the conference).
So enjoy the remaining days of GUADEC, and enjoy Coruña!
And of course if you’re staying after the conference and want to know more about the city or about Galicia, don’t hesitate to ask me or anyone from the local team, we’ll be glad to help you.
My name is Alberto Garcia and this is my first (well, second) post in Planet Debian. So I’ll introduce myself.
I’m a free software developer and enthusiast from Galicia, Spain. I studied computer science at the Corunha University, where I first heard about GNU/Linux and Debian. After leaving university I co-founded Igalia with a group of friends. We’ve been working on lots of different things during all these years, but some projects we’ve been particularly involved in include GNOME, Maemo/MeeGo and WebKit.
Although I’ve been using Debian for more than a decade now (my first -and still running!- installation was in 1997) and I’m quite familiar with the distribution, it wasn’t until a few years ago that I started maintaining packages officially.
Apart from software, my other main hobby is music. When I’m not using my computer you’ll find me at some concert (preferably small bands: I hate long queues, crowded places and being far from the stage). It’s no coincidence that my first Debian package was a Last.fm player 😉
I don’t have much more to add. I’d like to thank Ana for adding me to the planet, and I’m proud to be part of the Debian community!
FileTea is a free, web-based file sharing system that just works. It only requires a browser, and no user registration is needed. If you want to know more about it, you can read my previous blog post. For a more detailed description, read Nathan Willis’s excellent article on LWN.net. There have been a few changes since that article (HTTPS support in particular) but it’s still the best one you can find on the net.
Igalia still provides a FileTea server at http://filetea.me/, that you can use to share your files and see how it works. We plan to keep offering this service, but you don’t need to trust it/depend on it anymore: now you can apt-get install filetea and have your own.
FileTea is a simple way to send files to other people: drag a file into your web browser, give the link to your friends and they can start downloading it right away.
This is not a substitute for DropBox and the like. FileTea is not a file hosting service: the web server is only used to route the traffic, no data is stored there.
You can see it as a web-based P2P file sharing system, or a replacement for good ol’ DCC SEND. You don’t need to worry about firewalls or redirections: if you can surf the web, you can send the file. The only client that you need is your browser.
FileTea is a project developed by my fellow Igalian Eduardo Lima, and you can see more details about it here. It was written on top of EventDance, a peer-to-peer inter-process communication library based on GLib and also written by him (see also The Web jumps into D-Bus).
FileTea is free software and you can download it and install it in your machine.
We have also set up a server at http://filetea.me/.
Important: this is still an alpha release and our bandwith is limited so bear with us if you find any problem
Dear Last.fm fellows, I’ve just released Vagalume 0.8.5.
These are the most important changes since the previous version:
- Improved proxy support.
- Support for low-bitrate streams, to save bandwidth.
- GTK+ 3 support.
- New Catalan translation.
This makes 0.8.5 the first Vagalume to support GTK+ 3, and this without even needing to break backwards compatibility. So now it compiles with any GTK+ version from (at least) 2.6 till 3.0
Source code, as usual, here. Binaries very soon in your favourite distro.