Bug 1012868

Created attachment 803853 [details]
spice debug

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

I can't reproduce this with 
virt-viewer-0.5.6-8.el6.x86_64.

Steps:
1. Prepare two rhel6.5 hosts.
   On host-A:
    1). create nfs server, add the nfs server to the storage pool.
    2). create a guest "fedora" with spice listen on 0.0.0.0 + qxl + spicevmc and a sound device, configure the image file on the nfs-pool
    3). Add the connection to host-B with virt-manager
    4). # setsebool virt_use_nfs 1
   On host-B:
    1). Add the nfs server on host-A to the storage pool
    2). Add the connection to host-A with virt-manager
    3). # setsebool virt_use_nfs 1

2. On host-A, Start the guest and play a song.
3. On host-A, Connect the guest with virt-viewer, make sure can hear the song.
  #  virt-viewer fedora
4. Migrate the guest to host-B

Result:
After the migration, the sound didn't change.

Could you test it with virt-viewer-0.5.6-8.el6.x86_64?

Hi Cong,

Just test with virt-viewer-0.5.6-8.el6.x86_64, also hit this problem.

qemu-kvm-0.12.1.2-2.415.el6.x86_64
guest:rhel6u5

Thanks,
Mazhang.

(In reply to mazhang from comment #5)
> Hi Cong,
> 
> Just test with virt-viewer-0.5.6-8.el6.x86_64, also hit this problem.
> 
> qemu-kvm-0.12.1.2-2.415.el6.x86_64
> guest:rhel6u5
> 
> Thanks,
> Mazhang.

Thanks , I can reproduce the problem now.


Version:
virt-viewer-0.5.6-8.el6.x86_64


Steps:

1. Prepare two rhel6.5 hosts(A and B) for the migration.
Configure bridge network "br0" on A and B.

2. edit "/etc/qemu-ifup" on A and B
#!/bin/sh
switch=br0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1

3. Prepare the guest img file on a nfs-server, and mount it on A and B
A: # mount <nfs-server>/$dir  /NFS
B: # mount <nfs-server>/$dir  /NFS

4. Run the guest on A:
#/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Opteron_G4 -m 2G -smp 2,sockets=1,cores=2,threads=1-enable-kvm -name rhel6u5 -uuid 990ea161-6b67-47b2-b803-19fb01d30d12 -smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 -k en-us -rtc base=localtime,clock=host,driftfix=slew -nodefaults -monitor stdio -qmp tcp:0:6666,server,nowait -boot menu=on -bios /usr/share/seabios/bios.bin -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -drive file=/NFS/s.img,if=none,id=drive-scsi-disk,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0 -device scsi-disk,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:80:7e:6f -device virtio-balloon-pci,id=balloon0 -vga qxl -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device intel-hda,id=sound0,bus=pci.0 -device hda-duplex

5. Prepare the host B:
# /usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Opteron_G4 -m 2G -smp 2,sockets=1,cores=2,threads=1-enable-kvm -name rhel6u5 -uuid 990ea161-6b67-47b2-b803-19fb01d30d12 -smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 -k en-us -rtc base=localtime,clock=host,driftfix=slew -nodefaults -monitor stdio -qmp tcp:0:6666,server,nowait -boot menu=on -bios /usr/share/seabios/bios.bin -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -drive file=/NFS/s.img,if=none,id=drive-scsi-disk,format=raw,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0 -device scsi-disk,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:80:7e:6f -device virtio-balloon-pci,id=balloon0 -vga qxl -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device intel-hda,id=sound0,bus=pci.0 -device hda-duplex -incoming tcp:0:5800

6. Connect the guest on Client machine with remote-viewer
# remote-viewer spice://$A-ip:5900
Play a song in the guest, make sure can hear the sound.

7. Do the migrate on A:
(qemu) client_migrate_info spice $B-ip 5900
(qemu) migrate -d tcp:$B-ip:5800,spiceport=5900,spicehost=$B-ip

Result:
After the migration, the sound gets louder

Additional info:
The effect is not obvious every time.

This can be reproduce with virt-manager too, the steps is same with comment 4.
The effect is not obvious every time, so can trun the sound down firstly.

the issue seems to boil down to client <--> guest volume synchronization that appears to work just in guest --> client direction and migration is one of two ways to trigger it:
1) have a guest with some audio playing in it (not necessary but it helps)
2) set the guest volume to say 90 % (client volume gets also adjusted*)
3) set the client volume to say 50 % (*)
4) do one of these two actions:
     * migrate the guest
     * in guest, lower the volume just one step (to say ~ 85 %)
