Red Hat Bugzilla – Bug 477955
Enable qemu sound devices to tunnel over VNC
Last modified: 2013-03-13 02:21:47 EDT
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):
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.
No sound in the VM.
Sound should work in the VM, by default, through pulseaudio.
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
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
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.
Geert: here's where you can download the F11 RPM. I think it should be fine for testing on F10:
kvm-71 and above support pulseaudio directly.
kvm-83 behavior with kernel-18.104.22.168-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
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).
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.
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.
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?
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... ?
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.
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.
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.
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.
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
As far as QEMU is concerned, it should just use SDL audio driver, and SDL then probes for available backends, currently favouring PulseAudio.
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
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
Re-titling this "Enable qemu sound devices to tunnel over VNC"
The VirtVNCResourceTunnel feature has been punted to Fedora 13. Moving to F13VirtTarget
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:
I think this bug should be moved to rawhide for more visibility.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I assume that sound over VNC moved to F14?
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:
Duping this to the gtk-vnc bug
*** This bug has been marked as a duplicate of bug 595880 ***