Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Enable qemu sound devices to tunnel over VNC|
|Product:||[Fedora] Fedora||Reporter:||Geert Jansen <gjansen>|
|Component:||qemu||Assignee:||Justin M. Forbes <jforbes>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||12||CC:||amcnabb, amlau, atorkhov, belegdol, berrange, bugzilla, clalance, crobinso, dwmw2, fedora, fschwarz, gawain.lynch, gcosta, gilboad, itamar, jaswinder, jeremy, knoel, loganjerry, long, lpoetter, markmc, mishu, rankin.james, remm, sanabria.d, torsten.rausche, virt-maint, walovaton, wtogami, zing|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-06-30 12:04:28 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Geert Jansen 2008-12-26 06:26:44 EST
Description of problem: It is not possible to have audio both in a virtual guest running under KVM, and on the desktop, at the same time. As compiled in Fedora, KVM suppors both OSS and ALSA output. OSS is the default, with no way to change it. The OSS driver in KVM requires exlusive access to the audio device. If pulseaudio was idle at the time that KVM was started, this will work and the VM will have audio. However, in this case the rest of the desktop will not have audio anymore. If pulseaudio was not idle at the time KVM was started, the desktop will continue to have working audio, but audio in the VM will not work. Version-Release number of selected component (if applicable): kvm-74-10.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1. Play some music to ensure that pulseaudio has the sound card open. 2. Start a VM where sound is configured. 3. Observe that sound in the VM does not work. Actual results: No sound in the VM. Expected results: Sound should work in the VM, by default, through pulseaudio. Additional info: If KVM would use ALSA as the default audio driver, then sound would work because pulse installs a fake ALSA device that redirects output to itself. Also, a pulseaudio driver for KVM is available but it is not compiled in. This driver could be compiled in and made the default. This would be in-line with the policy of using Pulseaudio as the default audio server in Fedora. To see the compiled in sound drivers, issue: # qemu-kvm -audio-help
Comment 1 Mark McLoughlin 2009-01-20 18:34:15 EST
Warren: is this the bug you fixed with this change? * Tue Jan 20 2009 Warren Togami <email@example.com> - 83-2 - sdl sound output to avoid grabbing OSS and causing pulseaudio failure
Comment 2 Warren Togami 2009-01-22 10:52:50 EST
Could you please test it? I don't have rawhide. It seems to be imperfect though. While it outputs sound via SDL (which goes to pulseaudio), the sound is crackly. This is an improvement over kvm to ALSA which is crackly and 100% CPU though.
Comment 3 Mark McLoughlin 2009-01-22 11:09:27 EST
Geert: here's where you can download the F11 RPM. I think it should be fine for testing on F10: http://koji.fedoraproject.org/koji/buildinfo?buildID=79590
Comment 4 Avi Kivity 2009-01-22 11:13:04 EST
kvm-71 and above support pulseaudio directly. ./configure --audio-drv-list=pa
Comment 5 Warren Togami 2009-01-22 12:34:56 EST
kvm-83 behavior with kernel-220.127.116.11-159.fc10.x86_64 ==================================================== --audio-drv-list=pa worked on the first try. But second run seems to cause the guest to behave very slow and erratically, unusable. Host CPU usage is not high though. Third run caused a kernel BUG: BUG: unable to handle kernel NULL pointer dereference at 0000000000000790 --audio-drv-list=sdl works stable and fast, but cause sound crackling. --audio-drv-list=alsa works with crackling but host CPU usage is 100%, lots of complaints on stderr from qemu-kvm
Comment 6 Geert Jansen 2009-01-24 13:07:11 EST
I have tested kvm-83-2.fc11.x86_64 on F10 with latest updates. If i start a VM from the command line, sound works. Opening up pavucontrol tells me that a stream exists with the name "qemu-kvm: Simple DirectMedia Layer". I therefore conclude KVM is using SDL as the sound driver, and that SDL properly redirects its audio to pulseaudio. CPU load is around 40% during playback. Sound has occasional cracks. Starting KVM with QEMU_AUDIO_DRV=alsa to use the alsa sound driver, sounds become more crackly than with sdl. CPU usage is also higher, around 50%. When I start a VM through virt-manager, sound is not redirected to pulseaudio and the sound device get occupied. I don't understand this as on the command line the SDL audio driver is the default. It is not an SELinux problem because "setenforce 0" does not solve it. I agree with comment #4 that on a Fedora system the default sound driver should probably be pulseaudio (after the problems reported in #5 would be resolved, of course).
Comment 7 Avi Kivity 2009-02-04 08:57:34 EST
IIUC, virt-manager runs guests not under the owner's uid, so resources available to the owner are not available to the guest. This is really unsuitable for client-side virtualization.
Comment 8 Daniel Berrange 2009-02-04 09:14:09 EST
There are two modes of connecting to the driver - qemu:///system for a single-instance, system wide privileged driver - qemu:///session for a per-user account, private to session instance So instances of KVM/QEMU run via the qemu:///system driver will obviously not integrate with a PulseAudio daemon run in the user's desktop GNOME session. For this kind of integration to work, you'd need to be running guests via the qemu:///session instance where it'd be able to fully integrate with the GNOME session capabilities.
Comment 9 Geert Jansen 2009-02-04 10:32:40 EST
Thanks for the explanation. At the moment it seems not possible to connect to qemu:///session via the virt-manager GUI. TWould it make sense to file a feature request for virt-manager to add this feature?
Comment 10 Geert Jansen 2009-02-04 10:39:59 EST
Replying to my own comment: a different way to look at audio from a VM is that the virtual machine viewer (in this case virt-manager) is responsible for playing the remote audio stream on the local system, just as it is "playing" the VNC stream. This in contract to what we have now where the QEMU driver is playing the audio. In this case there would be no issue accessing PulseAudio, and it would work too for audio on remote virtual machines. Maybe virt-manager needs to switch to using SPICE as the protocol instead of VNC... ?
Comment 11 Daniel Berrange 2009-02-04 10:56:27 EST
There is already a long term plan to allow us to tunnel audio (and other data streams, like serial devices) over VNC, but that's not got any ETA yet. In addition, support of SPICE display backends is another roadmap item, again with no ETA. This is not a discussions to get into in this bug. For the context of this bug, we just need to make sure KVM chooses suitable sound drivers for talking to the host sound system. ie, choosing whether to default to SDL, ALSA or PA drivers.
Comment 12 Warren Togami 2009-02-04 11:12:07 EST
For now can we simply rebuild it to --audio-drv-list=sdl,oss? It is less worse than defaulting to OSS which causes other problems, without taking away the ability to explicitly set OSS.
Comment 13 Julian Sikorski 2009-03-17 16:07:43 EDT
When I tried adding the fix Warren added to rawhide kvm rpm, the result was getting a ton of selinux warnings and inability to restore a saved vm via virsh resume foo, since kvm tried to connect to root's pulseaudio session which obviously did not exist. So it seems that simple rebuild will not work, since it breaks qemu:///system.
Comment 14 Warren Togami 2009-03-18 02:38:06 EDT
F-11 is preventing the snd-*-oss modules to load by default. We will soon have no sound at all from kvm. Why is virsh running kvm with non-default sound hardware, when it can't possibly listen to that sound output via vnc? That sounds like another bug.
Comment 15 Daniel Berrange 2009-03-18 06:58:08 EDT
FYI, as a temporary workaround, current libvirt in rawhide disables sound devices completely now if running with SELinux enabled in qemu:///system. Longer term we are working on getting libvirt + PulseAudio + QEMU to play nicely together . See this mail for more info http://www.redhat.com/archives/libvir-list/2009-March/msg00291.html As far as QEMU is concerned, it should just use SDL audio driver, and SDL then probes for available backends, currently favouring PulseAudio.
Comment 16 Mark McLoughlin 2009-07-03 10:58:23 EDT
From bug #508317: -- If you have SELinux enabled, then it is expected that there is no sound device. We have disabled sound because it caused security problems, and in any case did you correctly integrate with VNC. ie sound would play on the machine running QEMU, not the machine running the VNC client. We are aiming to fix this properly in F12 http://fedoraproject.org/wiki/Features/VirtVNCResourceTunnel If you really do need sound working, then edit /etc/libvirt/qemu.conf and set security_driver="none" and restart libvirtd. This turns off the per-VM isolation. -- Re-titling this "Enable qemu sound devices to tunnel over VNC"
Comment 17 Mark McLoughlin 2009-07-31 05:38:51 EDT
The VirtVNCResourceTunnel feature has been punted to Fedora 13. Moving to F13VirtTarget
Comment 18 Bug Zapper 2009-11-16 04:44:40 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 William Lovaton 2010-02-14 17:34:51 EST
I think this bug should be moved to rawhide for more visibility.
Comment 20 Fedora Admin XMLRPC Client 2010-03-09 12:18:47 EST
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 21 Gilboa Davara 2010-06-21 10:08:12 EDT
I assume that sound over VNC moved to F14? - Gilboa
Comment 22 Cole Robinson 2010-06-30 12:04:28 EDT
I'm pretty sure that QEMU already has the capability to tunnel sound over VNC, the missing piece here is support in VNC clients. There is a relevant bug filed here: https://bugzilla.redhat.com/show_bug.cgi?id=595880 Duping this to the gtk-vnc bug *** This bug has been marked as a duplicate of bug 595880 ***