what happens: client volume gets synced to ~85 %*, too, effectively doing the opposite of user wish (big volume increase instead of small decrease)
what should happen: in step 3), the guest volume should be adjusted as well.


* NOTE: all of these apply in rhel/fedora to pulseaudio default of flat-volumes = yes. If you change it in /etc/pulse/daemon.conf to "flat-volumes = no" and restart PA (pulseaudio -k; pulseaudio --start), then all the client volume references apply to per-application volumes of (virt|remote)-viewer, in gnome visible in Sound Properties --> Applications.

In practice, I think if migration wouldn't send extra unnecessary volume back to client, this bug would be mostly unnoticeable. It would only get adjusted when guest volume is changed, which is the expected result, to avoid volume change.

(In reply to Marc-Andre Lureau from comment #9)
> In practice, I think if migration wouldn't send extra unnecessary volume
> back to client, this bug would be mostly unnoticeable. It would only get
> adjusted when guest volume is changed, which is the expected result, to
> avoid volume change.

It's not just migration. I forgot one more scenario (linux client only):
1) have a disconnected guest with 100 % volume
2) connect to the guest from client with 30 % volume
3) play some music in the guest
4) decrease volume in the guest
result: your ears are likely to pop if the volume was at acceptable level at point 3)
Windows clients behave better: XP seems to ignore volume changes completely and 7 has somehow better implementation of PA's flat-volumes counterpart

There is a bit more to this issue:
  * users of full-screen clients are unlikely to use client software volume control
  * OTOH users who prefer volume keys adjust just client volume
  * linux users are more likely to use software controls as just scrolling over volume icon changes volume

To sum up, the best long term solution is two-way sync with some handling of different volumes at client launch. The best interim solution IMHO is to disable volume synchronization for linux clients till it works both-ways: no users will get surprise volume jups, experience of users with default settings will pretty much mirror the one of users with "flat-volumes = no".

(In reply to David Jaša from comment #10)
> (In reply to Marc-Andre Lureau from comment #9)
> > In practice, I think if migration wouldn't send extra unnecessary volume
> > back to client, this bug would be mostly unnoticeable. It would only get
> > adjusted when guest volume is changed, which is the expected result, to
> > avoid volume change.
> 
> It's not just migration. I forgot one more scenario (linux client only):
> 1) have a disconnected guest with 100 % volume
> 2) connect to the guest from client with 30 % volume
> 3) play some music in the guest
> 4) decrease volume in the guest
> result: your ears are likely to pop if the volume was at acceptable level at
> point 3)
> Windows clients behave better: XP seems to ignore volume changes completely
> and 7 has somehow better implementation of PA's flat-volumes counterpart

What you describe is a spice-gtk bug, that the volume isn't sync upon stream creation, sent a fix for that:

http://lists.freedesktop.org/archives/spice-devel/2014-February/016198.html

> There is a bit more to this issue:
>   * users of full-screen clients are unlikely to use client software volume
> control

yes

>   * OTOH users who prefer volume keys adjust just client volume

volume keys are redirected to guest too, if they are not for you, file a bug.

