Hide Forgot
Description of problem: From a Fedora 20 desktop, run virt-manager. Connect over ssh to a server running RHEL7. Try to create a guest, in my case it was a Windows 2012 VM from ISO image using LVM disk volume, default nic options, etc. Attempting to begin installation fails with: Unable to complete install: 'internal error: process exited while connecting to monitor: qemu-kvm: -no-hpet: invalid option ' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 1959, in do_install guest.start_install(meter=meter) File "/usr/share/virt-manager/virtinst/guest.py", line 389, in start_install noboot) File "/usr/share/virt-manager/virtinst/guest.py", line 454, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2901, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: qemu-kvm: -no-hpet: invalid option Version-Release number of selected component (if applicable): libvirt-1.1.1-14.el7.x86_64 virt-manager-0.10.0-5.git1ffcc0cc.fc20.noarch How reproducible: 100% Steps to Reproduce: 1. see description 2. 3. Actual results: unusable Expected results: compatibility Additional info:
Not cool. This means libvirt thinks qemu-kvm supports -no-hpet while it apparently does not support it. The reason is libvirt has a hard-coded list of capabilities which are always present in QEMU 1.2.0 and later and which cannot be detected by querying QEMU using any QMP command. And it seems qemu-kvm in RHEL-7 disabled some of these capabilities, which broke libvirt. The question is, why is virt-manager trying to use HPET timer while there are apparently better choices even for Windows guests.
I can reproduce this issue with: virt-manager-0.10.0-5.git1ffcc0cc.fc20.noarch libvirt-1.1.1-16.el7.x86_64 Steps: 1.On Fedora 20 desktop, run virt-manager. 2.File->Add connection,add a remote rhel7 host. 3.On the new connection,create a new guest. 4.Tried pxe or iso installation,after all the default configuration set,then creating guest fail with error: Unable to complete install: 'internal error: process exited while connecting to monitor: qemu-kvm: -no-hpet: invalid option ' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 1959, in do_install guest.start_install(meter=meter) File "/usr/share/virt-manager/virtinst/guest.py", line 389, in start_install noboot) File "/usr/share/virt-manager/virtinst/guest.py", line 454, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2897, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: qemu-kvm: -no-hpet: invalid option
Also I tested this issue with remote rhel6 host: Fedora 20 version: virt-manager-0.10.0-5.git1ffcc0cc.fc20.noarch libvirt-1.1.3.1-2.fc20.x86_64 Remote rhel6 host: libvirt-0.10.2-29.el6.1.x86_64 When from Fedora 20 desktop,use virt-manager to add a remote rhel6 host as a new connection,try to install guest on the new connection,error occurs,is it a bug on rhel6 or issue on fedora? Unable to complete install: 'Cannot check QEMU binary /usr/bin/qemu-kvm: No such file or directory' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 1959, in do_install guest.start_install(meter=meter) File "/usr/share/virt-manager/virtinst/guest.py", line 389, in start_install noboot) File "/usr/share/virt-manager/virtinst/guest.py", line 454, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2897, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: Cannot check QEMU binary /usr/bin/qemu-kvm: No such file or directory
That depends on how you create the new domain. In case /usr/bin/qemu-kvm is chosen by virt-manager (and not manually by you), it's a bug in virt-manager since rhel6 libvirt only shows /usr/libexec/qemu-kvm emulator in capabilities XML from which virt-manager should take them.
(In reply to Jiri Denemark from comment #5) > That depends on how you create the new domain. In case /usr/bin/qemu-kvm is > chosen by virt-manager (and not manually by you), it's a bug in virt-manager > since rhel6 libvirt only shows /usr/libexec/qemu-kvm emulator in > capabilities XML from which virt-manager should take them. Yes,It is chosen by virt-manager,so I filed a new bug 1049192 on rhel6.
*** Bug 1049920 has been marked as a duplicate of this bug. ***
(In reply to Jiri Denemark from comment #2) > The question is, why is virt-manager trying to use HPET timer while there > are apparently better choices even for Windows guests. To clarify, virt-manager is requesting HPET off. While that's the default on RHEL, hpet=on is the default on upstream qemu and fedora. Since I saw the -no-hpet detection logic in libvirt, I figured it was safe for virt-manager to always specify hpet=off and libvirt would just do the right thing. Unconditional hpet=off is what was recommend by qemu/kvm devs.
the issue seems to be caused by the following line in qemu_capabilities.c (virQEMUCapsInitQMPBasic): virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_HPET); the comment for the function says: "Capabilities that we assume are always enabled for QEMU >= 1.2.0", which is apparently not true for RHEL-7. Unfortunately this information is not available trough QMP but it is needed to parse the qemu-kvm -help output. Any idea on this? Should we use both QMP and qemu-kvm -help?
Updated the BZ description per conversation with Giuseppe; let me know if that's not accurate.
Eric, do you have any idea how this should be solved? Parse "qemu-kvm -help" is still an option for these capabilities that now are assumed to be always present in qemu? Should qemu be changed to report when "no-hpet" is not present (so we can assume no-hpet is available in older qemu versions that not report it)?
I believe qemu guys are planning on extending the query cli commands to capture things like -no-hpet, at which point libvirt can do the right thing. However, if that isn't ready in time for RHEL7.0, libvirt absolutely needs to find a temporary way to fix this on RHEL7, even if it's a hack like checking if the emulator is in /usr/libexec. Having to work around this in virt-manager is going to be a nightmare, short of dropping the -no-hpet request entirely.
Let's just add back -no-hpet, making it a no-op while still hiding it from the help messages. In effect we're always operating as if -no-hpet is being passed.
(In reply to Giuseppe Scrivano from comment #11) > Eric, do you have any idea how this should be solved? Parse "qemu-kvm > -help" is still an option for these capabilities that now are assumed to be > always present in qemu? Should qemu be changed to report when "no-hpet" is > not present (so we can assume no-hpet is available in older qemu versions > that not report it)? Fixing it in qemu is the right action - until upstream qemu adds a way to query the existence of boolean options such as -no-hpet, then downstream qemu is not allowed to delete command-line parsing of those options (even if the option is changed to a no-op).
Fix included in qemu-kvm-1.5.3-38.el7
Test this bug with qemu-kvm-1.5.3-45.el7.x86_64 Try to boot guest with -no-hpet: # # /usr/libexec/qemu-kvm -no-hpet -cpu Penryn -m 2G -smp 4,sockets=1,cores=4,threads=1 -M pc -enable-kvm -device piix3-usb-uhci,id=usb -name W2012 -nodefaults -nodefconfig -device virtio-balloon-pci,id=balloon0 -vnc :10 -vga std -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -monitor stdio -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=virtio-netpci0,mac=54:52:1b:36:1a:01 -drive file=/home/rhel7base.qcow2_v3,if=none,media=disk,format=qcow2,rerror=stop,werror=stop,aio=native,id=scsi-disk0 -device virtio-scsi-pci,id=bus2 -device scsi-hd,bus=bus2.0,drive=scsi-disk0,id=disk0 QEMU 1.5.3 monitor - type 'help' for more information (qemu) Result, guest can boot up successfully with -no-hpet, qemu can detect -no-hpet well. So according to above this bug is fixed by qemu-kvm-1.5.3-45.el7.x86_64.
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.