Bug 524499 - libvirt should not enable qemu's audio backend, even with selinux disabled
libvirt should not enable qemu's audio backend, even with selinux disabled
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
rawhide
All Linux
high Severity high
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F12VirtBlocker
  Show dependency treegraph
 
Reported: 2009-09-20 16:22 EDT by Tom Horsley
Modified: 2009-10-02 11:21 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-02 11:21:39 EDT
Type: ---
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 Tom Horsley 2009-09-20 16:22:28 EDT
Description of problem:

I just got virtualization configured in my rawhide boot partition
and attempted to run some virtual machines I created in fedora 11,
and got an assortment of miserable failures. I've got a raw file image
with an ubuntu 9.10 machine:

[root@zooty images]# pwd
/var/lib/libvirt/images
[root@zooty images]# qemu-img info ubu.img 
image: ubu.img
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 3.2G

When I do a virsh define and import the xml def dumped on fedora 11
and start the machine, it boots partway up, then I see this in
/var/log/messages:

Sep 20 15:59:18 zooty kernel: tun: Universal TUN/TAP device driver, 1.6
Sep 20 15:59:18 zooty kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Sep 20 15:59:18 zooty kernel: device vnet0 entered promiscuous mode
Sep 20 15:59:18 zooty kernel: br0: port 2(vnet0) entering learning state
Sep 20 15:59:18 zooty kernel: BUG: MAX_LOCK_DEPTH too low!
Sep 20 15:59:18 zooty kernel: turning off the locking correctness validator.
Sep 20 15:59:18 zooty kernel: Pid: 3622, comm: qemu-kvm Tainted: G        W  2.6.31-33.fc12.x86_64 #1
Sep 20 15:59:18 zooty kernel: Call Trace:
Sep 20 15:59:18 zooty kernel: [<ffffffff8109799b>] __lock_acquire+0xb84/0xc0e
Sep 20 15:59:18 zooty kernel: [<ffffffff81097b13>] lock_acquire+0xee/0x12e
Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141
Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141
Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141
Sep 20 15:59:18 zooty kernel: [<ffffffff815067ee>] _spin_lock_nest_lock+0x45/0x8e
Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] ? mm_take_all_locks+0xf7/0x141
Sep 20 15:59:18 zooty kernel: [<ffffffff81505063>] ? mutex_lock_nested+0x4f/0x6b
Sep 20 15:59:18 zooty kernel: [<ffffffff8111a5f7>] mm_take_all_locks+0xf7/0x141
Sep 20 15:59:18 zooty kernel: [<ffffffff811305a8>] ? do_mmu_notifier_register+0xb4/0x192
Sep 20 15:59:18 zooty kernel: [<ffffffff811305b0>] do_mmu_notifier_register+0xbc/0x192
Sep 20 15:59:18 zooty kernel: [<ffffffff811306e5>] mmu_notifier_register+0x26/0x3d
Sep 20 15:59:18 zooty kernel: [<ffffffffa02a9eeb>] kvm_dev_ioctl+0x14a/0x2f7 [kvm]
Sep 20 15:59:18 zooty kernel: [<ffffffff81151cdf>] vfs_ioctl+0x31/0xaa
Sep 20 15:59:18 zooty kernel: [<ffffffff811522a1>] do_vfs_ioctl+0x4aa/0x506
Sep 20 15:59:18 zooty kernel: [<ffffffff81085fbb>] ? up_read+0x3a/0x55
Sep 20 15:59:18 zooty kernel: [<ffffffff81011f7a>] ? sysret_check+0x2e/0x69
Sep 20 15:59:18 zooty kernel: [<ffffffff81152362>] sys_ioctl+0x65/0x9c
Sep 20 15:59:18 zooty kernel: [<ffffffff81011f42>] system_call_fastpath+0x16/0x1b

I then tried a Windows XP machines which is setup as a qcow2 image
based on another qcow2 image:

