Bug 477955
| 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> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 12 | CC: | amcnabb, amlau, atorkhov, belegdol, berrange, bugzilla, clalance, crobinso, dwmw2, fedora, fschwarz, gcosta, gilboad, gwendolen.lynch, itamar, jaswinder, jeremy, knoel, loganjerry, long, lpoetter, markmc, mishu, rankin.james, remm, sanabria.d, torsten, virt-maint, walovaton, wtogami, zing |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-06-30 16:04:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 508317 | ||
|
Description
Geert Jansen
2008-12-26 11:26:44 UTC
Warren: is this the bug you fixed with this change? * Tue Jan 20 2009 Warren Togami <wtogami> - 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: http://koji.fedoraproject.org/koji/buildinfo?buildID=79590 kvm-71 and above support pulseaudio directly. ./configure --audio-drv-list=pa kvm-83 behavior with kernel-2.6.27.9-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 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. 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" 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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? - Gilboa 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 *** |