OA - Ubuntu
A blog about Ubuntu, mobile GIS and archaeology

KVM 84 backported in Hardy

Mar 29, 2009 by Yann Hamon

Dustin Kirkland announced a few weeks ago that he was trying to backport KVM-84 to Ubuntu Hardy. This was made following a post on the ubuntuserver blog that described the way KVM-84 would be backported: ~ubuntu-virt PPA -> hardy-backports -> hardy-{proposed|security} -> hardy-updates.
This raises some interesting questions. But let's define the context.

At OA, we've been using KVM in production since the very beginning - we started testing KVM in april 2008, deployed in late may, and started to move critical pieces of infrastructure on it later in the year. Some bugs surfaced after a while: problems with virtio networking, problems with the default NIC as well, performance problems with SMP, networking problems with SMP, need to use QCOW2 for windows VMs (although virt-install doesn't create QCOW images by default)... We managed to workaround most of them, mostly by using e1000 as NIC and living with the SMP slowness. We reported these bugs in launchpad and landscape, and Canonical had quite a tough time helping us with these issues.

In Ubuntu Hardy, the version of KVM used is kvm-62. The current version of KVM is KVM-84 (if not newer already) - and as you can see on the mailing list the development is going on really quickly. KVM is an opensource project created by QUMRANET and now belonging to Redhat. So, when you arrive on the mailing list or the IRC channel saying "I am running a one year old version on a concurrent distro and there is a bug", you'd be lucky to get help from a KVM dev (ie, a redhat engineer).

This is made worse by the development model, which is somewhat weird, as afaik there is no "stable" version (or only stable versions, pick the one you like). New versions get released all the time, fixing bugs in the previous versions. This is making the life of Ubuntu packagers hard, as they need to backport security and critical functionality bugs.

To summarize: It is extremely hard for Canonical to support packages for longer than the upstream would support them. There is no chance for Canonical to support KVM-62 in 3 years time, as some bugs may be fixed so much later that the code would have changed significantly, making the patches not that easy to apply (I am also still wondering how Canonical plans to support PHP4 in Dapper in 2 years time).

Backporting KVM-84 is a truly significant move, that acknowledges the lack of control on the supported packages, but also that confirms the commitment of Canonical to support packages during the whole support period. As a customer we are thrilled to see that. I think it is also the first time Ubuntu will push a new version of such an important package in -upgrades, that introduces so many new changes (but I may be wrong on that). It is quite an interesting precedent if you ask me :)

Now KVM is at the core of our infrastructure and I just can't afford to upgrade and experience new, significant bugs. I will be helping kirkland in testing kvm-84, reporting as many issues as I can, but I must say I am quite eager (and scared at the same time) to see how Canonical will handle quality assurance on this. I really hope they get it right :]


I'm with GregKH on all the backporting problems. Distros should just ship newer kernels.

Instead of exensive kernel hackers doing stupid backporting they should ship newer kernels and pay for better QA. Way better use of resources.

For some strange reason they don't want to (certification doesn't count IMNSHO.)

Maybe Ubuntu needs a "LTS and a half"

Posted by kragil on March 29, 2009 at 12:45 PM GMT+00:00 #

I'm with the guy who said "users have enough bugs already like a non-functioning bluetooth stack, we should spare them the qa"

Posted by Vadim P. on March 29, 2009 at 02:38 PM GMT+00:00 #

Hi Yann,

Very interesting post, I am passing this to the support team and to Dustin at Canonical. I always enjoy reading your comments about Ubuntu.

Posted by Fabian Rodriguez on March 29, 2009 at 03:05 PM GMT+00:00 #

The real QA problem was choosing to go with new and unprovem KVM instead of old, but very stable Xen for the LTS release.

Posted by Aigars Mahinovs on March 29, 2009 at 05:22 PM GMT+00:00 #

Hello Algars, I would tend to disagree. I am happier running KVM from the beginning, even if I get some problems as it is a new project, than running XEN and moving to KVM 2 or 3 years later - including migration costs and learning time.

Our needs in term of virtualisation are rather low, and so far KVM has proven to fit our needs - excluding the few problems I mentioned. We were also aware that it was a young project when we chose it.

KVM is an exciting project, but is quite critical and moving along very fast, so it needs special care. I am happy with the road Canonical is taking - providing support for sometimes bleeding edges projects (like eucalyptus).

Posted by Yann on March 29, 2009 at 05:31 PM GMT+00:00 #

Post a Comment:
Comments are closed for this entry.