[root@zooty images]# qemu-img info winxppro.img
image: winxppro.img
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 48M
cluster_size: 4096
backing file: winxpsp3-acpi-base.img (actual path: winxpsp3-acpi-base.img)
[root@zooty images]# qemu-img info winxpsp3-acpi-base.img 
image: winxpsp3-acpi-base.img
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 5.4G
cluster_size: 4096

It won't even start booting, it just says:

qemu: could not open disk image /var/lib/libvirt/images/winxppro.img

Version-Release number of selected component (if applicable):
qemu-img-0.10.92-4.fc12.x86_64
qemu-system-x86-0.10.92-4.fc12.x86_64
qemu-common-0.10.92-4.fc12.x86_64
qemu-kvm-0.10.92-4.fc12.x86_64
gpxe-roms-qemu-0.9.7-5.fc12.noarch


How reproducible:
Same results every time.

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
abject failure

Expected results:
being able to run virtual machines across an upgrade.

Additional info:
Comment 1 Mark McLoughlin 2009-09-21 10:52:48 EDT
(In reply to comment #0)

> Sep 20 15:59:18 zooty kernel: BUG: MAX_LOCK_DEPTH too low!

Nothing to be concerned about, see bug #507500

(In reply to comment #0)
> I then tried a Windows XP machines which is setup as a qcow2 image
> based on another qcow2 image:
> 
> [root@zooty images]# qemu-img info winxppro.img
> image: winxppro.img
> file format: qcow2
> virtual size: 20G (21474836480 bytes)
> disk size: 48M
> cluster_size: 4096
> backing file: winxpsp3-acpi-base.img (actual path: winxpsp3-acpi-base.img)
> [root@zooty images]# qemu-img info winxpsp3-acpi-base.img 
> image: winxpsp3-acpi-base.img
> file format: qcow2
> virtual size: 20G (21474836480 bytes)
> disk size: 5.4G
> cluster_size: 4096

See bug #497131 about an svirt bug with using qcow2 copy-on-write files
>
> It won't even start booting, it just says:
> 
> qemu: could not open disk image /var/lib/libvirt/images/winxppro.img

qemu now runs as the qemu user now

Try chmod o+x /var/lib/libvirt/images ?
Comment 2 Tom Horsley 2009-09-21 19:15:35 EDT
OK, changing permissions works for the Windows XP image. Thanks!

I assume the ubuntu problem won't be fixed till a kernel update shows up.
Comment 3 Tom Horsley 2009-09-21 19:41:07 EDT
Actually my ubuntu problem was a different permission problem: Due to bug 524732
I was running virt-manager as root, and apparently the VM hung up trying to
initialize the audio device because qemu couldn't connect to pulseaudio
running as the wrong user with wrong home directory for current pulse daemon.

Hanging forever seems pretty draconian - maybe just making it look like the
sound hardware is busted and continuing would be better behavior?

The ubuntu machine boots fine once I remove the sound hardware.
Comment 4 Mark McLoughlin 2009-10-01 04:38:26 EDT
(In reply to comment #3)

> I was running virt-manager as root, and apparently the VM hung up trying to
> initialize the audio device because qemu couldn't connect to pulseaudio
> running as the wrong user with wrong home directory for current pulse daemon.

Could you confirm that that you had SELinux disabled when doing this?

We do not enable audio devices when SELinux is enabled (see bug #508317)

However, now that we are running qemu as an unprivileged user, we should never enable the pulseaudio/SDL backend

It just so happens that danpb pushed a change upstream to do this recently:

  http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=b08e6d38ae

I've just pulled this into F-12:

* Thu Oct  1 2009 Mark McLoughlin <markmc@redhat.com> - 0.7.1-8
- Disable sound backend, even when selinux is disabled (#524499)

I'll build it later on today
Comment 5 Tom Horsley 2009-10-01 06:03:05 EDT
Yes, selinux is definitely disabled, both in /etc/selinux/config
and with selinux=0 in grub.conf (belt and suspenders :-).
Comment 6 Mark McLoughlin 2009-10-02 11:21:39 EDT
This is in rawhide now

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