Hide Forgot
Description of problem: http://libguestfs.org/guestfs.3.html#guestfs_config doesn't help either because it's overridden by -enable-kvm switch later. We should check if we're running on bare metal and enable KVN only in this case, in other cases use -no-kvm switch. See below guestfish session: $ LIBGUESTFS_QEMU=/usr/bin/qemu-system-x86_64 guestfish -v -a build/appliances/x86_64/fedora/14/f14-jeos/fedora-plugin/tmp/f14-jeos-sda.raw Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help on commands 'man' to read the manual 'quit' to quit the shell ><fs> launch libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum '/usr/lib64/guestfs/supermin.d' x86_64 supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null), initrd = (null), appliance = (null) supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d checking modpath /lib/modules/2.6.38.2-9.fc15.x86_64 is a directory picked vmlinuz-2.6.38.2-9.fc15.x86_64 because modpath /lib/modules/2.6.38.2-9.fc15.x86_64 exists supermin helper [00000ms] finished creating kernel supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d/base.img supermin helper [00001ms] visiting /usr/lib64/guestfs/supermin.d/daemon.img supermin helper [00001ms] visiting /usr/lib64/guestfs/supermin.d/hostfiles supermin helper [00038ms] visiting /usr/lib64/guestfs/supermin.d/init.img supermin helper [00170ms] finished creating appliance libguestfs: [00178ms] begin testing qemu features libguestfs: [00220ms] finished testing qemu features libguestfs: accept_from_daemon: 0x20b25b0 g->state = 1 libguestfs: [00232ms] /usr/bin/qemu-system-x86_64 \ -drive file=build/appliances/x86_64/fedora/14/f14-jeos/fedora-plugin/tmp/f14-jeos-sda.raw,cache=off,if=virtio \ -nodefconfig \ -enable-kvm \ -nodefaults \ -nographic \ -m 500 \ -no-reboot \ -no-hpet \ -device virtio-serial \ -serial stdio \ -chardev socket,path=/tmp/libguestfsdxVSvH/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -kernel /var/tmp/.guestfs-0/kernel.14705 \ -initrd /var/tmp/.guestfs-0/initrd.14705 \ -append 'panic=1 console=ttyS0 udevtimeout=300 noapic acpi=off printk.time=1 cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm-color ' \ -drive file=/var/tmp/.guestfs-0/root.14705,snapshot=on,if=virtio,cache=unsafe KVM not supported for this target libguestfs: error: unexpected end of file when reading from daemon libguestfs: child_cleanup: 0x20b25b0: child process died Version-Release number of selected component (if applicable): libguestfs-1.10.1-1.fc15.x86_64 qemu-kvm-0.14.0-7.fc15.x86_64 How reproducible: Always on non-bare metal hosts. $ guestfish -v -a /dev/null launch Actual results: Error. Expected results: No error, surprisingly :) Additional info: Fedora 15
We already check if KVM is available by checking if /dev/kvm exists: src/launch.c: if (qemu_supports (g, "-enable-kvm") && is_openable (g, "/dev/kvm", O_RDWR)) add_cmdline (g, "-enable-kvm"); Can you see if /dev/kvm exists, and what permissions it has? Does this machine use udev, or is /dev directory hard-coded?
The problem is that qemu-system-x86_64 advertizes the -enable-kvm option: $ qemu-system-x86_64 --help | grep enable-kvm -enable-kvm enable KVM full virtualization support But then completely rejects it: $ qemu-system-x86_64 -enable-kvm -hdc /dev/null KVM not supported for this target (It doesn't even open /dev/kvm or check for it in any way). This is a qemu bug basically.
Markus, can you suggest the correct / reliable way that we should be using so that we get KVM if it's available, but otherwise fall back to TCG, which will work across all versions of qemu and KVM?
Unfortunately, there is no way to ask for "KVM or else TCG" that works across versions. With qemu-kvm, it is the default. With upstream qemu, it's simply not possible. You could simply assume qemu-kvm semantics on the hypothesis that anyone who cares for KVM will use qemu-kvm for production. If you use qemu, you get TCG. If you must have KVM even with upstream qemu, you can try with -enable-kvm, recognize "no KVM support" failure, retry without. Recognizing the failure will be relatively brittle, I'm afraid. Or start an extra instance just to run "info kvm" in the monitor. Please don't shoot the messenger... Additional info: upstream qemu | default |-enable-kvm ----------------+-----------+----------- KVM available | disabled | enabled KVM unavailable | disabled | fail qemu-kvm old | default |-enable-kvm| -no-kvm ----------------+-----------+-----------+---------- KVM available | enabled* | enabled | disabled KVM unavailable | disabled | disabled* | disabled qemu-kvm new | default |-enable-kvm| -no-kvm ----------------+-----------+-----------+---------- KVM available | enabled* | enabled | disabled KVM unavailable | disabled | fail+ | disabled
OK, but you see why this is why we want proper qemu capabilities.
I understand why a robust way to test for feature availability is desirable. Unfortunately, upstream has rejected all attempts to provide it so far. Another case of perfect being the enemy of good.
Re: Marek suggested testing for vmx|svm in /proc/cpuinfo flags. That's not going to work. The problem is not that the hardware doesn't support hardware virt, but that qemu advertizes the -enable-kvm option but doesn't implement it. It's entirely a problem with qemu.
Want me to try to get upstream qemu's default changed to match qemu-kvm's? Chance of success is unpredictable.
A better thing (perhaps easier) would be to remove -enable-kvm from the qemu help output when it's not actually supported by the built binary ...
Patch posted upstream: https://www.redhat.com/archives/libguestfs/2011-May/msg00070.html This requires the new qemu -machine option which is not yet widely available, but it seems to be the best we can do.
Pushed upstream: http://git.annexia.org/?p=libguestfs.git;a=commit;h=64841fe8957f798df12a38bd81843c7011f2c278 and available in libguestfs >= 1.11.7.
libguestfs-1.10.4-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libguestfs-1.10.4-1.fc15
libguestfs-1.10.4-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.