On 05/20/2011 01:12 PM, Cal Heldenbrand wrote:
First look in /var/log/libvirt/qemu/<domainname>.log and see which
qemu binary is being executed by libvirt - it may not be the one
you've built.
It looks correct... I pulled out the driver tag from my config and
fired it up. Here is the full command line for it:
LC_ALL=C
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-x86_64 -S -M pc-0.14
-enable-kvm -m 4096 -smp 7,sockets=7,cores=1,threads=1 -name web101
-uuid bda63821-ccc4-6607-67c0-db6712526cbd -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/web101.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -boot
c -drive
file=/var/lib/libvirt/images/web101.img,if=none,id=drive-virtio-disk0,format=raw,cache=writethrough
-device
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0
-drive
file=/home/httpd.img,if=none,id=drive-virtio-disk1,format=raw,cache=writethrough
-device
virtio-blk-pci,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1
-drive 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
-fsdev local,security_model=passthrough,id=fsdev-fs0,path=/home/httpd
-device
virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=/home/httpd,bus=pci.0,addr=0x8
-netdev tap,fd=15,id=hostnet0 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6f:51:43,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -usb -device
usb-tablet,id=input0 -vnc 127.0.0.1:0 <http://127.0.0.1:0> -vga cirrus
-device AC97,id=sound0,bus=pci.0,addr=0x4 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
Then, run "qemu-kvm --help" (replacing "qemu-kvm" with the path to
the binary that libvirt is executing, found in the previous
paragraph), and search through that output for the string
",vhost=" - if it's not there, then your qemu doesn't support
vhost-net.
This also looks correct. Is it wrong that my qemu compilation didn't
create a binary named "qemu-kvm"? (Even though it said "KVM support
yes" on the configure output?)
Not exactly, but close. In the qemu capabilities code, there is a
variable called "is_kvm" that is only set if it finds the string
"(qemu-kvm-" or "(kvm-" in the help output. It seems to me that this
used to be used for a lot more things, but when I look now I see that
it's used for very few things (maybe a result of the capabilities code
refactoring, or maybe my memory is faulty :-). However, one of the
things still in place is that QEMU_CAPS_VNET_HOST isn't set unless
is_kvm is true.
I believe this dependency on is_kvm is there because someone said that
the feature was only in kvm, but retrospectively that doesn't make
sense. Can you try building with the following patch, and see if that works?
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ea55df5..71a54a5 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -982,7 +982,7 @@ qemuCapsComputeCmdFlags(const char *help,
if (is_kvm && (version >= 10000 || kvm_version >= 74))
qemuCapsSet(flags, QEMU_CAPS_VNET_HDR);
- if (is_kvm && strstr(help, ",vhost=")) {
+ if (strstr(help, ",vhost=")) {
qemuCapsSet(flags, QEMU_CAPS_VNET_HOST);
}
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
