Description of problem: Could not hear sound in guest which use VNC to connect. but can hear the sound when connect the guest via spice. Use the same driver in above two conditions, QEMU_AUDIO_DRV=alsa Version-Release number of selected component (if applicable): kvm-83-217.el5 kernel 2.6.18-233.el5 How reproducible: 100% Steps to Reproduce: 1. run QEMU_AUDIO_DRV=alsa 2. start guest with /usr/libexec/qemu-kvm -m 2G -smp 2 -uuid `uuidgen` -monitor stdio -boot c -drive file=/home/winxp-32.raw,if=ide,bus=0,unit=0,boot=on,format=raw,cache=none -net nic,macaddr=54:52:00:73:b5:90,model=rtl8139,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -usb -vnc :2 -soundhw ac97 3. to hear the sound from guest Actual results: Could not hear sound in guest The message display in monitor: interface_audio_init: line_in_init: line_out_init: freq 44100 channels 2 format AUD_FMT_S16 HOST_ENDIANNESS Expected results: can hear the sound in guest Additional info: Can hear the sound in guest which use spice to connect. /usr/libexec/qemu-kvm -m 2G -smp 2 -uuid `uuidgen` -monitor stdio -boot c -drive file=/home/winxp-32.raw,if=ide,bus=0,unit=0,boot=on,format=raw,cache=none -net nic,macaddr=54:52:00:73:b5:90,model=rtl8139,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -usb -spice disable-ticketing,port=5930 -qxl 1 -soundhw ac97
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
QEMU_AUDIO_DRV=alsa is broken, bug in the spice patches, spice (in rhel5) grabs the audio output unconditionally and QEMU_AUDIO_DRV=<anything> has no effect at all. Fixing this would *not* make the sound play on the vnc client machine, but on the host where the VM is running, which is probably not the desired effect. Fixing this also has the risk of adding regressions because alsa devices can't be shared and thus two VMs trying to play sound could conflict with each other. Beside that this is not a supported configuration.