Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Previously, reconnecting to a running guest virtual machine caused audio input devices attached to the guest, such as microphones, to stop working. This update fixes the handling of the guest recording channel, which prevents the described problem from occurring.
Created attachment 1400840[details]
spice-debug log after reconnection
Description of problem:
No input audio signal is detected after reconnection to VM during audio recording session (within VM guest).
Version-Release number of selected component (if applicable):
client/host (rhel7.5):
spice-server-0.14.0-2.el7.x86_64
spice-glib-0.34-3.el7.x86_64
spice-gtk3-0.34-3.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.14.x86_64.
virt-viewer-5.0-10.el7.x86_64
guest (rhel7.5), reproducible also for Win10 guest
How reproducible:
always
Steps to Reproduce:
1.Use remote-viewer and connect to guest with enabled audio. Have some recording device connected to client (usb webcam with microphone in my case)
2.run within guest 'arecord -vv' and make some noise to microphone (-> see input audio level increases within guest)
3. reconnect to guest VM
4. again make some noise to the microphone similar to that of the step 2
Actual results:
0% input audio level detected in guest VM even though I produce some noise to microphone.
Expected results:
Input audio level is roughly proportionate to the value detected before reconnection.
Additional info:
guest configuration:
/usr/libexec/qemu-kvm -name guest=rhel7.5,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-rhel7.5/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu Broadwell,rtm=on,hle=on -m 2000 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid e82c2e84-3325-4633-8e7a-61756a931fc5 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-rhel7.5/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/rduda/virtualky/RHEL-7.5-20180219.n.0-Workstation-x86_64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:04:e5:26,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-rhel7.5/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on
Do you have your usb device being auto redirect upon connection?
Considering that this is an USB device being redirected, I'm not sure we currently support that microphone (or any ISOC device) would seamless work back on reconnection (e.g the same would be for a webcam that is currently being used by some application and you disconnect/reconnect).
If I understood correctly, this is not the same as spice-gtk's RecordChannel that gets the input from Client's backend (like Pulseaudio) and send it to the guest. With RecordChannel, we'll be sending data to the guest since early stage but with USB device, that's like plug in an USB device while you are already recording audio.
I did not USB redirect this device (and I would write it in the reproducing steps if this was the case).
After reconnection to VM I can renew recording by restarting 'arecord' command.
I tried this again with built-in laptop microphone and I cannot reproduce, but I can reproduce with 3.5 headphones microphone on my workstation (the only connected microphone).
Bug was likely introduced by spice-server rebase.
I can see that qemu does the right thing, which is calling spice_server_record_start() in both situations:
1) When we are connected to the guest and then run arecord -v
2) When we connect to the guest that already has arecord -v running
In the situation (2) it seems that RedChannelClient from RecordChannel is not connected to the client in time (or is it outdated from previous connection?) which causes the RECORD_START message not be sent to the client.
So client does not receive 'ok' to send input from microphone.
It seems to be a regression and we should fix before 7.6 maybe add to 7.5.z too as a user with a ongoing record session (let's say, bluejeans) would lose microphone on disconnect/connect unless it request volume (from input) changes in the guest.
Comment 6Christophe Fergeau
2018-05-22 16:42:26 UTC
Something like this fixes this bug:
diff --git a/server/sound.c b/server/sound.c
index e3891d2cc..a81e4317b 100644
--- a/server/sound.c
+++ b/server/sound.c
@@ -1105,6 +1105,7 @@ static void snd_set_peer(RedChannel *red_channel, RedClient *client, RedStream *
"caps", caps,
NULL);
g_warn_if_fail(snd_client != NULL);
+ snd_send(SND_CHANNEL_CLIENT(snd_client));
}
static void snd_set_playback_peer(RedChannel *red_channel, RedClient *client, RedStream *stream,
The snd_send() calls in record_channel_client_constructed() are too early to trigger a call to send_item() as the channel client won't be considered connected before the end of red_channel_client_initable_init(), and prepare_pipe_add() in red_channel_client_pipe_add() just drops the pipe items if the channel client is not connected, so snd_send() fails to queue any pipe item. This was broken in d8dc09b 'sound: Convert SndChannelClient to RedChannelClient'
Comment 7Christophe Fergeau
2018-05-23 10:17:26 UTC
Verified with spice-server-0.14.0-6.el7.x86_64 and rhel7.6 client/host/guest.
Recording of microphone sound in guest VM continues after reconnection to it.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:3068
Created attachment 1400840 [details] spice-debug log after reconnection Description of problem: No input audio signal is detected after reconnection to VM during audio recording session (within VM guest). Version-Release number of selected component (if applicable): client/host (rhel7.5): spice-server-0.14.0-2.el7.x86_64 spice-glib-0.34-3.el7.x86_64 spice-gtk3-0.34-3.el7.x86_64 qemu-kvm-rhev-2.9.0-16.el7_4.14.x86_64. virt-viewer-5.0-10.el7.x86_64 guest (rhel7.5), reproducible also for Win10 guest How reproducible: always Steps to Reproduce: 1.Use remote-viewer and connect to guest with enabled audio. Have some recording device connected to client (usb webcam with microphone in my case) 2.run within guest 'arecord -vv' and make some noise to microphone (-> see input audio level increases within guest) 3. reconnect to guest VM 4. again make some noise to the microphone similar to that of the step 2 Actual results: 0% input audio level detected in guest VM even though I produce some noise to microphone. Expected results: Input audio level is roughly proportionate to the value detected before reconnection. Additional info: guest configuration: /usr/libexec/qemu-kvm -name guest=rhel7.5,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-rhel7.5/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu Broadwell,rtm=on,hle=on -m 2000 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid e82c2e84-3325-4633-8e7a-61756a931fc5 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-rhel7.5/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/rduda/virtualky/RHEL-7.5-20180219.n.0-Workstation-x86_64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:04:e5:26,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-1-rhel7.5/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on