>   * linux users are more likely to use software controls as just scrolling
> over volume icon changes volume
> 
> To sum up, the best long term solution is two-way sync with some handling of
> different volumes at client launch. The best interim solution IMHO is to
> disable volume synchronization for linux clients till it works both-ways: no
> users will get surprise volume jups, experience of users with default
> settings will pretty much mirror the one of users with "flat-volumes = no".

I disagree, I think volume of the guest should be set on the client like if I plug my headphone or my speaker in a computer.

The rest of the bug looks like qemu or spice-server side issue to me, not client side (extra volume events), imho it should be moved/reassigned.

(In reply to Marc-Andre Lureau from comment #11)
...
> > Windows clients behave better: XP seems to ignore volume changes completely
> > and 7 has somehow better implementation of PA's flat-volumes counterpart
> 
> What you describe is a spice-gtk bug, that the volume isn't sync upon stream
> creation, sent a fix for that:
> 
> http://lists.freedesktop.org/archives/spice-devel/2014-February/016198.html
> 

Great!

> > There is a bit more to this issue:
> >   * users of full-screen clients are unlikely to use client software volume
> > control
> 
> yes
> 
> >   * OTOH users who prefer volume keys adjust just client volume
> 
> volume keys are redirected to guest too, if they are not for you, file a bug.
> 

OK

> >   * linux users are more likely to use software controls as just scrolling
> > over volume icon changes volume
> > 
> > To sum up, the best long term solution is two-way sync with some handling of
> > different volumes at client launch. The best interim solution IMHO is to
> > disable volume synchronization for linux clients till it works both-ways: no
> > users will get surprise volume jups, experience of users with default
> > settings will pretty much mirror the one of users with "flat-volumes = no".
> 
> I disagree, I think volume of the guest should be set on the client like if
> I plug my headphone or my speaker in a computer.
> 

Let's see how will things work with your new patch.

*** Bug 1118365 has been marked as a duplicate of this bug. ***

I think the patch in that bug got stuck on http://lists.freedesktop.org/archives/spice-devel/2014-February/016198.html :( Would be nice to get this in for 6.7.

the patch is not yet upstream, I would rather not ack this bug yet.

now is correct status

There are two different problems reported here:
1-) the volume jump during migration;
2-) the volume jump that can occur during normal use (comment #10);

The (1) has a patch in the ml in the spice-server:
http://lists.freedesktop.org/archives/spice-devel/2015-April/019608.html

The (2) should be fixed by new volume synchronization protocol; When the client connects, the volume in the client application is sent to the guest agent and the agent set the master volume.
ml: http://lists.freedesktop.org/archives/spice-devel/2015-April/019546.html

spice-gtk:
8c50e1a2b9f243a7da9b538cc1438b6a9d8e5671
aa8d044417bbf60685f59163b874ecb4f157c3c9
37ba949716ebf4411103308f4dbde75e81c7a9b3
29a6a342da427005c1f84c705a9435535c26d5e9

spice-protocol:
9acfaa66df90cb1475db7c09da09b6e9b5f5dd00

linux vdagent:
9b0eb8b1246ccb422ccecc3679b0bb6b477ba6cb
010dc21f35fb3997ade6717e10c6a3b52a1737ba

Posted this too:
http://lists.freedesktop.org/archives/spice-devel/2015-April/019608.html

The following commits upstream are also necessary for rhel6.

spice-gtk:
bac48297211258b6527ef03d71fee4c275d779b8
60a8a3543c9206727a907d0db42c1870dbd21a37
0a50d2c1aca61772b6522b74eb2324fd5378a60e

This feature is not going to land in RHEL6 which is quite stable at the moment but it is expected to be on RHEL7:

spice-protocol: https://bugzilla.redhat.com/show_bug.cgi?id=1264100
spice-gtk: https://bugzilla.redhat.com/show_bug.cgi?id=1264105
spice-server: https://bugzilla.redhat.com/show_bug.cgi?id=1264107
spice-vdagent: https://bugzilla.redhat.com/show_bug.cgi?id=1264102