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.
Bug 1425443 - Client's volume can change after VM migration
Summary: Client's volume can change after VM migration
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: spice-gtk
Version: 8.0
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.1
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-21 12:49 UTC by Radek Duda
Modified: 2020-11-14 08:44 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-09 19:12:35 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Spice-server log of migration destination host (5.32 KB, text/plain)
2017-02-21 14:04 UTC, Radek Duda 		no flags Details
spice-server log of migration source host (2.62 KB, text/plain)
2017-02-21 14:05 UTC, Radek Duda 		no flags Details
migration destination set G_MESSAGES_DEBUG=all and SPICE_DEBUG=1 (5.32 KB, text/plain)
2017-02-21 15:51 UTC, Radek Duda 		no flags Details
migration source set G_MESSAGES_DEBUG=all and SPICE_DEBUG=1 (2.62 KB, text/plain)
2017-02-21 15:51 UTC, Radek Duda 		no flags Details
Show Obsolete (2) View All

Description Radek Duda 2017-02-21 12:49:58 UTC 
Description of problem:
During migration of VM sound volume of the client suddenly increases

Version-Release number of selected component (if applicable):
rhv-m 4.1.1.2-0.1.el7

host rhel7.3

client1 rhel7.3-z:
virt-viewer-2.0-12.el7.x86_64
spice-gtk3-0.31-6.el7.x86_64
spice-protocol-0.12.11-1.el7.noarch

client2 rhel7.4:
virt-viewer-2.0-13.el7.x86_64
spice-gtk3-0.31-8.el7.x86_64
spice-protocol-0.12.12-1.el7.noarch

reproducible on win7, rhel7.3, rhel 6.9 guests


How reproducible: always


Steps to Reproduce:
1. have some VM in rhv-m and enable its soundcard
2. run VM
3. Connect to VM guest from client using remote-viewer
3. decrease client's volume to value between 0% and 100% (Settings -> Sound)
4. migrate

Actual results:
Sound volume of client is increased 


Expected results:
Sound volume of client stays on the same level


Additional info:
- Sound volume stays on the same level if volume >=100% or =0%
- volume level does not change if soundcard of guest is not enabled  or if connection via remote-viewer is not established
Comment 2 Victor Toso 2017-02-21 13:01:17 UTC 
Please include the spice-server logs.

If this is still happen, could be a regression as this was solved in Bug 1264107 by "sound: do not modify client state on migration":f10de4bc084fcc653340545b53782c8c4b660ea9

I can't see this being a client bug as the volume changes are messages sent by spice server based on guest's changes. Moving to spice-server for now.
Comment 3 Radek Duda 2017-02-21 14:04:09 UTC 
Created attachment 1256146 [details]
Spice-server log of migration destination host
Comment 4 Radek Duda 2017-02-21 14:05:31 UTC 
Created attachment 1256147 [details]
spice-server log of migration source host
Comment 5 Radek Duda 2017-02-21 14:11:50 UTC 
These are relevant packages on both hosts:
spice-server-0.12.4-19.el7.x86_64
qemu-kvm-rhev-2.6.0-28.el7_3.6.x86_64

I found it is not 100% reproducible. I could not manage to reproduce the bug with rhel7.3 guest for a while.
Comment 6 Radek Duda 2017-02-21 15:51:01 UTC 
Created attachment 1256181 [details]
migration destination set G_MESSAGES_DEBUG=all and SPICE_DEBUG=1
Comment 7 Radek Duda 2017-02-21 15:51:46 UTC 
Created attachment 1256182 [details]
migration source set G_MESSAGES_DEBUG=all and SPICE_DEBUG=1
Comment 8 Victor Toso 2017-02-24 07:47:44 UTC 
After VM migration, the client is receiving Guest's volume for both playback and record. It should not.

This can either decrease or increase client's application volume. Avoiding volume-jumps upon connection and migration was dealt in the past (Bug 1264107) so this seems to be a regression.
Comment 10 Victor Toso 2017-02-27 15:16:38 UTC 
Complementing comment #8

The bug is not just on volume but also with mute state. Changing the mute on the client and doing the migration, it should move mute back after migration.

PS: I'm always referring to application's volume or mute state (in the client)

Patch sent: https://lists.freedesktop.org/archives/spice-devel/2017-February/036049.html
Comment 11 Victor Toso 2017-02-28 12:50:24 UTC 
This is not a regression. I can reproduce the volume jump during migration in the RHEVM 3.6 instance at [0] which contains:

spice-server-0.12.4-15.el7_2.1.x86_64
qemu-kvm-1.5.3-105.el7_2.11.x86_64

I'm removing the regression keyword here.

[0] https://rhevm36.spice.brq.redhat.com
Comment 13 David Blechter 2017-05-24 15:43:35 UTC 
not a blocker, will be included in the next server build
Comment 14 Victor Toso 2017-05-30 13:17:32 UTC 
We missed the build for this one. Does not seem important enough for exception.
Moving to 7.5 and keeping the POST
Comment 16 Victor Toso 2017-11-16 15:22:05 UTC 
Rebased and sent again:

https://lists.freedesktop.org/archives/spice-devel/2017-November/040791.html
Comment 17 Victor Toso 2018-01-23 10:42:24 UTC 
This needs more investigation and likely a better fix, see [0]. Moving this to 7.6

[0] https://lists.freedesktop.org/archives/spice-devel/2017-December/041047.html
Comment 18 Victor Toso 2018-07-23 13:08:55 UTC 
WIP but too late for 7.6, moving to 7.7
Comment 19 Victor Toso 2018-12-14 11:51:01 UTC 
As per comment #17, this is client issue but not always reproducible.

> The client is sending sometimes the connection_id (link message) as 0 telling
> the server that this is a new connection so the server correctly send the
> mute/volume information.

Moving to spice-gtk in RHEL 8
Comment 20 Victor Toso 2020-01-23 10:18:16 UTC 
Considering we have an approach to workaround it in spice (comment #16) and overview of the bug in spice-gtk done by Frediano (see link on comment #17), lets fix this in 8.3
Comment 21 Frediano Ziglio 2020-01-23 14:56:25 UTC 
I don't think the spice-server patch is needed, these paths should not be reached, this code

    if (!red_client_during_migrate_at_target(red_client)) {
        snd_set_command(scc, SND_PLAYBACK_MODE_MASK);
        if (channel->volume.volume_nchannels) {
            snd_set_command(scc, SND_VOLUME_MUTE_MASK);
        }
    }

won't set the messages to be sent if connection is a migrating one.
Note You need to log in before you can comment on or make changes to this bug.