KVM

virtio on hardy guest and jaunty host (kvm 84) is broken

Bug #331128 reported by Jamie Strandboge
8
Affects Status Importance Assigned to Milestone
KVM
Confirmed
Undecided
Unassigned
kvm (Ubuntu)
Fix Released
High
Dustin Kirkland 
Jaunty
Fix Released
High
Dustin Kirkland 
libvirt (Ubuntu)
Invalid
High
Canonical Server
Jaunty
Invalid
High
Canonical Server
linux (Ubuntu)
Invalid
Undecided
Unassigned
Jaunty
Invalid
Undecided
Unassigned
virt-manager (Ubuntu)
Invalid
High
Unassigned
Jaunty
Invalid
High
Unassigned

Bug Description

Binary package hint: kvm

Upgraded to kvm 84 today (been running jaunty all along), and afterwards booting a 32 bit hardy installation with virtio networking would kernel panic on my 64 bit jaunty host. Using the e1000 driver allowed the guest to boot.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: kvm 1:84+dfsg-0ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: kvm
Uname: Linux 2.6.28-8-generic x86_64

Related branches

Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Changed in kvm:
importance: Undecided → Medium
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Jamie-

What's the command line are you using to run this? I'll try to reproduce it.

:-Dustin

Changed in kvm:
importance: Medium → High
status: New → Incomplete
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Yes it is still a problem. Started via virt-manager (or virsh) crashes the guest kernel.

/usr/bin/kvm -S -M pc -m 384 -smp 1 -name sec-hardy-i386 -uuid c28d7c53-0da0-75c0-b360-df536d434f51 -monitor pty -pidfile /var/run/libvirt/qemu//sec-hardy-i386.pid -boot c -drive file=/srv/vms/kvm/sec-hardy-i386/root.qcow2,if=ide,index=0,boot=on -net nic,macaddr=00:16:36:70:61:a2,vlan=0,model=virtio -net tap,fd=18,script=,vlan=0,ifname=vnet1 -serial none -parallel none -usb -vnc 127.0.0.1:2

libvirt xml:
<domain type='kvm'>
  <name>sec-hardy-i386</name>
  <uuid>c28d7c53-0da0-75c0-b360-df536d434f51</uuid>
  <memory>393216</memory>
  <currentMemory>393216</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
      <source file='/srv/vms/kvm/sec-hardy-i386/root.qcow2'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <interface type='network'>
      <mac address='00:16:36:70:61:a2'/>
      <source network='default'/>
      <model type='virtio'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'/>
  </devices>
</domain>

Changed in kvm:
status: Incomplete → Confirmed
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

$ dpkg -l|grep kvm
ii kvm 1:84+dfsg-0ubuntu7 Full virtualization on i386 and amd64 hardwa
ii kvm-source 1:84+dfsg-0ubuntu7 Source for the KVM driver

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Jamie-

Try adding "-net user" to the end of the kvm command.

So:
 $ /usr/bin/kvm -S -M pc -m 384 -smp 1 -name sec-hardy-i386 -uuid c28d7c53-0da0-75c0-b360-df536d434f51 -monitor pty -pidfile /var/run/libvirt/qemu//sec-hardy-i386.pid -boot c -drive file=/srv/vms/kvm/sec-hardy-i386/root.qcow2,if=ide,index=0,boot=on -net nic,macaddr=00:16:36:70:61:a2,vlan=0,model=virtio -net tap,fd=18,script=,vlan=0,ifname=vnet1 -serial none -parallel none -usb -vnc 127.0.0.1:2 -net user

This is working like a champ for me, with a Jaunty host, and both Hardy and Jaunty guests:
 $ kvm -hda hardy-server.img -cdrom ../iso/ubuntu-8.04.1-server-amd64.iso -net nic,model=virtio -net user

:-Dustin

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I'm marking this against virt-manager, since kvm with the right parameter works.

Would it make sense to get virt-manager (and/or libvirt-bin) to append the "-net user" bit automatically?

:-Dustin

Changed in virt-manager:
importance: Undecided → High
status: New → Confirmed
Changed in kvm:
status: Confirmed → Triaged
Revision history for this message
Brazen (jdinkel) wrote :

I'm having this problem, too, using bridge networking with a virtio nic. Using "-net user" is not an option. I'm using Jaunty Alpha 6 as the host and Ubuntu Hardy as the guest.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I don't use '-net user'. I use nat with dnsmasq (ie, all the networking goodness that libvirt is supposed to give you) and using '-net user' would be a major usability problem for me.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

virt-manager is not the culprit because virsh does not work either. It is perhaps libvirt, but may still be kvm.

