Bug 1044742

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.