Description of problem: When I tried to start the Windows 7 guest machine when I set its NIC model to "virtio", I receive the following error message: qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: vhost-net support is not compiled in qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: vhost-net requested but could not be initialized qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: Device 'tap' could not be initialized The relevant command generated by virtual machine manager 0.9.1 is ".... -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2c:7c:d2,bus=pci.0,addr=0x3 ...." However, from what I googled, it appears to me vhost-net should be supported by Fedora 17. In fact, even "lsmod" shows the following: [awang@mars ~]$ lsmod | grep vhost vhost_net 33675 0 macvtap 18183 1 vhost_net tun 22768 4 vhost_net Version-Release number of selected component (if applicable): [awang@mars ~]$ rpm -qa kernel kernel-3.2.5-3.fc16.x86_64 [awang@mars ~]$ rpm -qa | grep virt python-virtinst-0.600.1-1.fc16.noarch libvirt-python-0.9.6-4.fc16.x86_64 virt-manager-common-0.9.1-2.fc16.noarch python-virtkey-0.50-9.fc15.x86_64 virt-manager-0.9.1-2.fc16.noarch libvirt-0.9.6-4.fc16.x86_64 libvirt-client-0.9.6-4.fc16.x86_64 How reproducible: Create a guest machine, set the NIC model to "virtio" and start it. Steps to Reproduce: 1. 2. 3. Actual results: The guest machine won't run. Expected results: The guest machine starts. Additional info: The complete Windows 7 guest machine configuration is attached.
libvirt will only add vhost options to the qemu commandline if two conditions are both true: 1) the vhost-net module is loaded (detected by presence of /dev/vhost-net 2) the output of "qemu-kvm -help" contains the string ",vhost=", indicating that qemu supports this. It appears there has been a two tiered failure of qemu-kvm in this case: 1) The Fedora build of qemu-kvm was configured to exclude vhost-net support, and 2) When qemu-kvm is built without vhost-net support, it fails to remove those parts of the help text. I'm moving this bug to the qemu package. The Fedora build of qemu should of course have vhost-net enabled. Beyond that, qemu upstream should be patched to not include mention of vhost-net options if vhost-net support is not built into the binary.
Thanks for the quick response. If I didn't misunderstand you, you're saying vhost-net is not enabled by default Fedora qemu-kvm package. However, when I downloaded the qemu source package, I noticed it states in the SPEC file that: * Mon Jan 30 2012 Justin M. Forbes <jforbes> - 2:0.15.1-4 - Add vhost-net to kvm.modules - Fix USB passthrough assert on packet completion (#769625) I verified that I have that version installed. [awang@mars rules.d]$ rpm -q qemu-kvm qemu-kvm-0.15.1-4.fc16.x86_64 I don't know what's the other way to verify whether it is actually loaded. All other indicators seems showing it's loaded. [awang@mars rules.d]$ ls -l /dev/vhost-net crw-------. 1 root root 10, 58 Mar 1 19:16 /dev/vhost-net [awang@mars rules.d]$ qemu-system-x86_64 --help | grep vhost -net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off] use vhost=on to enable experimental in kernel accelerator use vhostforce=on to force vhost on for non-MSIX virtio guests use 'vhostfd=h' to connect to an already opened vhost net device [awang@mars rules.d]$ lsmod | grep vhost vhost_net 33675 0 macvtap 18183 1 vhost_net tun 22768 2 vhost_net Any way, I will wait for the response from the qemu group. Thanks.
This message: > qemu-system-x86_64: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: > vhost-net support is not compiled in is printed by qemu-kvm, not by libvirt, and is present in the compiled binary only if qemu was built with CONFIG_VHOST_NET not #defined. So there are two options: 1) you have a locally built qemu-kvm on your system that was built with vhost-net support configured out, or 2) the F17 build of qemu-kvm has vhost-net support configured out.
I recompiled remu packages with vhost-net enabled, at least I thought so, and I'm still seeing the same error messages. I have the build log attached. I'm little bit confused now. Which component need vhost-net support enabled, Kernel, libvirt or qemu? How can I verify whether the vhost-net is "enabled" in those modules? As far as I can tell, Kernel module is loaded. [awang@mars ~]$ lsmod | grep vhost vhost_net 33675 0 macvtap 18183 1 vhost_net tun 22768 2 vhost_net Since The virtual machine manager GUI generated the proper qemu command, I assume libvirt shouldn't be blamed neither.
Created attachment 567127 [details] rpm build output.
The only checks in libvirt are at runtime, as given in Comment 1. The message you are seeing only exists in the qemu-kvm binary, and only exists if it was built with CONFIG_VHOST_NET *not* defined (see Comment 3). The kernel module is a part of the kernel, not a part of qemu or of libvirt. I'm not sure how/why it could be that rpmbuild is showing you that vhost-net support is enabled for the build, but in the binary it actually isn't, but that appears to be what is happening (look for CONFIG_VHOST_NET in config.h of the build directory). BTW, why is this BZ filed against F17, but the rpm has fc16 (as do the build logs). The qemu build for F17 is currently using qemu-1.0, not qemu-.15.
The OS is F16. I lost track to the version numbers. :-)
*** Bug 799185 has been marked as a duplicate of this bug. ***
From the koji build logs for F17 and F16 we see: vhost-net support yes We then proceed to actually build hw/vhost_net.c and don't see any errors there. The help is accurate here, and qemu-kvm should support vhost_net
Arnold, Can you please tell us the build of qemu-kvm you are using ("rpm -qa qemu-kvm")? Also, did you get the binary from the Fedora repos, or did you build it yourself?
The qemu version is [awang@mars ~]$ rpm -q qemu-kvm qemu-kvm-0.15.1-4.fc16.x86_64 When I first reported the problem, I was using the original Fedora binary. After I submitted the bug, I was told vhost-net is not enabled in the Fedora default build. Since I don't know other way for me to verify, I download the source RPM, add "--enable-vhost-net" to the configure option and rebuild the binary. I have the build output uploaded in this thread. Since my own binary didn't make any difference, I'm ready to go back the original one if it helps you to trouble shooting. Thanks.
Interesting note, I just realized that my F17 hypervisor does not make KVM available. Only QEMU. The kvm-qemu binary is installed on the box. The kvm kernel module is loaded on the box. But virt-manager says "Warning: KVM is not available. This may mean the KVM package is not installed, or the KVM kernel modules are not loaded. Your virtual machines may perform poorly." This means that the error message is coming from /usr/bin/qemu-system-x86_64 The actual command it used was: /usr/bin/qemu-system-x86_64 -S -M pc-0.15 -no-kvm -m 4096 -smp 3,sockets=3,cores=1,threads=1 -name Windows7 -uuid 584066b9-55a1-cd2a-382e-1a2535c70918 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/Windows7.img,if=none,id=drive-scsi0-0-0,format=raw,cache=none -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -drive file=/var/lib/libvirt/images/virtio-win-0.1-22.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive file=/var/lib/libvirt/images/Win7-iso.img,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=21,id=hostnet0,vhost=on,vhostfd=22 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:76:db:8b,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 Which fails if run from the command line with (I assume not surprisingly): char device redirected to /dev/pts/1 qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: TUNGETIFF ioctl() failed: Bad file descriptor TUNSETOFFLOAD ioctl() failed: Bad file descriptor qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: vhost-net support is not compiled in qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: vhost-net requested but could not be initialized qemu-system-x86_64: -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22: Device 'tap' could not be initialized I believe right now my main goal is to figure out why virt-manager doesn't think KVM is an option on that box.
> I believe right now my main goal is to figure out why virt-manager doesn't > think KVM is an option on that box. Try running the 'virt-host-validate' command as root. It will point out a few obvious problems it knows about.
# virt-host-validate QEMU: Checking for hardware virtualization : PASS QEMU: Checking for device /dev/kvm : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the BIOS has enabled virtualization) QEMU: Checking for device /dev/vhost-net : PASS QEMU: Checking for device /dev/net/tun : PASS LXC: Checking for Linux >= 2.6.26 : PASS Virt was disabled in BIOS. When I enabled virt in BIOS I was able to use KVM. With KVM the virtio nic is working. This bug appears specific to a virtio nic and non-kvm qemu.
Okay, this is starting to make sense. The first layer of failure is that the system in question doesn't have KVM support enabled somehow (in eparis' case, it was due to being disabled in the BIOS, in Arnold's case, it's because his CPU doesn't support KVM). The second layer of failure is that when that happens, qemu-system-x86_64 (or qemu-system-i686 or whatever it's called on 32 bit systems) is run instead of qemu-kvm, and qemu-system-x86_64 has for some reason been configured with vhost support compiled out. The 3rd layer is that even though vhost support has been configure out of qemu-system-x86_64, it still shows up in the help output, so libvirt believes it's available and builds a commandline accordingly. I don't think there's a reason that qemu-system-X needs to have vhost support disabled, so one solution would be to enable that in the build. If there *is* some reason it needs to be disable in qemu-system-X, then the -help text should be altered accordingly so that libvirt knows what it has to work with. Short term workaround: Until a new build of qemu-system is available, you can disable loading of the vhost-net module, so libvirt won't bother trying to use it. Just create a file in /etc/modprobe.d (you could call it vhost-net.conf) containing this line: blacklist vhost-net and if you want to unload it immediately, you can also run "rmmod vhost-net"; otherwise it won't be loaded during subsequent boots of the host. Long term fix: qemu-system-* need to either be configured with vhost-net support enabled, or their help text needs to be modified so that the vhost option isn't mentioned anywhere.
I'm pretty sure I bought a VT capable CPU and enabled in the BIOS. Any way, how I can verify that? I tried the following so far: -bash-4.2# lsmod | grep kvm kvm_intel 132336 0 kvm 401177 1 kvm_intel -bash-4.2# egrep '^flags.*(vmx|svm)' /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid -bash-4.2#
@Arnold the virt-host-validate command will verify that you have VT correctly enabled. From those CPU flags it looks fine ('vmx' is present)
Since I'm only running libvirt-0.9.6-4.fc16.x86_64, virt-host-validate is not available to me. :-( -bash-4.2# virt-host-validate bash: virt-host-validate: command not found... BTW, I tried manually use qemu-kvm, didn't know the existence of the difference, and I'm running into a different issue now. Well, I need figure out libvirt insist to use qemu-system-x86_64 even my machine is KVM capable. However that's a separate issue, I assume. -bash-4.2# LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -S -M pc-0.14 -cpu core2duo,+lahf_lm,+rdtscp,+aes,+popcnt,+x2apic,+sse4.2,+sse4.1,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+pbe,+tm,+ht,+ss,+acpi,+ds -no-kvm -m 4096 -smp 1,sockets=1,cores=1,threads=1 -name Windows7 -uuid f6cddba1-b1ef-67d8-658b-e802d80352e5 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Windows7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -device lsi,id=scsi0,bus=pci.0,addr=0x7 -drive file=/var/lib/libvirt/images/Windows7.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/var/lib/libvirt/images/Windows7-1.img,if=none,id=drive-scsi0-0-0,format=raw,cache=none -device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2c:7c:d2,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 char device redirected to /dev/pts/1 qemu-kvm: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: TUNGETIFF ioctl() failed: Bad file descriptor TUNSETOFFLOAD ioctl() failed: Bad file descriptor qemu-kvm: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: vhost-net requested but could not be initialized qemu-kvm: -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25: Device 'tap' could not be initialized I have the following kernel modules loaded. -bash-4.2# lsmod | grep kvm kvm_intel 132336 0 kvm 401177 1 kvm_intel -bash-4.2# lsmod | grep vhost vhost_net 33675 0 macvtap 18183 1 vhost_net tun 22768 4 vhost_net -bash-4.2# lsmod | grep tun tun 22768 4 vhost_net -bash-4.2# lsmod | grep tap macvtap 18183 1 vhost_net macvlan 18569 1 macvtap
Ok, I "fixed" my problem. Since it's beyond my capability to figure out all the parameters to satisfy qemu-kvm manually, I took the short cut to create a new VM using the GUI. This time, I made sure it's using KVM and I could start the machine with virtio NIC. I guess what happened was originally the VM was build with qemu option, for whatever reason. After all, the root cause is in libvirt. It need either reject "virtio" or change the virtualization type, in my view.
(In reply to comment #19) > After all, the root cause is in libvirt. It need either reject > "virtio" or change the virtualization type, in my view. As far as I understand things, that is incorrect. The virtio driver should work regardless of whether or not kvm is available/used. The two are independent of each other. As a matter of fact, the problem isn't that virtio isn't available in qemu-system, the problem is that one virtio optimization isn't available in qemu-system, but qemu-system advertises (via the help) that it is.
Thanks for the explanation.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Sounds like the original reporter worked around their issue. Since we haven't heard any other reports, I'm guessing this doesn't error on F18 at least. If anyone can still reproduce, please open a new bug since this one has grown quite long.