Virtio with multiple devices of the same type

Hello guys,

Bug: A virtual machine/guest can only have one virtio block device and one virtio network device.

Example command line:

qemu-system-x86_64 -drive file=disk.qcow2,if=virtio,boot=on -net nic,model=virtio,macaddr=50:18:99:55:4E:43 -net tap -net nic,model=virtio,macaddr=51:17:99:55:4D:43 -net tap

What will happen is the virtual machine will boot, and slowly grind to a halt with the two network interfaces not working at all.

qemu-system-x86_64 -drive file=disk.qcow2,if=virtio,boot=on -drive file=disk2.qcow2,if=virtio

With this one, instead of getting two virtual disks, the kernel hangs on bootup.

qemu-system-x86_64 -drive file=disk.qcow2,if=virtio,boot=on -net nic,model=virtio,macaddr=50:18:99:55:4E:43 -net tap -net nic,model=rtl8139,macaddr=51:17:99:55:4D:43 -net tap

With this one, even though only the first network device is a Virtio one, neither work.

When only using ONE virtio block and ONE virtio net, it works as it's supposed to.

This is observed :

* On a 64 bit host with an Intel Q6600 cpu
* Host is 64 bit, guest 64 bit.
* latest Linux git kernel (which has the new virtio code in it from Rusty) both for host and guest
* the latest KVM userspace (with --with-patched-kernel or by syncing to the latest kvm git tree)
* the behaviour with the network devices is observed regardless of whether the network drive is compiled in or modular.

I was wondering if this is helpful or can be replicated, if not perhaps my guest which is running Archlinux64 is doing something strange.

Regards,

Will Trives

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Hi Will,

Here's what I'm observing:

* I can create two block devices just fine.
* There are IRQ routing issues when I try to create 3 block devices, if
I pass -no-acpi when starting the guest, I can use 24 virtio block devices without a problem
* hw/virtio-net.c needs to be aware of reset to cancel any pending tx
timers. I have a patch that fixes this. I'll send it out tomorrow after more testing
* I can't seem to use more than two virtio_net devices when using -net
tap. When using -net user, I can create up to 8 virtio network devices (and they seem to work).
* QEMU has a hard limit of 32 PCI devices. Right now, we just get a
SEGV when we exceed this.

So I think our problems are:

* Something is goofy with ACPI and PCI interrupt routing.
-no-kvm-irqchip does not help the situation
* I need to send out a patch to make virtio_net reset aware
* -net tap is broken for more than 1 network device (at least with virtio)
* QEMU should allow more than 32 PCI devices.

Please try your tests again with -no-acpi and -net user and let me know if that prevents the problem. Thanks for testing!

Regards,

Anthony Liguori

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

You need to place the two nics on separate qemu vlans:

qemu-system-x86_64 -drive file=disk.qcow2,if=virtio,boot=on -net nic,model=virtio,macaddr=50:18:99:55:4E:43.vlan=0 -net tap,vlan=0 -net nic,model=virtio,macaddr=51:17:99:55:4D:43,vlan=1 -net tap,vlan=1

(a qemu vlan is just a virtual ethernet segment, not 802.3q (or whatever it's called) vlan)).

Ideally it should work without this, but there's a bug in one of the virtio optimizations that prevents it from working correctly.

Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/