Bug 821870 - spicec gets disconnected after migration while playing video during migration
spicec gets disconnected after migration while playing video during migration
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Yonit Halperin
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-15 11:53 EDT by Marian Krcmarik
Modified: 2012-10-03 14:39 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-03 14:39:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Client/DST/SRC logs (14.42 KB, text/plain)
2012-05-15 11:53 EDT, Marian Krcmarik
no flags Details

  None (edit)
Description Marian Krcmarik 2012-05-15 11:53:09 EDT
Created attachment 584702 [details]
Client/DST/SRC logs

Description of problem:
spicec gets disconnected after migration while playing video during migration. VM itself is fine, I am attaching Client logs, SRC and DST qemu log.

Version-Release number of selected component (if applicable):
spice-client-0.8.2-15.el6
spice-server-0.10.1-7
qemu-kvm-0.12.1.2-2.292

How reproducible:
Always

Steps to Reproduce:
1. Connect to a VM with spicec (spice-client) and start playing video on VM
2. Migrate
  
Actual results:
client gets disconnected.

Expected results:
Client should remain connected.

Additional info:
Comment 2 Yonit Halperin 2012-05-16 01:35:20 EDT
I think that the disconnection results from a race we have when migration completes between 
(1) libvirt killing the src 
(2) Spice client expecting a "clean" migration completion, i.e., it expects:
    (a) receiving MIGRATE_END from the src
    (b) the src to stay alive till it (the client) manages to switch to the dest.
The logs suggest that the client did receive MIGRATE_END, but that before it managed to switch all the channels to the dest, it identified that the src got disconnected and aborted.

In order to solve both this issue and the possible scenario in which MIGRATE_END message doesn't reach the client due to libvirt killing the src, I think that the client should just switch to the destination if it identifies disconnection from the src, even if it didn't receive MIGRATE_END. Note that the client has already established the required connections to the destination, before migration started.
Comment 3 Andrew Cathrow 2012-05-16 09:10:11 EDT
Are you seeing this in remote-viewer as well ?
Comment 4 Marian Krcmarik 2012-05-16 10:11:05 EDT
(In reply to comment #3)
> Are you seeing this in remote-viewer as well ?

Nope - The remote-viewer does not close itself during migration (I reported this to have it documented) but as far as I understand it The race is still there.
Comment 5 RHEL Product and Program Management 2012-05-21 02:49:19 EDT
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.
Comment 6 Marian Krcmarik 2012-08-01 15:48:08 EDT
This can impact spice-gtk as well (at least theoretically, should be looked at after seamless migration is implemented).
Moving to spice-gtk since we are replaced spice-client with spice-gtk based client remote-viewer.
Comment 7 Christophe Fergeau 2012-08-29 12:24:02 EDT
Any idea if the race has been addressed by the migration work that has been done recently? Comment #4 says that this bug cannot be reproduced with remote-viewer, so all that remains in this bug is the issue described by Yonit in https://bugzilla.redhat.com/show_bug.cgi?id=821870#c2
Comment 8 Yonit Halperin 2012-10-03 14:36:43 EDT
(In reply to comment #6)
> This can impact spice-gtk as well (at least theoretically, should be looked
> at after seamless migration is implemented).
> Moving to spice-gtk since we are replaced spice-client with spice-gtk based
> client remote-viewer.

Hi,
The implementation of migration in spice-gtk is a bit different than the one in spice-client. The migration completion phase is synchronous in spice-gtk and is not affected by the src qemu being terminated (this is relevant only for semi-seamless). Thus, I don't expect this bug to occur in spice-gtk, and I think it can be closed. 
For seamless migration, solving the race with libvirt is essential for passing the migration data from the src server, via the client, to the target server. The race should be solved by the fixes for bug #836135 and bug #836133.
Comment 9 Marian Krcmarik 2012-10-03 14:39:07 EDT
(In reply to comment #8)
> (In reply to comment #6)
> > This can impact spice-gtk as well (at least theoretically, should be looked
> > at after seamless migration is implemented).
> > Moving to spice-gtk since we are replaced spice-client with spice-gtk based
> > client remote-viewer.
> 
> Hi,
> The implementation of migration in spice-gtk is a bit different than the one
> in spice-client. The migration completion phase is synchronous in spice-gtk
> and is not affected by the src qemu being terminated (this is relevant only
> for semi-seamless). Thus, I don't expect this bug to occur in spice-gtk, and
> I think it can be closed. 
> For seamless migration, solving the race with libvirt is essential for
> passing the migration data from the src server, via the client, to the
> target server. The race should be solved by the fixes for bug #836135 and
> bug #836133.

Thanks for clarification.
I am closing as WONTFIX for spicec, as explained This does not affect spice-gtk and we were not able to hit it.

Note You need to log in before you can comment on or make changes to this bug.