Bug 1375141

Summary: Spice client connection is not normal after migrating guest from 6.8 to 7.3
Product: Red Hat Enterprise Linux 7 Reporter: Fangge Jin <fjin>
Component: spice-gtkAssignee: Default Assignee for SPICE Bugs <rh-spice-bugs>
Status: CLOSED WONTFIX QA Contact: SPICE QE bug list <spice-qe-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: cfergeau, dblechte, dyuan, fjin, fziglio, mzhan, pgrunt, rbalakri, tpelka, tzheng, xuzhang, yafu, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-16 13:50:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
logs and domain xml none

Description Fangge Jin 2016-09-12 09:37:39 UTC 
Description of problem:
Start a guest with spice listen='0.0.0.0' on RHEL6.8 host, open remote-viewer and connect to guest, then migrate the guest to RHEL7.3 host.
After migration, try to do some operation in remote-viewer, the guest has no response.

$ remote-viewer spice://10.66.4.166:5900 --debug --spice-debug 2>&1 > remote-viewer.log
(remote-viewer:30217): GSpice-WARNING **: incomplete link header (0/16)
(remote-viewer:30217): GSpice-WARNING **: major mismatch (got 2, expected 1)
(remote-viewer:30217): GSpice-WARNING **: incomplete link header (0/16)
(remote-viewer:30217): GSpice-WARNING **: major mismatch (got 2, expected 1)
(remote-viewer:30217): GSpice-CRITICAL **: spice_inputs_key_press_and_release: assertion 'channel->priv->state != SPICE_CHANNEL_STATE_UNCONNECTED' failed
(remote-viewer:30217): GSpice-CRITICAL **: spice_inputs_key_press: assertion 'SPICE_CHANNEL(channel)->priv->state != SPICE_CHANNEL_STATE_UNCONNECTED' failed

Before migration, on source host, there are 8 spice connections:
# netstat -tunap|grep 5900
tcp        0      0 0.0.0.0:5900                0.0.0.0:*                   LISTEN      14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45855           ESTABLISHED 14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45848           ESTABLISHED 14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45852           ESTABLISHED 14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45849           ESTABLISHED 14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45850           ESTABLISHED 14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45854           ESTABLISHED 14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45851           ESTABLISHED 14123/qemu-kvm      
tcp        0      0 10.66.4.166:5900            10.72.4.184:45853           ESTABLISHED 14123/qemu-kvm  

After migration, on target host, there are only 4 spice connections:
# netstat -tunap|grep 5900
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      11980/qemu-kvm          
tcp        0      0 10.66.4.152:5900        10.72.4.184:47433       ESTABLISHED 11980/qemu-kvm      
tcp        0      0 10.66.4.152:5900        10.72.4.184:47434       FIN_WAIT2   -                  
tcp        0      0 10.66.4.152:5900        10.72.4.184:47432       TIME_WAIT   -                  
tcp        0      0 10.66.4.152:5900        10.72.4.184:47435       TIME_WAIT   -                  
tcp        0      0 10.66.4.152:5900        10.72.4.184:47430       ESTABLISHED 11980/qemu-kvm      
tcp        0      0 10.66.4.152:5900        10.72.4.184:47436       ESTABLISHED 11980/qemu-kvm      
tcp        0      0 10.66.4.152:5900        10.72.4.184:47429       ESTABLISHED 11980/qemu-kvm      
tcp        0      0 10.66.4.152:5900        10.72.4.184:47431       FIN_WAIT2   -  

Close remote-viewer, connect to guest display on target directly and succeed:
$ remote-viewer spice://fjin-4-152:5900

Version-Release number of selected component:
RHEL6.8 host:
spice-server-0.12.4-13.el6.1.x86_64
libvirt-0.10.2-60.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.491.el6_8.3.x86_64

RHEL7.3 host:
qemu-kvm-rhev-2.6.0-23.el7.x86_64
libvirt-2.0.0-8.el7.x86_64
spice-server-0.12.4-19.el7.x86_64