Changed in virt-manager (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Steve Beattie (sbeattie) wrote :

Assigning this to the server team.

Changed in kvm:
assignee: nobody → canonical-server
Revision history for this message
Brazen (jdinkel) wrote :

I haven't tried any other OSes as the guest other than Hardy and now Vista, but FYI - Vista DOES work with virtio.

Revision history for this message
Soren Hansen (soren) wrote :

"-net user" is not a solution. It hooks the nic into the usermode networking stack which is almost never what we want to do.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

I can confirm this problem. Just tried to install 8.04.2 into a newly create VM under Jaunty and the installation process repeatedly hangs after network detection. This persisted until the default NIC definition was removed and replaced by an e1000 NIC.

Steve Beattie (sbeattie)
Changed in libvirt:
assignee: nobody → canonical-server
importance: Undecided → High
status: New → Incomplete
Revision history for this message
Jamin W. Collins (jcollins) wrote :

How is this bug report incomplete? What additional information is necessary? This has been confirmed by multiple users.

Changed in libvirt (Ubuntu Jaunty):
status: Incomplete → Confirmed
Revision history for this message
gernonimo (gernotk) wrote :

I also can confirm this bug and i hope it will be resolved until the final release. Thank You.

Revision history for this message
danielk (danielk-cuymedia) wrote :

I believe virtio may be a red herring, this appears to be a problem with any bridge set up using /etc/libvirt/qemu/networks/default.xml

By replacing it with default0.xml default1.xml (where %d is replaced with the appropriate number), changing my vm's virsh XML to use those instead of default, then running 'virsh net-undefine default' and then running net-define + net-start for each of the new defaultX.xml's I was able to start some VM's.. the model type emulated appeared to have no effect.

Note: Some of my attempted fixes caused CPU sucking infinite loops, and others disassociated libvirt from the running kvm, so backup your disk images before trying to get qemu/kvm/libvirt running in jaunty.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Jamie said he's experiencing this using the module from kvm-source... Can anyone else confirm the problem using the stock kvm module shipping with the kernel (ie, no kvm-source installed)?

:-Dustin

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Also, try as I might, I have not been able to reproduce this problem using kvm alone on the command line (without libvirt).

I see that libvirt was merged twice, from 0.4.6-5ubuntu2 to 0.5.1-4ubuntu1, and then to 0.6.0-1ubuntu1 shortly before Jamie's report. I'm thinking that there may have been a regression somewhere in there.

I have posted a message to the kvm upstream mailing list, asking if anyone there is familiar with the problem.

Finally, I'm marking this 'Incomplete' against kvm (but leaving it open against libvirt) until someone can show me how to reproduce this problem using KVM alone.

:-Dustin

Changed in kvm (Ubuntu Jaunty):
status: Triaged → Incomplete
Changed in kvm:
importance: Unknown → Undecided
status: Unknown → New
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I've added a task against linux for this bug.

I found the following upstream kernel commit (which is in our Jaunty), but not in Hardy. I think it might be worth testing a Haryd guest with this patch applied.

 * http://<email address hidden>/msg39122.html

:-Dustin

Changed in linux (Ubuntu Jaunty):
status: New → Fix Released
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Invalid against the kernel. This patch is applied to both hardy and jaunty. Sorry for the noise.

:-Dustin

Changed in linux (Ubuntu Jaunty):
status: Fix Released → Invalid
Changed in libvirt (Ubuntu Jaunty):
status: Confirmed → Invalid
Changed in kvm (Ubuntu Jaunty):
assignee: canonical-server → kirkland
status: Incomplete → In Progress
Changed in kvm:
status: New → Confirmed
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Okay, with some help from upstream kvm (Anthony Liguori), we have a workaround for this issue in KVM itself.

Basically, Hardy's kernel does not support GSO (general segment offload). However, recent kvm/libvirt changes are now utilizing GSO.

In the KVM userspace code, we are going to disable this support for all guests until upstream designs a workable mechanism for the host sensing guest support for GSO and use it opportunistically. Uploading to Jaunty now.

:-Dustin

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package kvm - 1:84+dfsg-0ubuntu10

---------------
kvm (1:84+dfsg-0ubuntu10) jaunty; urgency=low

  * debian/patches/virtio-net_disable_gso.patch: hardy guest kernels
    do not have working gso support. Disable it for everyone until
    we have a work around, LP: #331128.

 -- Dustin Kirkland <email address hidden> Thu, 02 Apr 2009 11:08:34 -0500

Changed in kvm (Ubuntu Jaunty):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.