Bug 967836 - Bad /dev/kvm permissions give misleading startup errors: hda-duplex not supported in this QEMU binary
Bad /dev/kvm permissions give misleading startup errors: hda-duplex not suppo...
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
: 957938 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-28 08:00 EDT by Cole Robinson
Modified: 2016-04-26 09:25 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-04-16 14:10:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cole Robinson 2013-05-28 08:00:18 EDT
# chmod 600 /dev/kvm
# sudo service libvirtd restart
# virsh start my-guest
error: Failed to start domain my-guest
error: unsupported configuration: hda-duplex not supported in this QEMU binary

Some weird mis-error reporting is going on there. Might be a change in qemu but someone needs to figure it out.

There's another issue as well, and this it is why people are seeing it I suspect: if you change the /dev/kvm permissions to 666 like they should be but _don't_ restart libvirtd, everything is still messed up. I think we already auto refresh capabilities if qemu binaries change, maybe we need to do that for /dev/kvm as well.
Comment 1 Cole Robinson 2013-05-28 08:04:08 EDT
*** Bug 957938 has been marked as a duplicate of this bug. ***
Comment 2 Martin Kho 2013-05-29 05:15:30 EDT
Hi Cole,

Tried to create a new VM (host and guest F19 kde), followed the first two steps above, but still get this error:

Unable to complete install: 'unsupported configuration: hda-duplex not supported in this QEMU binary'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1920, in do_install
    guest.start_install(False, meter=meter)
  File "/usr/share/virt-manager/virtinst/Guest.py", line 1134, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/Guest.py", line 1202, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2775, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: unsupported configuration: hda-duplex not supported in this QEMU binary

HTH

Martin Kho

qemu-common.x86_64 2:1.4.2-2.fc19
virt-manager-common.noarch 0:0.10.0-0.5.gitde1695b2.fc19
Comment 3 Martin Kho 2013-05-29 06:38:13 EDT
Hi,

After a reboot everything seems fine. Sorry for the noise :-(

Martin Kho
Comment 4 Cole Robinson 2013-08-31 20:14:03 EDT
The root is that fedora qemu-kvm is just a script with

qemu-system-x86_64 -machine accel=kvm

Libvirt does capabilities probing on qemu-kvm with

qemu-kvm -M none ...

But qemu-kvm still tries to use accel=kvm. /dev/kvm can't be accessed, so all the qmp probing fails, and we get weird error messages. Not clear to me how to fix it: we could do capabilities probing with -machine none,accel=tcg but maybe that would upset RHEL if it compiles tcg out (I'm not sure if it does).

Since the root /dev/kvm permissions issue has been identified (bug #993491), moving this to the upstream tracker since it isn't as big of an issue for Fedora
Comment 5 Till Maas 2013-11-23 15:31:21 EST
I am not sure, whether the root kvm permissions isse has been identified since I still see this bug in Fedora 19. But there was also no update for Fedora 19 that addresses bug 993491. Also there are no details about how bug 993491 fixes the issue, i.e. what are the correct permissions for /dev/kvm to work?
Comment 6 Brian J. Murrell 2014-06-11 16:03:27 EDT
I'm not sure I understand what the problem is here, exactly, but I am seeing this on Fedora 20.

# ls -l /dev/kvm
crw-rw-rw-+ 1 root kvm 10, 232 Jun 11 14:11 /dev/kvm

This was trying to start a domain shortly after a reboot, so I doubt another reboot will fix anything.
Comment 7 Cole Robinson 2014-06-11 17:13:53 EDT
(In reply to Brian J. Murrell from comment #6)
> I'm not sure I understand what the problem is here, exactly, but I am seeing
> this on Fedora 20.
> 
> # ls -l /dev/kvm
> crw-rw-rw-+ 1 root kvm 10, 232 Jun 11 14:11 /dev/kvm
> 
> This was trying to start a domain shortly after a reboot, so I doubt another
> reboot will fix anything.

Those are the expected /dev/kvm permissions
Comment 8 Brian J. Murrell 2014-06-12 08:13:36 EDT
(In reply to Cole Robinson from comment #7)
> 
> Those are the expected /dev/kvm permissions

Indeed.  But what I am at a loss about is how that has anything to do with the reported error in this ticket, which I am also seeing:

error: Failed to start domain Win7
error: unsupported configuration: hda-duplex not supported in this QEMU binary

I think perhaps I am looking at a completely unrelated ticket here, or perhaps the error I am getting is another mis-error.
Comment 9 Rich Megginson 2014-09-26 15:15:40 EDT
Does anyone have a clue about how to fix this issue?
Comment 10 Cole Robinson 2014-09-26 15:48:03 EDT
Rich, it's usually that:

- qemu-system-x86 or qemu-kvm is not installed
- /dev/kvm isn't loaded, dmesg | grep kvm might say why

Sometimes a reboot is required after those packages are installed
Comment 11 Rich Megginson 2014-09-26 15:54:04 EDT
(In reply to Cole Robinson from comment #10)
> Rich, it's usually that:
> 
> - qemu-system-x86 or qemu-kvm is not installed
> - /dev/kvm isn't loaded, dmesg | grep kvm might say why
> 
> Sometimes a reboot is required after those packages are installed

Thanks.  Looks like rebooting fixed the problem - I no longer see "error: unsupported configuration: hda-duplex not supported in this QEMU binary'
Comment 12 Rich Megginson 2014-09-26 18:21:10 EDT
A reboot shouldn't be required.  And note: it works fine with qemu 1.6.1-2, but fails with the current version in f20 1.6.2-8

Is someone working on this bug?  Maybe this bug should be moved to qemu?
Comment 13 Cole Robinson 2015-04-16 14:10:10 EDT
I tried to reproduce with the steps in comment #0, but libvirt/qemu only through clear errors now. So closing this

If anyone can still reproduce with Fedora 22 or later packages, please reopen

Note You need to log in before you can comment on or make changes to this bug.