Spice client:
virt-viewer-2.0-11.el7.x86_64
spice-gtk-0.31-6.el7.x86_64
spice-gtk3-0.31-6.el7.x86_64
spice-protocol-0.12.11-1.el7.noarch


How reproducible:
100%

Steps to Reproduce:
1. Start a guest with shared storage on RHEL6.8 host
2. Connect to guest by remote-viewer
3. Migrate the guest to RHEL7.3 host:
   # virsh migrate rhel6.6 qemu+ssh://10.66.4.152/system --live --verbose
   Migration: [100 %]  

Actual results:
Spice connection is not normal after migration from 6.8 to 7.3

Expected results:
Spice connection is normal after migration from 6.8 to 7.3, user can operate in guest through remote-viewer after migration.

Additional info:
I CAN'T reproduce this bug for the following migration scenarios:
7.3->7.3
7.2->7.3
6.8->6.8

I CAN reproduce this bug for the following migration scenarios:
6.8->7.2
Comment 1 Fangge Jin 2016-09-12 09:38:57 UTC 
Created attachment 1200136 [details]
logs and domain xml
Comment 3 Frediano Ziglio 2016-12-13 15:34:17 UTC 
What's happen if you disconnect remote-viewer and connect again?
Looks like it's more a client problem than a server one.
Comment 4 Fangge Jin 2016-12-14 02:03:41 UTC 
(In reply to Frediano Ziglio from comment #3)
> What's happen if you disconnect remote-viewer and connect again?
> Looks like it's more a client problem than a server one.

If I disconnect remote-viewer and connect again, it can connect successfully
Comment 5 Frediano Ziglio 2016-12-16 11:19:02 UTC 
As the reply I strongly think is more a problem in the widget or the client than in the server.
Comment 6 Frediano Ziglio 2016-12-16 11:39:01 UTC 
Can you attach a network capture (like wireshark or tcpdump) of the Spice traffic?
Comment 7 Pavel Grunt 2016-12-16 11:50:52 UTC 
(In reply to Frediano Ziglio from comment #5)
> As the reply I strongly think is more a problem in the widget or the client
> than in the server.

Is the seamless migration between two different versions of spice-server supported ?
Comment 8 David Blechter 2016-12-16 13:50:02 UTC 
(In reply to Pavel Grunt from comment #7)
> (In reply to Frediano Ziglio from comment #5)
> > As the reply I strongly think is more a problem in the widget or the client
> > than in the server.
> 
> Is the seamless migration between two different versions of spice-server
> supported ?

seamless migration is for inside the cluster migration, but between diff. RHEL hosts.
Comment 9 Fangge Jin 2016-12-26 11:16:38 UTC 
(In reply to David Blechter from comment #8)
> (In reply to Pavel Grunt from comment #7)
> > (In reply to Frediano Ziglio from comment #5)
> > > As the reply I strongly think is more a problem in the widget or the client
> > > than in the server.
> > 
> > Is the seamless migration between two different versions of spice-server
> > supported ?
> 
> seamless migration is for inside the cluster migration, but between diff.
> RHEL hosts.

Hi David

Do you mean that I only need to test spice migration between same host version (like RHEL7.3->RHEL7.3), not between different host version (like RHEL6 -> RHEL7, RHEL7.2->RHEL7.3)?

Thank you
Fangge Jin
Comment 10 David Blechter 2017-07-31 11:40:29 UTC 
(In reply to Fangge Jin from comment #9)
> (In reply to David Blechter from comment #8)
> > (In reply to Pavel Grunt from comment #7)
> > > (In reply to Frediano Ziglio from comment #5)
> > > > As the reply I strongly think is more a problem in the widget or the client
> > > > than in the server.
> > > 
> > > Is the seamless migration between two different versions of spice-server
> > > supported ?
> > 
> > seamless migration is for inside the cluster migration, but between diff.
> > RHEL hosts.
> 
> Hi David
> 
> Do you mean that I only need to test spice migration between same host
> version (like RHEL7.3->RHEL7.3), not between different host version (like
> RHEL6 -> RHEL7, RHEL7.2->RHEL7.3)?
> 
> Thank you
> Fangge Jin

this is correct